yost@esquire.UUCP (David A. Yost) (11/27/89)
In article <16655@ultima.cs.uts.oz> potter@ultima.cs.uts.oz (John Potter) writes: > > From article <192@eiffel.UUCP>, by bertrand@eiffel.UUCP (Bertrand > Meyer): > >From article <182@enea.se>, sommar@enea.se (Erland Sommarskog): >> >> > [...] The rule for a relational expression should be something like: >> > Rel_exp ::= Expression (Rel_op Expression)* >> > [...] The semantic interpretation would be than of a logical AND so >> that: >> > a < b <= c > a + 2 >> > would be a shorthand for >> > a < b AND b <= c AND c > a + 2 >> > [...] Since Eiffel still is open for changes for some more time, >> > why not take the chance and add it? Not an essential thing, >> > but one of those little things that makes life easier. Or >> > is there some problem I have overlooked? >> >> I have tried to find an argument for not following >> Mr. Sommarskog's suggestion and I cannot think of one. >> As a matter of fact, many assertions in the basic Data Structure >> Library and elsewhere would be written more simply in this way. >> >> It may be that the reason why no mainstream language has >> included the form suggested by Mr. Sommarskog is that people feared >> ambiguity. >> But the simple semantics he suggests (``and'') makes any such fear >> unfounded. > >I've just got around to reading these articles and their followups. > >It may be of passing interest to note that the language Miranda allows >precisely this form of relational expression. Miranda is a functional >language with non-strict semantics (i.e. uses lazy evaluation). >The semantic interpretation of > a < b <= c > a + 2 >would be akin to the Eiffel form > a < b and then b <= c and then c > a + 2 >The "then" corresponds to the non-strict semantics in Miranda. OK, I guess it's time someone said that the Icon programming language (available free from icon-project@arizona.edu, but please give them a few bucks) can do this, plus Icon expressions yield more information. In most languages you could divide the world of expression values into two types: boolean (used for control structures) and non- boolean. In Icon, by contrast, every expression acts as both. Every expression either "succeeds" or "fails", giving you your true/false indication, if you want to use it, and, if the expression succeeds, it has a (non-boolean) value, if you want to use it. When any subexpression fails, expression evaluation stops, and the entire expression fails. And everything is an expression in Icon; there are no statements. If a relational expression succeeds, it takes the value of the right side. So, the expression (a < b) + 1 < c evaluates like this a b c expression --- --- --- ----------------- 2 1 3 no value - fails because a < b fails 1 2 3 no value - fails because b + 1 < c fails 1 2 4 c This succeed/fail property of Icon expressions is nice to use in practice. Yet there is more still: if an expression succeeds, it can be resumed, at which point it can yield another value or fail. Thus, you will see many forms of multi-valued "generator" expressions. You can use each value in turn or just the first value, if you like. For instance, the expression 1 to 3 which yields 1, then 2, then 3, ... then fails. There are various control structures that make it easy to take advantage of the multiple values that expressions can generate, such as every expression [ do expression ] while expression [ do expression ] For example, every x := 1 to 3 do write (x) Of course, Icon subroutines either succeed or fail, and can be written to generate additional values when resumed. Icon is neat. My ideal language would be an Icon-ish Eiffel, that is, for example, everything a succeed/fail multi-valued expression instead of some things statements and some things expressions, {} syntax instead of keywords, semicolons optional, and icon-like lists in the library. --dave yost
budd@mist.cs.orst.edu (Tim Budd) (11/28/89)
I'm developing a new programming language called LEDA, which is designed to be ``multiparadigm''. That is, you can program in a logical (prolog style), functional, object oriented or imparative style - or in any mix. It provides generators similar (and largely taken from) Icon, as well as many other features. Several papers on LEDA are in various pipelines, but none has seen daylight yet. If you want to see various technical reports let me know and I can send them. --tim budd (budd@cs.orst.edu)
peter@ficc.uu.net (Peter da Silva) (11/29/89)
I would like to note that this syntax has been used before. I implemented a real-time control language that did this about 6 or 7 years ago. It's very easy to implement, and the ambiguity does not produce much difficulty in practice. I was skeptical at first, but now I'm a convert. Too bad that project ended up getting canned due to overengineering. :-< -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM
ol@CERISI.CERISI.FR (Lecarme Olivier) (11/30/89)
I'm interested in ANY new programming language, and especially in any programming language trying to take out some good ideas from Icon. Here is my postal address: Olivier LECARME University of Nice Parc Valrose 06034 NICE cedex FRANCE Olivier Lecarme