Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] semi-colons and begin
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: mahamud@c...
Subject: Re: [Caml-list] semi-colons and begin
>>>>> ">" == Chris Hecker <checker@d6.com> writes:

    >> However, in the O'Caml manual there is a precedence table
    >> (section 6.7) determining that "if" has higher precedence than
    >> ";". So the first way is what the compiler interprets.

on an unrelated point, speaking of precedence rules,
is there a good reason why unary minus for floats (-.) has higher 
precedence than power of (**). i think the usual precedence is the
other way. atleast this is what i'm used to in languages that are
primarily numerically oriented like matlab. i've been caught by this 
quite a few times. 

another minor point regarding syntax : 
the use of "(* ... *)" prevents one from passing the multiplication
"*" operator as an argument (say to List.map2) without 
padding some space as in : ( * ) as opposed to (*).
it's a small point, but i don't think i've come across such unintended
interactions between comments and other constructs in other languages.

while i still have your attention, one last comment :
as you may have guessed i primarily use OCAML for writing code that
mostly do number crunching. i know you've all seen others writing similar
code beg for something like overloading. and i want to chime in too
for what its worth : why can't OCAML do what SML does ? 
overload the standard arithmetic operators to do both int and double
and assume a default type if the type can't be inferred.
this would i think avoid the majority of annoyances for people who use OCAML
for number crunching. I don't know if there is a deep issue involved 
that prevents OCAML from doing what SML does, but it seems inconsistent 
from a user's viewpoint that for eg. the comparison operators are allowed to
be overloaded but not the arithmetic operators. perhaps the comparison 
operators are easier to overload since the result returned always has the same
type ?

- shyjan


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr