From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA01792 for caml-redistribution; Mon, 6 Sep 1999 18:16:29 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA19579 for ; Sat, 4 Sep 1999 20:52:18 +0200 (MET DST) Received: from iggy.triode.net.au (iggy.triode.net.au [203.63.235.1]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id UAA17352; Sat, 4 Sep 1999 20:52:14 +0200 (MET DST) Received: from egret (pm1-20.triode.net.au [203.63.235.36]) by iggy.triode.net.au (8.9.3/8.8.8) with SMTP id EAA15534; Sun, 5 Sep 1999 04:45:14 +1000 Message-Id: <3.0.6.32.19990903165643.0096fa20@mail.triode.net.au> X-Sender: skaller@mail.triode.net.au X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 03 Sep 1999 16:56:43 +1000 To: Pierre Weis From: John Skaller Subject: Re: convincing management to switch to Ocaml Cc: caml-list@inria.fr In-Reply-To: <199908311710.TAA18381@pauillac.inria.fr> References: <3.0.6.32.19990831053557.0096ea40@mail.triode.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: weis At 19:10 31/08/99 +0200, Pierre Weis wrote: >> Sure, I will try. First note that my background is >> in procedural languages. So I am used to calling functions like: >> >> f(x,y) >> >> In ocaml, if I used curried functions, then >> >> f x+1 y >> >> is an error >The problem in this example has nothing to do with currying, since you would the >same problem writing > f x+1 >instead of > f (x+1) Please excuse my clumbsy use of terminology: by currying I meant 'representing a function with multiple arguments using a higher order function': a1 -> a2 -> r instead of a tuple: a1 * a2 -> r Using this latter form: f(x+1,y) is 'correct', and 'natural' in the context of many languages I have previously written. >Yes, and once more the Caml convention is the mathematical one. Not where I can from: I learned algebra using reverse polish notation: here x f g h is considered unambiously as h ( g ( f (x) ) ) (* in forward notation *) I find the categorical interpretation even cleaner: x; f; g; h where 'x' is an element arrow for x: this notation is associative, so there is no need for brackets. Unfortunately, applying a functor is usually done by introducing an ambiguity (implicit conversion): f g h F which only makes sense if the arrows f g h are lifted to element functors. >> In ocaml, the function being called is _inside_ the brackets, >> first on the left, instead of labelling the 'node'. So it >> has the same visual status as its arguments. > >Normal for a functional programming language where functions can be >arguments of other functions, at any nested level. I'm not saying isn't normal for a functional programming language, I'm commenting that for someone like myself, whose 'normal' experience is with procedural languages, the change of paradigm is disconcerting, and is sure to put procedural programmers off switching to a functional language. >> This problem is exacerbated by the fact that a lot of >> ocaml is an expression, so you can do a lot of nesting. > >As in maths ? No. Mathematicians do several tricks to get around this: more or less, a convenient notation is invented that serves the purpose. Usually, this involves introducing 'justifiable' ambiguities. I personally find this difficult to deal with, and luckily the strong typing system of languages like ocaml do not permit it. [For example, embeddings are often made implicit] So the amount of punctuation required in real maths is usually a lot less than the same (type correct) ocaml expression. As another example, mathematicians use super and subscripts, more generally, visual layout often reduces the need for punctuation. >> A general rule for a good syntax would be that augmentation >> of some term of a construction only required local editing. >> This means: >> >> terminators, not separators >> mandatory begin/end keywords > >This cannot be done elegantly with function application, except if we >use a lisp-like syntax. Actually, I think it can. Every expression can have an unambiguous closed infix for: begin e s1 e s2 e s3 end which automatically nests without knowing any precedence rules. For any such rule where the separators are the same, it is always possible to allow an optional trailing one. A consequence of this may be a loss of error detection: (a,b,) now becomes legal. I'm not suggesting ocaml be changes, just trying to explain what I personally find difficult to get used to. >In the same vein, would you complain about r.lab compared to r.(lab) >or r(lab) or even r lab ? or also module.f compared to Module.f ? I'm not complaining. I'm explaining what I find difficult, in the hope the information will be useful. For example: more examples in the tutorial, which demonstrate precedences by usage. [People learn in the first instance by association, not by symbolic rules?] >More generally, do you mean that if we change a single character in a >program the meaning should not change ? Or that any notation should >not be a prefix or a suffix of another one ? I think that there is a concrete language design rule something like 'allow common changes to be local in the recommended style'. So for example, IF x THEN something; something; something; ELSE something; somnething; ENDIF here I can change the semantics within the body controlled by the then or/if part, by editiing within a lexical scope consisting of a sequence of lines: something my eye and editor a good at. Easily the best language I have used from this point of view is Python, although indenting must be considered a fundamental operation, and I yearn for a folding editor which would work so well with Python's syntax. >This is not light enough for a language that uses so many anonymous functions. >Once more generalizing it to efor, ewhile, elet, etry, ematch would >lead to a painful language. I have no dispute with this sentiment, I am not offering a 'design solution'. However, I note that 'for' and 'while' already DO have terminators: for do done .. while do done. I am thankful for small mercies :-) ------------------------------------------------------- John Skaller email: skaller@maxtal.com.au http://www.maxtal.com.au/~skaller phone: 61-2-96600850 snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia