Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] strange behaviour of ocamldoc
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] Confused
On Wed, 2004-09-15 at 23:28, Jon Harrop wrote:
> How come this works:
> 
> # let rec build = function 0 -> [] | n -> 1e-6 :: build (n-1);;
> val build : int -> float list = <fun>
> # let test = 1. :: build 1000;;
> val test : float list = ...
> 
> But this does not:
> 
> # let rec build = function 0 -> [] | n -> 1e-6 :: build (n-1) in
>   let test = 1. :: build 1000;;
> Syntax error
> 
> Am I being stupid?

The top level let is unrelated to the expression let/in.
It just happens to use the same keyword. I'll change the 
keyword to demonstrate:

toplet x = y;;
let x = y in z;;

The first form is a toplet statement, the second is an entirely
unrelated expression statement. Note that toplet explicitly
has side-effects -- it enriches the global environment with
the symbol x. The expression statement has side-effects 
if y and z do OR if you are using the command line 'ocaml'
program (it prints the type and value).

Now rewriting your example:


let rec build = function 0 -> [] | n -> 1e-6 :: build (n-1) in
  toplet test = 1. :: build 1000;;

you can see you've used a 'toplet' in an inner location
where an expression is expected: let/in is an expression,
toplet isn't.

Basically this syntax is a 'hack' used by language
designers, overloading related syntactic forms to avoid
introducing new keywords and to make the language 
'more intuitive' - which usually backfires on newbies
and even experts at times. 

Such impurity is annoying, however a fully 'orthogonal'
syntax may well be worse. For example seeing:

int_match x with | 1 -> ..
float_match x wth | 1.2 -> ...
variant_match x with | True -> 

you can probably agree some 'pattern matching' in the compiler
itself to discriminate these cases (and allow just plain 'match')
is probably justified.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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