Re: convincing management to switch to Ocaml

[John Skaller <skaller@maxtal.com.au>]

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