Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re[2]: [Caml-list] Custom operators in the revised syntax
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: dmitry grebeniuk <gds-mlsts@m...>
Subject: Re[2]: [Caml-list] Custom operators in the revised syntax
Hello, Nicolas.

>> > Something general like: x `foo` y ?
>> Exactly.

NP> I've a tiny patch to do that:

NP> 2 ``List.mem`` [1;2;3]

  Sometimes it is very convenient (``map`` and function
compositions are good examples).  But I prefer syntax
where one thing should be done in one way (that's why
I prefer revised syntax -- lesser ambiguities than in
original syntax).  And the principle "there is more than
one way to do it" is good for "weak" languages such as
perl and bash and not for "strict" languages of ML family.
  I agree that "bad programmer will write unreadable code
in any language/syntax", but it's better not to give
to programmer any choices when it there is no need --
when the choice does not affect the result (for example,
usually people don't need to think about whether they
should write "fun .. -> .." or "function .. -> ..").
  And one more "against" point: using infix notation for
functions allows to write "ad hoc"-code, which can grow
enormously.  In the original version of code there can be
only "arg1 ``myfunc`` arg2", but it can grow to
"(some complex expression1) ``some other things`` (some
other expression)" over several lines.  It can be compared
to perl's "post-conditions":
"<do_something> if <condition>".
  And, again, precedence and associativity: some people
will want "a ``b`` c ``d`` e" to work as
"(a ``b`` c) ``d`` e", some people -- as
"a ``b`` (c ``d`` e)", and which interpretation is correct?
The result of "1 ``(fun x y -> 2*x + 3*y)`` 2 + 3" will be
1*2+2*3+3 or 1*2+3*(2+3)?  And every programmer must keep
these things in the head to write and understand caml code.
  However, do anything you want, but please don't turn ocaml
into perl, or, omg, haskell.

-- 
WBR,
 dmitry                          mailto:gds-mlsts@moldavcable.com