From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA04005; Tue, 21 May 2002 09:04:29 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA04088 for ; Tue, 21 May 2002 09:04:28 +0200 (MET DST) Received: from fichte.ai.univie.ac.at (fichte.ai.univie.ac.at [131.130.174.156]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g4L749X28827; Tue, 21 May 2002 09:04:10 +0200 (MET DST) Received: (from markus@localhost) by fichte.ai.univie.ac.at (8.9.3/8.9.3/Debian 8.9.3-21) id NAA18178; Sun, 19 May 2002 13:31:30 +0200 Date: Sun, 19 May 2002 13:31:29 +0200 From: Markus Mottl To: Pierre Weis Cc: alex@baretta.com, caml-list@inria.fr Subject: Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs] Message-ID: <20020519113129.GA17044@fichte.ai.univie.ac.at> Mail-Followup-To: Pierre Weis , alex@baretta.com, caml-list@inria.fr References: <20020517153120.GB27012@kiefer.ai.univie.ac.at> <200205172118.XAA19584@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205172118.XAA19584@pauillac.inria.fr> User-Agent: Mutt/1.3.26i Organization: Austrian Research Institute for Artificial Intelligence Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Dear Pierre, On Fri, 17 May 2002, Pierre Weis wrote: > Hence, (to me) there is no question about the fact that semantics (hence > syntax) is of primordial importance. So that we have to improve the > syntax of the language if we can. But we cannot say that the regular > syntax is EXTREMELY ambiguous (with upper case letters and the like). Be > quite, please! It is not ambiguous. You need some parens sometimes as > in math, and math is not known to be that ambiguous. I am not sure whether you, as one of the language designers, felt offended by my use of an _emphasis_. If yes, it seems to be a misunderstanding, because I just wanted to point out the fact that "there _are_ problems" rather than that there was anything extremely ambiguous about OCaml, which would certainly be unjustified criticism. The problems are comparatively minor, but they do exist and therefore shouldn't be brushed under the carpet but (IMHO) solved at some point in the future. That's all I wanted to say. > Considering the difficulties of apprentices, some pedagogical theories > of mathematics once proposed to adopt completely unambiguous (read > absolutely redundant if you want) notations or encodings for algebraic > expressions in mathematics (reverse polish or lisp like parentheses > for operators). This was a complete failure. It happens to be not only > less readable than the usual notation but even much more difficult to > teach, use, and learn! I wouldn't say that e.g. RPN were "absolutely redundant". In fact, I think the reason why it wasn't so successful is exactly because it isn't redundant: humans just need some redundant syntactic hints to parse texts more efficiently. In the case of RPN it is actually impossible to interpret or correctly modify only a part of an expression without having parsed it from the beginning. This makes both understanding and editing very difficult. Just to give an example, I like the fact that the following is syntactically redundant in OCaml: let f = function X -> () | Y -> () and let f = function | X -> () | Y -> () This way I can more easily choose whether I want to put the whole code in one line or each match in a separate one. Without allowing a preceding "|" in the first line of a match it would be annoying to add matches at the beginning or move the first one elsewhere. OTOH, I really dislike the lack of distinction between constructors with tuple arguments and several arguments (as Brian has also mentioned). Or the following irregularity: try () with Exit -> print_string "Hello "; print_endline "world!"; print_endline "DONE" and if false then print_string "Hello "; print_endline "world!"; print_endline "DONE" The catch here is that users can accidently write suggestive code, which makes people believe that "DONE" will be printed in any case as in the "try/with"-example or that "world!" would be printed only if the condition were true in the "if/then/else" example. A simple-minded fix does not resolve all problems: try () with Exit -> (print_string "Hello "; print_endline "world!"); print_endline "DONE" This will still not print "DONE"! But here the behaviour changes: if false then (print_string "Hello "; print_endline "world!"); print_endline "DONE" I think this is just confusing. IMHO, "try/with" and "if/then/else" should really syntactically force users to explicitly express what they mean. To prevent myself from falling into such traps I have adopted the strategy to never use ";" in code parts that are executed conditionally: I use "let _ = ... in" instead, which doesn't look particularly beautiful, but which I can still parse successfully even when being in brain-dead mode. The upper case is particularly bad, because the compiler cannot help you. But there are similar ones that are annoying, but are at least caught at compile time, e.g.: match v1 with | A -> match v2 with | X -> () | Y -> () | B -> () Then there is this question of when to use ";;", which all beginners wonder about... > In any way, claiming the Caml syntax is this or that is just useless > and a waste of time. More interesting is to state problems that have > to be solved and axioms (or rules) you want to respect. People are certainly willing to discuss details of syntactic aspects they find confusing. AFAIK, it's almost always the same kind of problems. > That's what is interesting in the revised syntax. Believe it or not, > I am glad to see that it elegantly realizes some of those rules I > definitely would like to have in the syntax of the language; on the > other hand it consistantly violate other of my personal axioms about > the syntaxes I like. It is truly difficult to design a good syntax! I certainly agree that designing a good syntax is quite challeninging. Another reason why we should think about it - who doesn't like being challenged :-) > So, what I am interested in is to set up a list of rules to guide the > design of a syntax. This is hard, but interesting and could lead to a > syntax easy to learn and use. This would be constructive and new. What I consider at least as important is how to introduce syntactic changes into a language without driving users mad. This gets us back to the topic of having camlp4 in the distribution or not. I think that irrespective of the syntactic rules the community can finally agree on, a tool like camlp4 would be very welcome to support a transition. Best regards, Markus Mottl -- Markus Mottl markus@oefai.at Austrian Research Institute for Artificial Intelligence http://www.oefai.at/~markus ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners