If OCaml were a car

If OCaml were a car

[Richard Jones]

This is on the first page of Digg at the moment ...

http://www.cs.caltech.edu/~mvanier/hacking/rants/cars.html

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] If OCaml were a car

[Jeff Meister]

That's a pretty accurate characterization, I think! ;)

On 8/18/07, Richard Jones <rich@annexia.org> wrote:
> This is on the first page of Digg at the moment ...
>
> http://www.cs.caltech.edu/~mvanier/hacking/rants/cars.html
>
> Rich.
>
> --
> Richard Jones
> Red Hat
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] If OCaml were a car

[Michael Vanier]

I agree, especially since I wrote it ;-)

Mike

Jeff Meister wrote:
> That's a pretty accurate characterization, I think! ;)
> 
> On 8/18/07, Richard Jones <rich@annexia.org> wrote:
>> This is on the first page of Digg at the moment ...
>>
>> http://www.cs.caltech.edu/~mvanier/hacking/rants/cars.html
>>
>> Rich.
>>
>> --
>> Richard Jones
>> Red Hat
>>
>> _______________________________________________
>> Caml-list mailing list. Subscription management:
>> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>> Archives: http://caml.inria.fr
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] If OCaml were a car

[Daniel Bünzli]

Maybe I ride this car too often to realize (or I'm dumb) but I don't  
get the joke about controls.

Daniel

Re: [Caml-list] If OCaml were a car

[Erik de Castro Lopo]

Daniel Bünzli wrote:

> Maybe I ride this car too often to realize (or I'm dumb) but I don't  
> get the joke about controls.

I'm preet sure thats a reference to Ocaml's rather odd (in
comparison to C/C++/Java/Perl/Python etc) syntax.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
Perl  : executable line noise
Python: executable pseudo-code

Re: [Caml-list] If OCaml were a car

[Luca de Alfaro]

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

The only thing about Ocaml I mind, is that it a bit like German is, in that
all the verbs at the end come.  And there nothing wrong is, but it for some
strange reading makes, and it strange is that this from France comes.

I still somewhat puzzled am, at reading:

let f x =
  [humonguous definition 50 lines spanning]
in List.iter f l

because the only way I make sense of this can, is by first looking at where
f used is, and only then reading its definition.
I much rather write would:

do List.iter f l
where f x = [humonguous definition]

Maybe this problem with Ocamlp4 solvable is?

Luca

-------------

PS: Yes, yes, I know why the let comes before the use, but it would still be
handy to have a pre-processor implement this do...where... construct.  Has
anyone done it already?
Yes, I also know that in German, unlike in Ocaml, the verbs do not always
come at the end... :-)

On 8/19/07, Erik de Castro Lopo <mle+ocaml@mega-nerd.com> wrote:
>
> Daniel Bünzli wrote:
>
> > Maybe I ride this car too often to realize (or I'm dumb) but I don't
> > get the joke about controls.
>
> I'm preet sure thats a reference to Ocaml's rather odd (in
> comparison to C/C++/Java/Perl/Python etc) syntax.
>
> Erik
> --
> -----------------------------------------------------------------
> Erik de Castro Lopo
> -----------------------------------------------------------------
> Perl  : executable line noise
> Python: executable pseudo-code
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 2405 bytes --]

Re: [Caml-list] If OCaml were a car

[Jon Harrop]

On Wednesday 22 August 2007 06:50:24 Luca de Alfaro wrote:
> The only thing about Ocaml I mind, is that it a bit like German is, in that
> all the verbs at the end come.  And there nothing wrong is, but it for some
> strange reading makes, and it strange is that this from France comes.
>
> I still somewhat puzzled am, at reading:
>
> let f x =
>   [humonguous definition 50 lines spanning]
> in List.iter f l
>
> because the only way I make sense of this can, is by first looking at where
> f used is, and only then reading its definition.
> I much rather write would:
>
> do List.iter f l
> where f x = [humonguous definition]
>
> Maybe this problem with Ocamlp4 solvable is?

Get this to good effect in vanilla OCaml by copying F# you can:

  let ( |> ) x f = f x

  l |> List.iter
    (fun e -> ...)

-- 
Yoda, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e

Re: [Caml-list] If OCaml were a car

[Jacques Garrigue]

From: Jon Harrop <jon@ffconsultancy.com>
> On Wednesday 22 August 2007 06:50:24 Luca de Alfaro wrote:
> > The only thing about Ocaml I mind, is that it a bit like German is, in that
> > all the verbs at the end come.  And there nothing wrong is, but it for some
> > strange reading makes, and it strange is that this from France comes.
> >
> > I still somewhat puzzled am, at reading:
> >
> > let f x =
> >   [humonguous definition 50 lines spanning]
> > in List.iter f l
> >
> > because the only way I make sense of this can, is by first looking at where
> > f used is, and only then reading its definition.
> > I much rather write would:
> >
> > do List.iter f l
> > where f x = [humonguous definition]
> >
> > Maybe this problem with Ocamlp4 solvable is?
> 
> Get this to good effect in vanilla OCaml by copying F# you can:
> 
>   let ( |> ) x f = f x
> 
>   l |> List.iter
>     (fun e -> ...)

Or, sugar-free,

  open StdLabels

  List.iter l ~f:
  begin fun x ->
    ...
  end

Jacques Garrigue

Re: [Caml-list] If OCaml were a car

[Nathaniel Gray]

On 8/21/07, Luca de Alfaro <luca@dealfaro.org> wrote:
> The only thing about Ocaml I mind, is that it a bit like German is, in that
> all the verbs at the end come.  And there nothing wrong is, but it for some
> strange reading makes, and it strange is that this from France comes.
>
> I still somewhat puzzled am, at reading:
>
> let f x =
>   [humonguous definition 50 lines spanning]
> in List.iter f l
>
> because the only way I make sense of this can, is by first looking at where
> f used is, and only then reading its definition.
> I much rather write would:
>
> do List.iter f l
> where f x = [humonguous definition]

Given the prevalence of List.fold and friends, I think this (the order
of arguments) is the biggest obstacle to code comprehension in OCaml.
I've even gone so far as to create my own ReList (readable list)
library:
  ReList.iter l
    (fun x -> [humongous definition] )

As others have mentioned, labels can help as well if that's an option
for you, but I find the label system to be a bit intrusive for
everyday usage.

> Maybe this problem with Ocamlp4 solvable is?

I think it already has been done once or twice with camlp4.  This and
try/finally are popular in camlp4 demos...

Cheers,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

Re: [Caml-list] If OCaml were a car

[Oliver Bandel]

Zitat von Nathaniel Gray <n8gray@gmail.com>:

> On 8/21/07, Luca de Alfaro <luca@dealfaro.org> wrote:
> > The only thing about Ocaml I mind, is that it a bit like German is, in that
> > all the verbs at the end come.  And there nothing wrong is, but it for some
> > strange reading makes, and it strange is that this from France comes.
> >
> > I still somewhat puzzled am, at reading:
> >
> > let f x =
> >   [humonguous definition 50 lines spanning]
> > in List.iter f l
> >
> > because the only way I make sense of this can, is by first looking at where
> > f used is, and only then reading its definition.
> > I much rather write would:
> >
> > do List.iter f l
> > where f x = [humonguous definition]
>
> Given the prevalence of List.fold and friends, I think this (the order
> of arguments) is the biggest obstacle to code comprehension in OCaml.
[...]

I think that is the joke with wrong sided controls of the car?! ;-)


Ciao,
   Oliver

Re: [Caml-list] If OCaml were a car

[John Carr]

> Maybe I ride this car too often to realize (or I'm dumb) but I don't  
> get the joke about controls.

OCaml has a badly designed syntax processed by a badly implemented
parser feeding into a backend that generates poor error messages.
All this makes the language hard to use.  Anybody else learn C
using pcc on Unix?

Unfortunately, I didn't think to start cataloging compiler error
messages and their causes when I started learning the language.
I did send one anomaly to the list about parsing of semicolons.

Re: [Caml-list] If OCaml were a car

[brogoff]

On Sun, 19 Aug 2007, John Carr wrote:
> > Maybe I ride this car too often to realize (or I'm dumb) but I don't
> > get the joke about controls.
>
> OCaml has a badly designed syntax processed by a badly implemented
> parser feeding into a backend that generates poor error messages.
> All this makes the language hard to use.  Anybody else learn C
> using pcc on Unix?

I'm not a fan of the current syntax or error handling either. What's the
way out? Revised didn't catch on widely, though it fixes a few of the
syntactic flaws. Now it appears that Revised will fracture into two
streams, one with camlp4 and the other with camlp5. That isn't a good
sign.

One of the better compilers I used for syntactic error messages was
GNAT, the free Ada 95 one, and the parser was hand coded recursive
descent (Ada's provided grammars are NOT even close to LL(1), either)
and the diagnostics were superb.

-- Brian

Re: [Caml-list] If OCaml were a car

[Richard Jones]

On Sun, Aug 19, 2007 at 10:43:14AM -0400, John Carr wrote:
> > Maybe I ride this car too often to realize (or I'm dumb) but I don't  
> > get the joke about controls.
> 
> OCaml has a badly designed syntax processed by a badly implemented
> parser feeding into a backend that generates poor error messages.
> All this makes the language hard to use.

I think this is a little bit of an exaggeration, but there is some
truth to it.

It's not likely that the syntax can be changed (how is the revised
syntax doing lately?) but there is one error message which could be
fixed.  When I worked at Merjis a colleague got frustrated to the
point of virtually giving up the language at the error message "Foo
makes inconsistent assumptions over Bar"[1].  It is literally useless:
it does not describe what it means, what files are involved which are
inconsistent, what their MD5 sums are or should be, and lastly it
doesn't say how to fix the problem (which generally involves
recompiling libraries).

On the up side, OCaml does show you the range of characters within the
line where the error happens.  This is something I now really miss
when using gcc / C code.

> Anybody else learn C using pcc on Unix?

Using the traditional K&R compiler for OS-9/68k and later using pcc on
Unix.  The OS-9 compiler only had about 10 different error messages
that it could print (I remember they were listed on a short page in
the manual).  ocamlopt really is miles better :-)

> Unfortunately, I didn't think to start cataloging compiler error
> messages and their causes when I started learning the language.
> I did send one anomaly to the list about parsing of semicolons.

I tell beginners that most code they write should be within a toplevel
statement:

  let _ =
    ...

or (better):

  let () =
    ...

That basically gets rid of any ; vs ;; issues.

On the subject of cataloging error messages see:
http://www.ocaml-tutorial.org/common_error_messages

Rich.

[1] I forget the precise message because hopefully my terribly
complicated dependency rules for OCaml on Fedora make it impossible
to happen, so I can't recreate it here!
http://fedoraproject.org/wiki/Packaging/OCaml#head-0c27c921de0c32d391ea39fffcbbacbd28ad10ca

-- 
Richard Jones
Red Hat

Re: [Caml-list] If OCaml were a car

[Stefano Zacchiroli]

On Sun, Aug 19, 2007 at 06:07:16PM +0100, Richard Jones wrote:
> It's not likely that the syntax can be changed (how is the revised
> syntax doing lately?) but there is one error message which could be

Well, yes, the syntax can be changed and it isn't hard either.

It's just a matter of stating something like «from version x.y the
official syntax is the revised one, you can use the provided converter
for migrating your old code to the new syntax». Other languages have
seen similar migrations in the past and they survived.

Point is that upstream OCaml authors have never acknowledged that the
current syntax is more than sub-optimal and the fear of missing backward
compatibility has done the rest.

The revised syntax is far better, but there has never been the
willingness to push it.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time

Re: [Caml-list] If OCaml were a car

[Luca de Alfaro]

[-- Attachment #1: Type: text/plain, Size: 2563 bytes --]

Backward compatibility is of the UTMOST importance.
Developers tend to assume that people who wrote package X can always adapt
it to new conventions, but often this is just not true: the developers may
be working on other things now, their interests may have shifted, and great
packages get left behind and are eventually lost.

Let's make an example: George Necula in Berkeley wrote (with his students)
CIL, a superb front-end to C code analysis.  Suppose the Ocaml syntax
changes in a non-trivial way.  Would he be willing, and have time, to fix
CIL?  To spend his time in a job with zero innovation content, and lots of
frustration?  It is anyone's bet.  And what about in five years from now?
Who knows?

There is a point in which people move on, and it is very important that
software continues to work in a stable way, or we are losing great work all
the time -- and there is some great work that is not easy at all to redo.
Yes, the language survives, but the software not always.

Luca

On 8/19/07, Stefano Zacchiroli <zack@bononia.it> wrote:
>
> On Sun, Aug 19, 2007 at 06:07:16PM +0100, Richard Jones wrote:
> > It's not likely that the syntax can be changed (how is the revised
> > syntax doing lately?) but there is one error message which could be
>
> Well, yes, the syntax can be changed and it isn't hard either.
>
> It's just a matter of stating something like «from version x.y the
> official syntax is the revised one, you can use the provided converter
> for migrating your old code to the new syntax». Other languages have
> seen similar migrations in the past and they survived.
>
> Point is that upstream OCaml authors have never acknowledged that the
> current syntax is more than sub-optimal and the fear of missing backward
> compatibility has done the rest.
>
> The revised syntax is far better, but there has never been the
> willingness to push it.
>
> Cheers.
>
> --
> Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
> zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
> (15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
> (15:57:15)  Bac: no, la demo scema    \/    right keys at the right time
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 3377 bytes --]

Re: [Caml-list] If OCaml were a car

[Vincent Hanquez]

On Sun, Aug 19, 2007 at 06:07:16PM +0100, Richard Jones wrote:
> > Unfortunately, I didn't think to start cataloging compiler error
> > messages and their causes when I started learning the language.
> > I did send one anomaly to the list about parsing of semicolons.
> 
> I tell beginners that most code they write should be within a toplevel
> statement:
> 
>   let _ =
>     ...

That's very bad to advocate this kind of construct.
on weird function, you are going to get caugth with partial application
and ocaml will never tell you.

for example:

let _ = Printf.printf "something %s" in

will never print ... and it will takes some time to a beginners to find
what's going on.

> or (better):
> 
>   let () =
>     ...

at least this one prevent you for doing so..

-- 
Vincent Hanquez

RE: [Caml-list] If OCaml were a car

[David Allsopp]

> It's not likely that the syntax can be changed (how is the revised
> syntax doing lately?) but there is one error message which could be
> fixed.  When I worked at Merjis a colleague got frustrated to the
> point of virtually giving up the language at the error message "Foo
> makes inconsistent assumptions over Bar"[1].  It is literally useless:
> it does not describe what it means, what files are involved which are
> inconsistent, what their MD5 sums are or should be, and lastly it
> doesn't say how to fix the problem (which generally involves
> recompiling libraries).

I'm not sure I'd classify this as the "worst" message the compiler gives -
when I see that it tells me that my Makefile dependencies are broken (if
Bar.cmi is part of my project) or that I've updated a library (if Bar.cmi is
from something else) and either way that make clean; make will fix it for
now!

The error message on a missing "in" in a "let...in" block on the other hand
is the one that drives me up the wall...

(* first function *)
let f x = (* definition of f *)
in
  let g x = (* definition of g *)
  (* etc, etc *)

(* next function *)
let h x = (* definition of *)

Here, O'Caml helpfully tells me that there's a syntax error on line 7 which
is of course complete rubbish!! It may be easy to spot here, but I've
absent-mindedly missed the final part of a bigger function mid-development
(or after having to leave the code and come back to it) and had to spend
*ages* trying to find where the error is in larger ML files... in this
situation I'd really like a "the let on line 4 may be un-matched" guess
similar to that for mismatched parenthesis :o)

> I tell beginners that most code they write should be within a toplevel
> statement:
> 
>  let _ =
>     ...
>
> or (better):
>
>   let () =
>     ...

I'd go one further - and recommend that all top level statements are
function definitions (there's so rarely a need to use global "variables"...
it usually comes back to bite you at some point later). Then define a
function main () to do the "top level" part of your program (the concept of
"main" is generally clearer to someone coming to ML from a more mainstream
language) and finish the whole thing to give code like:

type t = Foo

let foo f = f ()

let bar _ = Foo

let main () = foo bar

(* One top-level statement to run the program *)
let _ = main (); ()

While I wouldn't bet my life on it, I've never found a need for ";;" at all
when coding this way and ";" always binds as you expect it to.


David

Re: [Caml-list] If OCaml were a car

[Richard Jones]

On Tue, Aug 21, 2007 at 09:05:33AM +0100, David Allsopp wrote:
> (* first function *)
> let f x = (* definition of f *)
> in
>   let g x = (* definition of g *)
>   (* etc, etc *)
> 
> (* next function *)
> let h x = (* definition of *)
> 
> Here, O'Caml helpfully tells me that there's a syntax error on line 7 which
> is of course complete rubbish!! It may be easy to spot here, but I've
> absent-mindedly missed the final part of a bigger function mid-development

I find that using tuareg-mode (an Emacs mode for OCaml) generally
avoids this problem.

[...]
> I'd go one further - and recommend that all top level statements are
> function definitions (there's so rarely a need to use global "variables"...
> it usually comes back to bite you at some point later). Then define a

No I use top level "variables" all the time.  It depends what sort of
program you're writing, but for once-through command-line programs you
will often do things like:

let dbname = (* something involving Sys.argv *) ;;
let dbh = PGOCaml.connect ~dbname () ;;

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] If OCaml were a car

[Tom]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

On 19/08/07, John Carr <jfc@mit.edu> wrote:
>
>
> OCaml has a badly designed syntax processed by a badly implemented
> parser feeding into a backend that generates poor error messages.
> All this makes the language hard to use.
>

I would just like to know, what exactly do you think is badly designed, and
what would be a better alternative? Mind that I am not defending OCaml's
syntax here (I have grown accustumed to it, but I do not find it superb...
probably...), I just think that all criticism should be constructive (that
is, shut up unless you've got a better idea). I would also like to hear some
improvements that could be made to the syntax (of OCaml or possibly some
future functional language), as I think that currently, OCaml syntax is
better than both SML and Haskell.

One possible complaint I see here is too many parenthenses and therefore
confusing eror messages, however I prefer denser code to the way it was
"fixed" in the revised syntax by adding more closing terminals...

 - Tom

(I hope you get what I'm saying... I'm somehow lost...)

[-- Attachment #2: Type: text/html, Size: 1386 bytes --]

Re: [Caml-list] If OCaml were a car

[skaller]

On Sun, 2007-08-19 at 22:30 +0200, Tom wrote:
> On 19/08/07, John Carr <jfc@mit.edu> wrote:
>         
>         OCaml has a badly designed syntax processed by a badly
>         implemented
>         parser feeding into a backend that generates poor error
>         messages.
>         All this makes the language hard to use.  
> 
> I would just like to know, what exactly do you think is badly
> designed, and what would be a better alternative? Mind that I am not
> defending OCaml's syntax here (I have grown accustumed to it, but I do
> not find it superb... probably...), I just think that all criticism
> should be constructive (that is, shut up unless you've got a better
> idea). 

I disagree with that: Most analysis is
and should be destructive. Understanding problems is the
precursor to constructing better solutions.

Ocaml has lots of syntactic issues. It has too many operators,
so that it is hard to remember their 'precedence'. Some are
very un-natural, for example:

	if e then e1 else e2

The thing is that 'else' has a different 'precedence' than 'then'.
So you can write:

	if e then e1 else a; b; c

and a,b,c are all executed if the condition is false, but you
cannot write:

	if e then a; b; c else ...

and similarly for let/in. So you need parentheses in the 'then' branch
to write a 'larger' expression, but you need parentheses around the
whole if/else to write a 'smaller' expression in the else 
branch ..

Furthermore, because of the decision that procedures
return unit, you can write:

	if e then p;

without the else, but only if p has type unit: the syntax is so
confused it doesn't know if it is functional/expression based
(in which case the else expression should be mandatory)
or procedural (in which case procedure calls should return void
to prevent the call being used as an argument to an application).

Felix procedures return void, and it provides

	if e then e1 else e2 endif  // an expression
	if e do 
		s1; s2; s3; 
	elif e1 then                // optional
		s4; s5; s6;
	else 			    // optional
		s7; s8; s9;
	done; 			    // a statement 

and in both cases the text of the branches can be
transparently swapped around. The cost is additional syntax
and the mandatory terminator. But if you don't like it
you can roll your own syntax .. as in Ocaml. For example
Felix also parses:

	if (x < 1) print "Less";
	else print "No"; // optional

if the "C" domain specific sublanguage syntax (DSSL csyntax) is loaded
(which it is by default). And if you like Python or Haskell you can
even write:

	if (x < 1) $$
		print "Less"
	else $$
		print "No"

[the $$ is ugly, but something is required to initiate indent mode]

Well it is NOT clear that all these alternatives are actually
a good idea, just as it is NOT clear that excess use of camlp4 is
a good idea. In my experience, using the language's raw syntax,
even if it has warts, is more or less mandatory if you want 
other people to be able to read your code.

Can Ocaml syntax be improved? Yes, but not much. Felix has:

	print$ "Hello" + " World";

which is stolen from Haskell and gets used a lot. Even if I can
implement that with camplp4 I wouldn't. I'd like to see $ in
the standard language: then I'd use it.

Every 'feature' of Ocaml syntax I hate I also love, 
for example:

	let f x = 
		blah
		blah
	in

WOOPS! I forgot a pre-condition .. 

	let f x = 
		if precond x then specialvalue else
		blah
		blah
	in

so I can add just one line without touching the rest 
of the code .. this is really cool!! .. so maybe the
weird if/then/else isn't so bad after all ... :)

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] If OCaml were a car

[Jon Harrop]

I'm quite surprised to hear so many non-specific complaints. There are, as 
always, some tweaks I'd like to make...

On Sunday 19 August 2007 22:45:41 skaller wrote:
> Ocaml has lots of syntactic issues. It has too many operators,
> so that it is hard to remember their 'precedence'. Some are
> very un-natural, for example:
>
> 	if e then e1 else e2
>
> The thing is that 'else' has a different 'precedence' than 'then'.
> So you can write:
>
> 	if e then e1 else a; b; c
>
> and a,b,c are all executed if the condition is false,

I do not believe this is true. The "b" and "c" are executed in both cases 
because the above is parsed as:

  (if e then e1 else a); b; c

which is syntactically uniform:

# (<:expr< (if true then a else a);b;c >>) =
  (<:expr< if true then a else a;b;c >>);;
- : bool = true

Perhaps you were thinking of this:

  if p then t else
    let () = () in
    f1;
    f2;
    f3

because "let" binds more tightly.

> Furthermore, because of the decision that procedures
> return unit, you can write:
>
> 	if e then p;
>
> without the else, but only if p has type unit: the syntax is so
> confused it doesn't know if it is functional/expression based
> (in which case the else expression should be mandatory)
> or procedural (in which case procedure calls should return void
> to prevent the call being used as an argument to an application).

Why should the return value (of unit) not be used as the argument to an 
application?

> Well it is NOT clear that all these alternatives are actually
> a good idea, just as it is NOT clear that excess use of camlp4 is
> a good idea. In my experience, using the language's raw syntax,
> even if it has warts, is more or less mandatory if you want
> other people to be able to read your code.

Yes.

> Can Ocaml syntax be improved? Yes, but not much. Felix has:
>
> 	print$ "Hello" + " World";
>
> which is stolen from Haskell and gets used a lot. Even if I can
> implement that with camplp4 I wouldn't. I'd like to see $ in
> the standard language: then I'd use it.

You might prefer the F# operators |>, << and >>.

For syntactic changes, my personal vote goes to some very useful syntactic 
extensions rather than any replacements, and ones that don't (in practice) 
break backward compatibility.

Boolean expressions could permit:

   a < b <= c

Asymmetric whitespace allows a new unary minus operator with higher 
precedence:

  a - b -> Sub(a, b)
  a -b -> Apply(a, -b)
  a-b -> Sub(a, b)

That's pretty much all I can think of. The rest is fine by me. I'd much rather 
see effort go into an IDE rather than tweaking the syntax and breaking 
backward compatibility.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e

Re: [Caml-list] If OCaml were a car

[skaller]

On Mon, 2007-08-20 at 04:37 +0100, Jon Harrop wrote:

> >
> > The thing is that 'else' has a different 'precedence' than 'then'.
> > So you can write:
> >
> > 	if e then e1 else a; b; c
> >
> > and a,b,c are all executed if the condition is false,
> 
> I do not believe this is true. The "b" and "c" are executed in both cases 
> because the above is parsed as:
> 
>   (if e then e1 else a); b; c
> 
> which is syntactically uniform:
> 
> # (<:expr< (if true then a else a);b;c >>) =
>   (<:expr< if true then a else a;b;c >>);;
> - : bool = true
> 
> Perhaps you were thinking of this:
> 
>   if p then t else
>     let () = () in
>     f1;
>     f2;
>     f3
> 
> because "let" binds more tightly.

Well there you go! I've been writing Ocaml almost 10 years and 
didn't know that. Here's my real code:

    if ret = `BTYP_tuple [] then "// elided (returns unit)\n","" else
    let funtype = fold syms.dfns (`BTYP_function (argtype, ret)) in

I guess I'm just lucky. From what you say, the grammar is exceptionally
bad: the scope of the 'else' is *extended* by the let/in non-terminal
so it goes past ';' -- that should be a syntax error. 

Roughly a 'loosely' binding operator is extending the scope 
of a 'tightly' binding operator: doing that is fragile. For example
if I drop the 'let .. in' part the semantics may** change silently.

The 'right' way to extend a scope is to use an scope extension 
operator with no semantics, such as ( .. ) or begin .. end,
or $ in Felix in Haskell.

But please note: just because I present this analysis doesn't mean
I believe it 100%. Contrarily .. it is just a data point. It has
to be weighted against other factors: every syntactic form has
both advantages and disadvantages, and it is very dependent
on the client's prior experience. ***

German, for example, has the ridiculously clumsy grammar of
putting the verb at the end and concatenating adjectives onto
nouns: "Ein Schwartz-Wald-Spatzieren-Gehen" = "A Walk in
the Black Forest" .. literally "A Black Forest Walk Going"
(FYI: a famous jazz number from the '60s).

I'd probably fall over laughing at how stupid French is :)

Except .. I happen to know English is the most absurd language
around. It just happens to be my native language so I'm used 
to it.

** it's likely I'll get a type error and become very confused,
but that is much better than not getting a type error, which is
quite possible if everything is returning unit.

*** when I designed Felix I made a decision that the grammar
had to be LALR1 and entirely unambiguous, a choice easily
enforced by using Ocamlyacc (without any %prec rubbish,
and by grepping the .output to make sure there were
no shift/reduce conflicts).

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] If OCaml were a car

[Joerg van den Hoff]

On Mon, Aug 20, 2007 at 04:26:24PM +1000, skaller wrote:
> On Mon, 2007-08-20 at 04:37 +0100, Jon Harrop wrote:
> 
> > >
> > > The thing is that 'else' has a different 'precedence' than 'then'.
> > > So you can write:
> > >
> > > 	if e then e1 else a; b; c
> > >
> > > and a,b,c are all executed if the condition is false,
> > 
> > I do not believe this is true. The "b" and "c" are executed in both cases 
> > because the above is parsed as:
> > 
> >   (if e then e1 else a); b; c
> > 
> > which is syntactically uniform:
> > 
> > # (<:expr< (if true then a else a);b;c >>) =
> >   (<:expr< if true then a else a;b;c >>);;
> > - : bool = true
> > 
> > Perhaps you were thinking of this:
> > 
> >   if p then t else
> >     let () = () in
> >     f1;
> >     f2;
> >     f3
> > 
> > because "let" binds more tightly.
> 
> Well there you go! I've been writing Ocaml almost 10 years and 
> didn't know that. Here's my real code:
> 
>     if ret = `BTYP_tuple [] then "// elided (returns unit)\n","" else
>     let funtype = fold syms.dfns (`BTYP_function (argtype, ret)) in
> 
> I guess I'm just lucky. From what you say, the grammar is exceptionally
> bad: the scope of the 'else' is *extended* by the let/in non-terminal
> so it goes past ';' -- that should be a syntax error. 
> 
> Roughly a 'loosely' binding operator is extending the scope 
> of a 'tightly' binding operator: doing that is fragile. For example
> if I drop the 'let .. in' part the semantics may** change silently.
> 
> The 'right' way to extend a scope is to use an scope extension 
> operator with no semantics, such as ( .. ) or begin .. end,
> or $ in Felix in Haskell.
> 
> But please note: just because I present this analysis doesn't mean
> I believe it 100%. Contrarily .. it is just a data point. It has
> to be weighted against other factors: every syntactic form has
> both advantages and disadvantages, and it is very dependent
> on the client's prior experience. ***
> 
> German, for example, has the ridiculously clumsy grammar of
> putting the verb at the end and concatenating adjectives onto
> nouns: "Ein Schwartz-Wald-Spatzieren-Gehen" = "A Walk in
> the Black Forest" .. literally "A Black Forest Walk Going"
> (FYI: a famous jazz number from the '60s).

as a ocaml novice I probably would'nt have mailed to this list any time
soon and I'm afraid this goes off at a tangent, but anyway: I won't
argue against your (probably not so well founded?) assessment of a
'ridiculously clumsy grammar', still what you wrote down as being a
german sentence is not even the equivalent to pidgin english. "a walk
in the black forest" would simply be "ein Spaziergang im Schwarzwald"
with a nearly one-to-one correspondence of the words. "Walking in the
black forest" would be "im Schwarzwald spazieren gehen", possible
tranlation: "taking a walk in the black forest". to be sure, there
_are_ some grammatical idiosyncrasies (cf. e.g. a rather funny small
polemic written by mark twain, I believe) -- or so it must seem to
non-native speakers. so much in defense of my native language :-).
apologies for this intrusion...

> 
> I'd probably fall over laughing at how stupid French is :)
> 
> Except .. I happen to know English is the most absurd language
> around. It just happens to be my native language so I'm used 
> to it.
> 
> ** it's likely I'll get a type error and become very confused,
> but that is much better than not getting a type error, which is
> quite possible if everything is returning unit.
> 
> *** when I designed Felix I made a decision that the grammar
> had to be LALR1 and entirely unambiguous, a choice easily
> enforced by using Ocamlyacc (without any %prec rubbish,
> and by grepping the .output to make sure there were
> no shift/reduce conflicts).
> 
> -- 
> John Skaller <skaller at users dot sf dot net>
> Felix, successor to C++: http://felix.sf.net
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] If OCaml were a car

[Florian Hars]

Joerg van den Hoff schrieb:
> german sentence is not even the equivalent to pidgin english. "a walk
> in the black forest" would simply be "ein Spaziergang im Schwarzwald"
> with a nearly one-to-one correspondence of the words. 

But if you wanted to know where to take your walk in the Schwarzwald, you
would need a Schwarzwaldspaziergangsempfehlung.

Yours offtopicly,
Florian.

Re: [Caml-list] If OCaml were a car

[skaller]

On Mon, 2007-08-20 at 04:37 +0100, Jon Harrop wrote:

> Why should the return value (of unit) not be used as the argument to an 
> application?

Because functions returning unit are always executed for side-effects
since unit conveys no information, so allowing a procedure to be
used as an argument means the order of side effects depends on
implementation dependent argument evaluation ordering, that is,
it is indeterminate.

In Felix banning side-effects from functions allows optimisations
Ocaml will have a much harder time applying, since Felix
bans side-effects from functions, and the type system helps
by requiring procedures to return the vacuous type void.
[But this still doesn't give referential transparency ;]

> > 	print$ "Hello" + " World";

> You might prefer the F# operators |>, << and >>.

I might. But I'll use what Inria provides.

>  I'd much rather 
> see effort go into an IDE rather than tweaking the syntax and breaking 
> backward compatibility.

I'd never use the IDE.. so I'd rather the effort be going into

	(a) the type system, parallelism, etc -- which it is!
	(b) libraries -- which it isn't ;(


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] If OCaml were a car

[Oliver Bandel]

Zitat von Daniel Bünzli <daniel.buenzli@epfl.ch>:

> Maybe I ride this car too often to realize (or I'm dumb) but I don't
> get the joke about controls.
[...]

I would think this is only a joke from an american person about
french cars?
On which side do they drive in USA, and on which in french?
So the controls are on the other side.

But possibly this also was meant on the Stdlib's
order of arguments in functions like List.map, List.iter and so on.
Some people meant that the order of the args were wrong,
making complex code some more complicated (for partial application
orsimilar techniques).

But I really enjoy OCaml all the days again.
It seems to me, that the people here on the list
have a funny live to choose the langauge they want,
and because of that they have forgotten, how cool OCaml is,
compared to so mancy other languages.

When I remember Perl, which I often have to work with,
because there are a lot of Perl projects but no Ocaml projects
outside on the amrket, I always know, how ugly langauges
can be.

So, the problems with which OCaml comes along are really minor
to what languages in IT-business offer....

Maybe in universities or at home you can choose
any language you want, but a lot of money-projects
need to be done in ugly langauges.

So, that's the reason why I don't forget, which advantages
OCaml offers.

So, if you see only the holes inside the cheese,
can you enjoy eating the cheese?

I enjoy it. And: OCaml-cheese IMHO tastes good and does NOT stink,
even if the people on the list here talking about it as if it would
stink.

If you want to have a strange smell, look for what languages
have to be used in so lot IT-projects. The peoples even don't know what OCaml
is!

When I mention it, I got strange look from people,
they maybe think I'm like a script kiddie with a new toy.
But they want that one uses ugly languages.

Compared to that the discussions on OCaml's defficiencies are
incomprehensible to me.

Ciao,
   Oliver

RE: [Caml-list] If OCaml were a car

[David Allsopp]

> > Maybe I ride this car too often to realize (or I'm dumb) but I don't
> > get the joke about controls.
> [...]
> 
> I would think this is only a joke from an american person about
> french cars?
> On which side do they drive in USA, and on which in french?
> So the controls are on the other side.

Erm, I think you'll find that the French, Americans (and Germans) all drive
on the same side of the road?


David [who drives on the correct, not right, side of the road ;o)]

RE: [Caml-list] If OCaml were a car

[Ulf Wiger (TN/EAB)]

 
David Allsopp wrote:
> 
> > I would think this is only a joke from an american person 
> > about french cars?
> > On which side do they drive in USA, and on which in french?
> > So the controls are on the other side.
> 
> Erm, I think you'll find that the French, Americans (and 
> Germans) all drive on the same side of the road?

I would assume that this is a leftover from the time when
Citroën dashboards bore little resemblance to those of 
other cars.

(Example: http://en.wikipedia.org/wiki/Image:Citroen_CX_dashboard.JPG)

The Citroëns were of course (and still are) superior cars. ;-)

BR,
Ulf W
(proud owner of two Citroën XM)

Re: [Caml-list] If OCaml were a car

[Joerg van den Hoff]

and there was a time, when french cars had the direction indicator on
the right of the steering wheel and the column gear shift on the left.

On Mon, Aug 20, 2007 at 10:50:52PM +0200, Ulf Wiger (TN/EAB) wrote:
>  
> David Allsopp wrote:
> > 
> > > I would think this is only a joke from an american person 
> > > about french cars?
> > > On which side do they drive in USA, and on which in french?
> > > So the controls are on the other side.
> > 
> > Erm, I think you'll find that the French, Americans (and 
> > Germans) all drive on the same side of the road?
> 
> I would assume that this is a leftover from the time when
> Citroën dashboards bore little resemblance to those of 
> other cars.
> 
> (Example: http://en.wikipedia.org/wiki/Image:Citroen_CX_dashboard.JPG)
> 
> The Citroëns were of course (and still are) superior cars. ;-)
> 
> BR,
> Ulf W
> (proud owner of two Citroën XM)
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

RE: [Caml-list] If OCaml were a car

[Oliver Bandel]

Zitat von David Allsopp <dra-news@metastack.com>:

> > > Maybe I ride this car too often to realize (or I'm dumb) but I don't
> > > get the joke about controls.
> > [...]
> >
> > I would think this is only a joke from an american person about
> > french cars?
> > On which side do they drive in USA, and on which in french?
> > So the controls are on the other side.
>
> Erm, I think you'll find that the French, Americans (and Germans) all drive
> on the same side of the road?
[...]

Ooops, so it was UK....
...then maybe caltech.edu must be british, ;-)

          (...well, geographics never was my cup of tee ;-) )

or if not, it was really meant to to the Standardlib to drive
the wrong side? ;-)

Ciao,
   Oliver

P.S.: In Japan the also drive on the left side.

P.P.S.: Oh, I found this map on Wikipedia (sorry, german language,
        but colored):
        http://de.wikipedia.org/wiki/Bild:RechtsverkehrUndLinksverkehr.png
        In the corresponding article they wrote, that French had left-sided
        driving before Napoleon, but that in USA in the beginning they also
        drove on the left side (British Influence).
        So, really complicated thing...

        So, what does this say about OCaml?
        Does the time functions of OCaml's Unix-module count the seconds
        backward?

P.P.P.S.: http://de.wikipedia.org/wiki/Bild:London_Look_Right.jpg

Re: [Caml-list] If OCaml were a car

[skaller]

On Mon, 2007-08-20 at 21:54 +0200, Oliver Bandel wrote:

> Compared to that the discussions on OCaml's defficiencies are
> incomprehensible to me.

Unfortunately not so. The syntax is only a minor issue IMHO.
There are a number of other annoyances. But the major issues are:

(1.a) lack of dynamic loading (of native code) 
    -- hopefully to be fixed in 3.11

(1.b) lack of multi-processing

(2.a) interoperability
    -- with C libraries
    -- with .NET libraries (F# isn't Ocaml)

(2.b) refusal of Inria team to provide a more complete library

(3) lack of ISO or ECMA standardisation

We who use Ocaml are patient (fixes 1),
creative (fixes 2), and trusting (fixes 3),
which are three properties industry does not have.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] If OCaml were a car

[Oliver Bandel]

Zitat von skaller <skaller@users.sourceforge.net>:

> On Mon, 2007-08-20 at 21:54 +0200, Oliver Bandel wrote:
>
> > Compared to that the discussions on OCaml's defficiencies are
> > incomprehensible to me.
>
> Unfortunately not so. The syntax is only a minor issue IMHO.
> There are a number of other annoyances. But the major issues are:
>
> (1.a) lack of dynamic loading (of native code)
>     -- hopefully to be fixed in 3.11
[...]

Would be fine, but is not that necessary.



>
> (1.b) lack of multi-processing

You mean parallelization on many processors?

Well, Unix.fork could help, or OCamlP3l.



>
> (2.a) interoperability
>     -- with C libraries
>     -- with .NET libraries (F# isn't Ocaml)

What do you mean with interoperability here?
You have the possibility to marry C and OCaml,
and it's relatively easy, compared to Perl
for example (which is very ugly with that XS-stuff).


>
> (2.b) refusal of Inria team to provide a more complete library

I do not really miss a lot in the library.
Some more functions would be fine, but the missings
are not so big, IMHO.
People could add some items in the bug-database as feature wishes.
If the wishes make sense, I think, they possibly will be implemented.

But it does not make sense to ask for a complete rewrite.
It takes too much time, does not bring so much advantages
and stops them working at other things.
So, if some really necessary things should be added,
a feature-wish would make sense IMHO.
And that must be concrete saying, what and why it is missed.
Not something like "rewrite the lib, it misses so much".


>
> (3) lack of ISO or ECMA standardisation

That would be fine, yes.


>
> We who use Ocaml are patient (fixes 1),
> creative (fixes 2), and trusting (fixes 3),
> which are three properties industry does not have.

Does Perl have an ISO-standard?
Or the ugly Visual Basic, which some big companies
really are using?

I think an ISO-standard could be fine, but it is not
the criteria, why companies decide to use a language.

IMHO, many (most) things that are used in industry are really bad
things. And people insist on using bad langauges and bad systems,
because they are accustomed to it, and some Lobbyists
sell that stuff.

But also, because certain tools will only be deklivered on
certain systems (thoose ugly things). (But this I can understand
as a reason, because somehow the work must be done.)

Ciao,
   Oliver

Re: [Caml-list] If OCaml were a car

[skaller]

On Tue, 2007-08-21 at 11:51 +0200, Oliver Bandel wrote:
> Zitat von skaller <skaller@users.sourceforge.net>:

> > (1.a) lack of dynamic loading (of native code)
> >     -- hopefully to be fixed in 3.11
> [...]
> 
> Would be fine, but is not that necessary.
> 

It's absolutely mandatory. Just consider a web browser executing 
compiled client script to see this.

> >
> > (1.b) lack of multi-processing
> 
> You mean parallelization on many processors?

Yes.

> Well, Unix.fork could help, 

No, it can't "help": some applications can be built that way,
with suitable message passing protocols. Others required 
shared data. 

Also note, you can't effectively use both threads and (forked)
processes because Unix is a mess. Quite a few applications use
threads, which precludes forking (completely separate processes
are OK of course).

> or OCamlP3l.

Indeed, but that's not Ocaml.

> > (2.a) interoperability
> >     -- with C libraries
> >     -- with .NET libraries (F# isn't Ocaml)
> 
> What do you mean with interoperability here?

Sharing data and control across language boundaries.

> You have the possibility to marry C and OCaml,
> and it's relatively easy, compared to Perl
> for example (which is very ugly with that XS-stuff).

It's extremely hard, and it's very expensive, compared to
sharing between C and C++, or C++ and Felix, or between
any .NET languages.

Perhaps by easy you mean the effort to handle "two functions".

Now try to wrap a library like GTK with hundreds or even 
thousands of functions!

> > (2.b) refusal of Inria team to provide a more complete library
> 
> I do not really miss a lot in the library.
> Some more functions would be fine, but the missings
> are not so big, IMHO.

Lots of really basic things are missing, for example re-entrant
regular expressions, variable length arrays, doubly linked lists,
sequential hash tables, and a heap of other data structures which
are either basic, or common in other systems.

> Does Perl have an ISO-standard?

Perl is dead.

> Or the ugly Visual Basic, which some big companies
> really are using?

No idea, but most of the new Microsoft offerings have
ECMA standards backing either extant or planned.

> I think an ISO-standard could be fine, but it is not
> the criteria, why companies decide to use a language.

Often it is. Do you know why C++ was standardised? Because
(I think it was Hewlett Packard) wanted to do some 
USA Federal Government contractsusing it, and an ANSI 
Standardised language was a requirement of the contracts.

Many big military contracts mandate Ada. Standards are
vital for big projects.

> IMHO, many (most) things that are used in industry are really bad
> things. And people insist on using bad langauges and bad systems,
> because they are accustomed to it, and some Lobbyists
> sell that stuff.

Many of the industrially used languages are not so good:
it's annoying the designers don't listen to academia.

But then, the academics don't bother to listen to industry
either .. :)


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] If OCaml were a car

[Richard Jones]

On Tue, Aug 21, 2007 at 08:30:28PM +1000, skaller wrote:
> On Tue, 2007-08-21 at 11:51 +0200, Oliver Bandel wrote:
> > Zitat von skaller <skaller@users.sourceforge.net>:
> > > (1.b) lack of multi-processing
> > 
> > You mean parallelization on many processors?
> 
> Yes.
> 
> > Well, Unix.fork could help, 
> 
> No, it can't "help": some applications can be built that way,
> with suitable message passing protocols. Others required 
> shared data. 

This might come back and bite you in a couple of years you've got 16-
and 32-core processors and you find your parallel GC / operating
system really don't scale.

> Now try to wrap a library like GTK with hundreds or even 
> thousands of functions!

I certainly won't argue on this count.  I've been chasing the libvirt
API for a few months and even though it only has 50 or so functions,
it's more painful than it should be.

Of course GTK _has_ been wrapped, thanks to the tireless efforts of
the lablgtk team.  And the binding is a good one too.

One interesting thing I've learned from working with people on the
GNOME team is that in fact there is no shortage of manpower in the
free software world (people prepared to do repetitive grunt work,
reimplement stuff endlessly and so on), but there is a big shortage of
people who understand anything beyond C and maybe Python.  Python is
the Visual Basic of the free software world, believe me.

> > > (2.b) refusal of Inria team to provide a more complete library
> > 
> > I do not really miss a lot in the library.
> > Some more functions would be fine, but the missings
> > are not so big, IMHO.
> 
> Lots of really basic things are missing, for example re-entrant
> regular expressions, variable length arrays, doubly linked lists,
> sequential hash tables, and a heap of other data structures which
> are either basic, or common in other systems.

As I've said before, this is a packaging problem.  Can you not bundle
private copies of the libraries you need in with felix?

> > Does Perl have an ISO-standard?
> 
> Perl is dead.

Hum, well.  Perl is far more widely used than OCaml.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] If OCaml were a car

[skaller]

On Tue, 2007-08-21 at 19:57 +0100, Richard Jones wrote:
> On Tue, Aug 21, 2007 at 08:30:28PM +1000, skaller wrote:

> This might come back and bite you in a couple of years you've got 16-
> and 32-core processors and you find your parallel GC / operating
> system really don't scale.

Wrong approach IMHO. There are physical limits on localisation:
the speed of light and Heisenberg's constant. We know from
simple observation of organic systems, that systems clump
at various levels.

This means we need multiple mechanisms of sharing, for example,
to use BOTH shared memory threads and message passing. Indeed,
we use 'fast' message passing to implement 'slow' sharing
right now: isn't that what cache interconnects do already?

It's not an 'either/or' thing. It will not be 'either message
passing or shared memory'. It will always be a mixture of both
with 'layered' levels of granularity/abstraction.

The smart modern CPU programmer can use random access data 
structures but keeps cache locality in mind for performance.
[See Judy Array for an interesting example of this.]
[The smart Erlang programmer probably does the opposite..
funnel messages to local ports where possible]

> One interesting thing I've learned from working with people on the
> GNOME team is that in fact there is no shortage of manpower in the
> free software world (people prepared to do repetitive grunt work,
> reimplement stuff endlessly and so on), but there is a big shortage of
> people who understand anything beyond C and maybe Python.  Python is
> the Visual Basic of the free software world, believe me.

I know. The Felix build system and LP tool is pure Python, the Felix
libraries are C++, and the compiler is Ocaml: the Ocaml part is the
biggest language obstacle to participation ;(

> > > > (2.b) refusal of Inria team to provide a more complete library

> As I've said before, this is a packaging problem.  

Yes indeed. And that's my point.

> Can you not bundle
> private copies of the libraries you need in with felix?

I do. Elkhound, Tre, Judy are all bundled as source code.
[But BSD like licence is mandatory.]

> > > Does Perl have an ISO-standard?
> > 
> > Perl is dead.
> 
> Hum, well.  Perl is far more widely used than OCaml.

But Ocaml is alive, changing, and growing. Perl has been
on the way down for years. Once, every web site offered Perl
as a scripting language. This annoyed Python people :)
But then PHP took over. And now Ruby on Rails is taking over.
Perl is now an arcane language for aging Unix hippies who
fondly remember it is much better than awk and sed.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] If OCaml were a car

[Thomas Fischbacher]

John Skaller wrote:

>>This might come back and bite you in a couple of years you've got 16-
>>and 32-core processors and you find your parallel GC / operating
>>system really don't scale.
> 
> Wrong approach IMHO. There are physical limits on localisation:
> the speed of light and Heisenberg's constant. We know from
> simple observation of organic systems, that systems clump
> at various levels.

If one look e.g. at the distribution function of something like
the size of debian packages, one will find that it follows a power
law (dN/N(size) ~ a*size^b) remarkably well over multiple orders of
magnitude. Similar distributions can be observed for many systems.

There are deep fundamental reasons that tell us that we should expect
something like this on very general grounds whenever three things
come together:

(1) We have "frustration" in the system in the sense that there are
multiple stable configurations, and lots of them.

(2) The system's constituents are linked up in such a way that reducing
the "internal stress" in one place increases the internal stress in its
neighbourhood, and

(3) The individual components are networked in an effectively
more-than-one-dimensional way. (So, the number of nodes reached
increases with the number of hops.)

These are very general properties that come together in many different
systems. Now, in 1987 a bunch of theoretical physicists (Bak, Tang, and
Weisenfeld) had a deep insight that whenever this happens, then all the
interesting distributions one can derive from such a system should
turn out to follow power-law behaviour. (The key idea is to look at the
weakest condition that gives stability, which will determine the
system's structure, as every stronger condition would constrain
configuration space too much.)

In essence, Perl did two things right: (1) It properly acknowledged that
most problems are small problems that should be resolvable as a one-line
job (unlike C++ which believes all problems to be huge tasks - if they
are not, they first have to be turned into one so that one then can use
C++ to solve them), and (2) it also acknowledged that human language is
irregular in some funny but far from chaotic way, and tried to mimick
some of that irregularity in order to make programming more natural and
hence less tiring.

Quite in general, what deeply worries me (in programming as well as in
a much broader context concerning how our present-day society works)
is that we do not pay proper respect to these fundamental mechanisms
that always cause activity on a variety of different scales. When
making decisions, our reasoning all too often starts out from
false assumptions on scale distributions of system sizes. In
particular, we often design our systems based on assumptions of
extreme scales (say, extreme centralization or extreme
decentralization) rather than "reasonable assumptions about
natural distributions". That is fundamentally wrong, and
Thermodynamics/statistical mechanics can even prove this. :-)

-- 
best regards,
Thomas Fischbacher
tf@functionality.de

Business Adoption of Ocaml [was Re: [Caml-list] If OCaml were a car]

[Robert Fischer]

(This is an on-topic post, but it's going to take a while for me to get 
there: scroll down.)

Oliver Bandel wrote:
> IMHO, many (most) things that are used in industry are really bad
> things. And people insist on using bad langauges and bad systems,
> because they are accustomed to it, and some Lobbyists
> sell that stuff.
>
>   
This is an academic conceit, which isn't really fair.  The problem is 
that what academics consider "really bad things" and what industry 
considers "really bad things" are two very different things.  The 
criteria for judging languages are simply different.

To business, picking a language or a framework is a matter of 
prognostication.  Few businesses are willing to carry an unsupported 
library or language, or want to be exposed to the dangers of an 
uncontrolled library, so they need to pick languages and libraries that 
have a lifespan.  They don't want to perform expensive experiments to 
see if a new language or paradigm is really going to help.  And things 
being open source makes the situation worse, not better: by actually 
spending money on things, you gain a legalistic and business protection 
-- at the level of management, contractual guaranties are nearly as good 
as reality.  And, even more, it's important to pick a popular language, 
because popular languages have a wide variety of developers to choose 
from, which makes growth a lot cheaper.

Note that none of these qualities have anything to do with the 
efficiency of the language, both in terms of processing efficiency or 
development efficiency.  They're business concerns, coming from a very 
different context.

If we want more commercial adoption of Ocaml, we need to see more 
companies (like Jane Street) which are willing to take the risk and 
adopt Ocaml.  Their successes, and the community that they are building, 
need to be advertised.  Business needs to believe that the language (or 
close derivations thereof) is here for the long haul, and that it either 
is or presently will be widely adopted.

One good way of handling this is to find and grow a niche -- this was 
the approach that Ruby on Rails has taken.  Yet it's notable that Groovy 
on Grails, by virtue of it being "basically Java" and interoperable with 
large swaths of existing application code, is posing a significant 
threat to the corporate adoption of Ruby on Rails.

I'm not sure if Ocaml has such a niche to grab onto, and it isn't 
already a popular language, so as much as I'd love to see its widespread 
adoption, I'm not holding out a lot of hope.  I think the one major 
niche we could get into is concurrency (like Brian's deferred 
monad/futures* or jocaml), but the main language isn't there yet.

* http://enfranchisedmind.com/blog/archive/2007/08/13/323

~~ Robert.

Re: Business Adoption of Ocaml [was Re: [Caml-list] If OCaml were a car]

[Brian Hurt]

Robert Fischer wrote:

>
> I'm not sure if Ocaml has such a niche to grab onto, and it isn't 
> already a popular language, so as much as I'd love to see its 
> widespread adoption, I'm not holding out a lot of hope.  I think the 
> one major niche we could get into is concurrency (like Brian's 
> deferred monad/futures* or jocaml), but the main language isn't there 
> yet.
>
> * http://enfranchisedmind.com/blog/archive/2007/08/13/323


For the record, this idea isn't mine.  I'm stealing the idea (immature 
artists immitate, mature artists steal) from Stephen Weeks and David 
Powers here, and I think they're stealing the idea from somewhere else.

Of course, this requires programmers to *think* differently.  Not 
something many programmers are willing to try (thinking, that is), in my 
experience.  Especially not blub programmers.

While we're trading blog posts, I'd also point out:
http://weblog.raganwald.com/2007/08/bricks.html
http://weblog.raganwald.com/2007/05/not-so-big-software-application.html

Brian

Re: [Caml-list] If OCaml were a car

[brogoff]

On Tue, 21 Aug 2007, skaller wrote:
> On Mon, 2007-08-20 at 21:54 +0200, Oliver Bandel wrote:
>
> > Compared to that the discussions on OCaml's defficiencies are
> > incomprehensible to me.

Since we're dealing with analogies, you could say Perl is like some
hideous disfigured mutant leper. Really, who is going to notice a
few warts on that? OCaml is a puclchritudinous visage pocked with
some blemishes.

> Unfortunately not so. The syntax is only a minor issue IMHO.

Minor for you, but for less expert programmers, or those new to or
infrequent OCaml users, they weight the decision "OCaml or Other"
in the wrong direction.

> There are a number of other annoyances. But the major issues are:
>
> (1.a) lack of dynamic loading (of native code)
>     -- hopefully to be fixed in 3.11
>
> (1.b) lack of multi-processing
>
> (2.a) interoperability
>     -- with C libraries
>     -- with .NET libraries (F# isn't Ocaml)
>
> (2.b) refusal of Inria team to provide a more complete library
>
> (3) lack of ISO or ECMA standardisation
>
> We who use Ocaml are patient (fixes 1),
> creative (fixes 2), and trusting (fixes 3),
> which are three properties industry does not have.

Note that none of your issues are about the language itself, except
(1.b).

Different industries have different priorities, and a few of your
annoyances are  of no concern to me, as I imagine some of mine don't
bother you.

-- Brian