gudeman@cs.arizona.edu (David Gudeman) (03/21/91)
In article <18502:Mar2014:07:0691@kramden.acf.nyu.edu> Dan Bernstein writes: ]In article <896@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes: ] ]What language do you find most expressive? Let me guess: BCPL? :-) I could argue for Icon or Scheme on different grounds: Icon lets you express a collection of different evaluation paradigms that other languages don't. It has search-with-backtracking like Prolog, it has normal expressions and commands like most languages (but Prolog doesn't), it has success/failure semantics like SNOBOL4 (which also has expressions and comands, but not backtracking). Scheme has first-class continuations, closures, processes (sort of), and environments; which lets you express many things that you can't express without them (or without first implementing them). There are other, lesser known, languages that I could also argue for, but there isn't any language that has everything. And so far as I know there isn't any way to combine all these features without making the language unwieldy. One thing I would _not_ include in a definition of "expressive" is the ability to control the machine at a low level. Expressiveness should describe a language's suitability for "expressing" the solution to a large class of problems without regard to performance -- except (maybe) for algorithmic performance. Low-level control is certainly an important feature of some languages, but it is an entirely different kind of feature than expressiveness. -- David Gudeman gudeman@cs.arizona.edu noao!arizona!gudeman
oz@yunexus.yorku.ca (Ozan Yigit) (03/21/91)
In article <924@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes: >One thing I would _not_ include in a definition of "expressive" is the >ability to control the machine at a low level. Expressiveness should >describe a language's suitability for "expressing" the solution to a >large class of problems without regard to performance ... I agree. A much more formal view of what some people still think as a religious topic may be found on Matthias Felleisen's "On The Expressive Power of Programming Languages", original of which appeared in the Proceedings of the European Symposium on Programming 1990, Springer Lecture Notes in Computer Science, Volume 432, 134-151. A revised version of this paper is ftp-able from titan.rice.edu as public/expressiveness.dvi. Abstract: The literature on programming languages contains an abundance of informal claims on the relative expressive power of programming languages, but there is no framework for formalizing such statements nor for deriving interesting consequences. As a first step in this direction, we develop a formal notion of expressiveness and investigate its properties. To validate the theory, we analyse some widely held beliefs about the expressive power of several extensions of functional languages. Based on these results, we believe that our system correctly captures many of the informal ideas on expressiveness, and that it constitutes a good basis for further research in this direction. ... oz --- In seeking the unattainable, simplicity | Internet: oz@nexus.yorku.ca only gets in the way. -- Alan J. Perlis | Uucp: utai/utzoo!yunexus!oz
billk@hawk.cs.ukans.edu (Bill Kinnersley) (03/21/91)
In article <924@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes: : In article <18502:Mar2014:07:0691@kramden.acf.nyu.edu> Dan Bernstein writes: : ] : ]What language do you find most expressive? Let me guess: BCPL? :-) : : I could argue for Icon or Scheme on different grounds: : : Icon lets you express a collection of different evaluation paradigms : that other languages don't. It has search-with-backtracking like Prolog Icon's backtracking is "implicit", which means it is there but you can't see it. It is "restricted syntactically", which means you have to rewrite a major portion of your program into a single expression to get it to work. : it has success/failure semantics like SNOBOL4 which means Icon lacks boolean variables, operators or expressions. These two features, the heart and soul of Icon, are elegant on paper, and sound useful--until you try to use them. In practice they are of limited use, difficult to write, and difficult to debug. : gudeman@cs.arizona.edu : noao!arizona!gudeman -- --Bill Kinnersley billk@hawk.cs.ukans.edu 226 Transfer complete.
wright@gefion.rice.edu (Andrew Wright) (03/21/91)
In article <924@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes: : In article <18502:Mar2014:07:0691@kramden.acf.nyu.edu> Dan Bernstein writes: : ] : ]What language do you find most expressive? Let me guess: BCPL? :-) : : I could argue for Icon or Scheme on different grounds: Expressiveness _can_ be studied using formal tools, rather than just the usual fuzzy intuition-based arguments. @article{Felleisen90, author = "Matthias Felleisen", year = "1990", journal = "Proceedings of the European Symposium on Programming", publisher = "Springer-Verlag", volume = "LNCS 432", pages = "134-151", title = "On the Expressive Power of Programming Languages" } @article{Riecke91, author = "Jon G. Riecke", year = "1991", month = "January", journal = "Proceedings of the 18th Annual Symposium on Principles of Programming Languages", pages = "245-254", title = "Fully Abstract Translations between Functional Languages" } I was also under the impression that David Gudeman has also done some work in this direction? Disclaimer: Felleisen is my advisor, but his expressiveness results seem to match intuition, and have proved very useful in analyzing many aspects of programming languages. Andrew K. Wright Computer Science, Rice University wright@rice.edu Houston Texas 77251-1892
kwalker@cs.arizona.edu (Kenneth Walker) (03/22/91)
In article <1991Mar21.123639.577@hawk.cs.ukans.edu>, billk@hawk.cs.ukans.edu (Bill Kinnersley) writes: > In article <924@optima.cs.arizona.edu> gudeman@cs.arizona.edu > (David Gudeman) writes: > : Icon lets you express a collection of different evaluation paradigms > : that other languages don't. It has search-with-backtracking like Prolog > > Icon's backtracking is "implicit", which means it is there but you can't > see it. It is "restricted syntactically", which means you have to rewrite > a major portion of your program into a single expression to get it to work. What you "see" when you read a program depends on your mental model. If you understand where backtracking occurs, you will see it there. I don't understand your use of the term "rewrite". If you start off using goal-directed evaluation why would you have to rewrite your code to use it? The syntactic restrictions on backtracking is a feature that you can (and usually do) use because you want to. If you want to allow backtracking through your entire program, you can write it that way. As for most of your program being a single expression, it aways is. Icon is an expression oriented language: A procedure body is one expression even when you cannot backtrack through all of it. > : it has success/failure semantics like SNOBOL4 > > which means Icon lacks boolean variables, operators or expressions. You don't need boolean operators or expressions in Icon. Icon's success/failure semantics perform the same functionality quite elegantly. I realize some people who "grew up" with boolean operators are uncomfortable with this; to appreciate the elegance of Icon's expression evaluation mechanism you must escape from old prejudices. There are several ways to emulate boolean variables. None is as elegant as I would like, but they are not bad. > These two features, the heart and soul of Icon, are elegant on paper, and > sound useful--until you try to use them. In practice they are of limited > use, difficult to write, and difficult to debug. Full goal-directed evaluation is a powerful feature, but is not used extensively. That may be because few people have learned to think in those terms or it may be because you don't often need its power. Like anything else, it becomes easier to use as you gain experience with it. While complex goal-directed evaluation is not used a lot, generators are. In Icon, these are simply one piece of goal-directed evaluation and iterating through a generator is really a trivial example of backtracking. Debugging goal-directed evaluation also becomes easier with time, but can still be a problem. I'm not sure if that is an inherent difficulty or if we just lack good debugging tools. Anti-disclaimer: As a member of the Icon Project my opinions might be a triffle biased. Because Icon is not geared toward "systems programming", I do most of my implementation work in C. However, I assure you I write programs in Icon whenever it is applicable. It is far less painful than programming in C. Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621-4252 kwalker@cs.arizona.edu {uunet|allegra|noao}!arizona!kwalker
gudeman@cs.arizona.edu (David Gudeman) (03/22/91)
In article <1991Mar21.123639.577@hawk.cs.ukans.edu> Bill Kinnersley writes:
]Icon's backtracking is "implicit", which means it is there but you can't
]see it.
I don't now what you mean. You mean that there is no special
syntactic construct that says "this is backtracking"?
]It is "restricted syntactically", which means you have to rewrite
]a major portion of your program into a single expression to get it to work.
I don't know what you mean again. Backtracking works through
procedure calls, which seems pretty dynamic to me. As to rewriting
programs: only if you wrote it wrong in the first place, and all you
have to do to correct things is go through and put commas at the end
of any line that you want backtracked into. This is seldom what is
wanted though. Usually, the default behavior works fine.
]... Icon lacks boolean variables, operators or expressions.
Icon has boolean operators and expressions in the same sense that C
does -- they are actually more powerful, but you can treat them like
boolean operators and expressions if you want. Icon doesn't have
boolean variables, which has bothered me all of one time in thousands
of lines of Icon code. And it was easy to get around.
With "break", "next" (that's "continue" to you C hackers), and
"return", boolean variables just aren't needed very often. Icon even
has cascaded breaks so you can break out of multiple levels of loops.
]These two features, the heart and soul of Icon, are elegant on paper, and
]sound useful--until you try to use them. In practice they are of limited
]use, difficult to write, and difficult to debug.
There hundreds of people who disagree. Dedicated Iconites have come
from backgrounds as diverse as novice BASIC or Pascal programmers to
guru-level C hackers. I suspect that your effort to learn the
language --if any-- was half-hearted or under extremely poor
conditions.
--
David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman