* let ... in layout @ 2000-03-15 1:33 Julian Assange 2000-03-15 8:22 ` Jean-Yves Moyen ` (2 more replies) 0 siblings, 3 replies; 6+ messages in thread From: Julian Assange @ 2000-03-15 1:33 UTC (permalink / raw) To: caml-list; +Cc: proff let .. in let .. in ... seems such a common construct in caml that it could do with some syntatic sugar. I often see let..in run to 5-20 clauses. This appears incredibly ugly compared to the equivalent haskell code, is harder to read and takes longer to write due to the clutter of the surrounding token magic. Has anyone thought about applying layout in general to ocaml, or otherwise sugaring let...in? Is there any reason why the BNF let {name = expr}+ in would be ambiguous? The only other haskell features I frequently miss, are list comprehensions and multiple argument pattern matching. Cheers, Julian. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: let ... in layout 2000-03-15 1:33 let ... in layout Julian Assange @ 2000-03-15 8:22 ` Jean-Yves Moyen 2000-03-15 22:18 ` Julian Assange 2000-03-15 8:56 ` Benoit Deboursetty 2000-03-17 13:16 ` Dmitri Lomov 2 siblings, 1 reply; 6+ messages in thread From: Jean-Yves Moyen @ 2000-03-15 8:22 UTC (permalink / raw) To: Caml mailing list On 15 Mar 2000, Julian Assange wrote: > > let .. in > let .. in ... > > seems such a common construct in caml that it could do with some > syntatic sugar. I often see let..in run to 5-20 clauses. This appears > incredibly ugly compared to the equivalent haskell code, is harder to > read and takes longer to write due to the clutter of the surrounding > token magic. Has anyone thought about applying layout in general to > ocaml, or otherwise sugaring let...in? Is there any reason why the BNF > > let {name = expr}+ in > > would be ambiguous? I guess one can write: let silly f= let x=List.map f z=3 in ... which can be read either: let silly f= let x=List.map f in let z=3 in ... or: let silly f= let x=List.map in let f z=3 in ... Of course, if your definition aren't mutually recursive, you can use 'and' to separate two deifferent definitons: let x=t and y=u and ... and z=v in ... which is not so long to write, unambigous and readable (I find). > The only other haskell features I frequently miss, are list > comprehensions and multiple argument pattern matching. I don't understand exactly what you mean by 'multiple argument pattern matching', but I guess you could just use a tuple-pattern matching: let f a b c= match a,b,c with ... which allows you to match several arguments at once. Hypocoristiquement, Jym. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: let ... in layout 2000-03-15 8:22 ` Jean-Yves Moyen @ 2000-03-15 22:18 ` Julian Assange 2000-03-17 9:42 ` Pierre Weis 0 siblings, 1 reply; 6+ messages in thread From: Julian Assange @ 2000-03-15 22:18 UTC (permalink / raw) To: Jym; +Cc: Caml mailing list, proff Jean-Yves Moyen <Jean-Yves.Moyen@loria.fr> writes: > let f a b c= > match a,b,c with > ... > > which allows you to match several arguments at once. Sure, but let f a b c = match a,b,c with 0,1,2 -> 3 is a lot more cluttered than f 0 1 2 = 3 This wouldn't really be an issue except that pattern matching is so common. Intuitive brevity (as opposed to the brevity represented by languages such as perl) is what makes both haskell and *ml so readable. While both functions seem equally readable because they are both small, once you have a screen full of them there is a significant difference in clarity. Cheers, Julian. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: let ... in layout 2000-03-15 22:18 ` Julian Assange @ 2000-03-17 9:42 ` Pierre Weis 0 siblings, 0 replies; 6+ messages in thread From: Pierre Weis @ 2000-03-17 9:42 UTC (permalink / raw) To: Julian Assange; +Cc: caml-list > Jean-Yves Moyen <Jean-Yves.Moyen@loria.fr> writes: > > > let f a b c= > > match a,b,c with > > ... > > > > which allows you to match several arguments at once. > > Sure, but > > let f a b c = > match a,b,c with > 0,1,2 -> 3 > > is a lot more cluttered than > > f 0 1 2 = 3 > > This wouldn't really be an issue except that pattern matching is so > common. Intuitive brevity (as opposed to the brevity represented by > languages such as perl) is what makes both haskell and *ml so > readable. While both functions seem equally readable because they are > both small, once you have a screen full of them there is a significant > difference in clarity. > > Cheers, > Julian. You're right but this is not only a problem of syntax. There are semantics issues to consider. As for the syntax, your example is a bit contrieved, since there are not that many functions with pattern matching on 3 arguments that has only one match case. In general, such a complex function will have many cases and then the (admittedly heavier) way of writing the code in Caml gives you an extra benefit of naming the arguments, not repeating the function name, and clearly exhibit the complete pattern matching in one place: let f a b c = match a, b, c with | 0, _, 0 -> a + b + c | .... Also, the semantics of partial applications of curried pattern matching is not clear: consider your f example let f 0 1 2 = 3;; What's the meaning of this definition ? Two interpretations have been used in Caml: let f1 a b c = match a, b, c with | 0, 1, 2 -> 3 | _ -> raise Match_failure let f2 = function | 0 -> (function | 1 -> (function | 2 -> 3 | _ -> raise Match_failure) | _ -> raise Match_Failure) | _ -> raise Match_Failure I guess f2 is more consistent with the usual semantics of ML, while f1 seems to be more natural for users: with f2 partial applications will fail as early as necessary: (f 1 raises Match_failure as the definition of g in let g = List.map (f 1)), while with f1, application of f will fail only when 3 arguments are provided. I guess that this is this semantic problem, and the new syntax to add that prevents the addition of this feature to Caml. Best regards, Pierre Weis INRIA, Projet Cristal, http://pauillac.inria.fr/~weis ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: let ... in layout 2000-03-15 1:33 let ... in layout Julian Assange 2000-03-15 8:22 ` Jean-Yves Moyen @ 2000-03-15 8:56 ` Benoit Deboursetty 2000-03-17 13:16 ` Dmitri Lomov 2 siblings, 0 replies; 6+ messages in thread From: Benoit Deboursetty @ 2000-03-15 8:56 UTC (permalink / raw) To: Julian Assange; +Cc: caml-list > seems such a common construct in caml that it could do with some > syntatic sugar. I often see let..in run to 5-20 clauses. This appears > incredibly ugly compared to the equivalent haskell code, is harder to > read and takes longer to write due to the clutter of the surrounding > token magic. Has anyone thought about applying layout in general to > ocaml, or otherwise sugaring let...in? Is there any reason why the BNF > > let {name = expr}+ in > > would be ambiguous? Plenty... 1. Because the equal sign is also the structural equality operator, there is no way you could know that you begin another binding. With O'CaML now, you can write let a x = f x = 3 which means let a x = ((f x) = 3) where you would like let a x = f in let x = 3 in So perhaps you would better want a reserved keyword such as "be" or "is" to declare bindings. 2. But even there, there is another ambiguity between multiple applications and function definition : think about the following code... let a = f x y z in let g x y z = b in With your proposition this would turn into let a is f x y z g x y z is b in Let us read this as a line : let a is f x y z g x y z is b in \_____________/ where do you separate the two bindings? So, anyway, we must separate two successive bindings with a keyword. Perhaps you want a keyword that is an alias for "in let"... Something you can do sometimes to reduce your number of "let ... in" is to use let a, b, c = ..., ..., ... in (* 3 bindings at a time *) which I believe is optimized by the compilers and finally completely equivalent to let a = ... in let b = ... in ... (except perhaps order of evaluation?) If you do not like O'CaML grammar, I can only encourage you to use the excellent "caml preprocessor and pretty-printer" (camlp4) to modify it. http://caml.inria.fr/camlp4 It is much easier to use camlp4 than to write your own parser!! When you can write both a parser and a pretty-printer for O'CaML and when you can translate automatically from the original syntax to the other and vice-versa, you know you have done something which is not ambiguous. Best regards, BdB. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: let ... in layout 2000-03-15 1:33 let ... in layout Julian Assange 2000-03-15 8:22 ` Jean-Yves Moyen 2000-03-15 8:56 ` Benoit Deboursetty @ 2000-03-17 13:16 ` Dmitri Lomov 2 siblings, 0 replies; 6+ messages in thread From: Dmitri Lomov @ 2000-03-17 13:16 UTC (permalink / raw) To: caml-list Julian Assange wrote: > > [skip] > > The only other haskell features I frequently miss, are list > comprehensions and multiple argument pattern matching. Actually, comprehensions can be easily added using camlp4. I did this as an excercise for O'Caml course last spring. Source code is at: ftp://young.tepkom.ru/pub/compr The implementation supports list as well as array comprehensions. > > Cheers, > Julian. Friendly, Dmitri _________________________________________________________________ Dmitri S. Lomov mailto:dsl@tepkom.ru ICQ#: 20524819 (Rusty) http://users.tepkom.ru/dsl, http://young.tepkom.ru ftp://young.tepkom.ru +7 (812) 428-46-57 (b) +7 (812) 295-94-15 (h) ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2000-03-17 15:28 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-03-15 1:33 let ... in layout Julian Assange 2000-03-15 8:22 ` Jean-Yves Moyen 2000-03-15 22:18 ` Julian Assange 2000-03-17 9:42 ` Pierre Weis 2000-03-15 8:56 ` Benoit Deboursetty 2000-03-17 13:16 ` Dmitri Lomov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox