Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] A G'Caml question" + additional info
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: John Max Skaller <skaller@m...>
Subject: Re: [Caml-list] A G'Caml question" + additional info
"Krishnaswami, Neel" wrote:

> Permit me to disagree. I find nearly all of OCaml's features highly
> useful and orthogonal, and I am only working on medium size projects.

I don't find that is entirely true.
First, there is quite a bit of sugar, such as fun/function/match,
if then else vs. matching.

Then, there are duplicated facilities: tuples and records,
standard variants and polymorphic ones. Then classes and modules
Oh, and labelled arguments or not. To currify a function or use
a tuple .

Some syntax cannot be used as the 
basic grammar would suggest, and the constraints aren't documented.
For example, you can write:

	let x,y,z = (1,2,3) 
	let Some x = Some 1
	let (Some x) as y = Some 1

but not

	let (Some x) when true = Some 1

I'd give examples from the module system, if only I understood
how to use it properly.

In classes, you can write:

	x <- y

for 'assignment', but you have to write

	x := y

for a reference in ordinary code.

Many library components have both a functorial and
polymorphic interface. There are two versions
of some libraries (Unix, ThreadUnix). Some of the libraries
seem deficient (Str).

Then, there is a duplication of tools (native code
and bytecode compilers), label or standard mode.

The interaction of all these features with the type
system, particularly type inference, makes for some
really daunting error messages.

I'm NOT complaining, just disagreeing.
In my current project, I've been sticking to the basic
feature set. But I'm stronly tempted to switch to polymorphic
variants, because they'd provide much better typing for
my application. But I'm scared that I won't be able to 
understand the error messages, and quite concerned
that there's no way to catch spelling mistakes.
[Something which declared the variant names would be useful]
Switching over, to an _isomorphic_ program -- a mechanical
task -- will requires an almost complete rewrite, by hand.

There's no question that I have a difficult choice
between two non-orthogonal features. 
I'm glad to have the choice -- its much better than being stuck
in C++ without any representation of sums :-)

John (Max) Skaller, 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix
Literate Programming tool Interscript
Bug reports:  FAQ:
To unsubscribe, mail  Archives: