Browse thread
[Caml-list] semi-colons and begin
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2001-04-05 (01:04) |
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