[nem-en] Parentheses

[Kamil Skalski]

On Fri, Sep 10, 2004 at 12:01:25PM +0200, Maurizio Colucci wrote:
> On Wednesday 08 September 2004 16:47, Pawel W. Olszta wrote:
> > Hello Maurizio,
> >
> > > With the ongoing update to the type inference (I read the Monologue :-)),
> > > the only thing that is holding me back from using Nemerle (instead of
> > > ocaml) is the heavy notation with too many parentheses, especially for
> > > lambdas:
> > >
> > > Nemerle:
> > >
> > > List.Map ([B()], fun (x) { x.foo });
> > >
> > > Ocaml:
> > >
> > > List.map [new B]  (fun x -> x#foo)
> >
> > I've made a little experiment and you'll probably be able to write:
> >
> >     List.Exists ([1, 2, 3, 4, 5], lambda x -> x == 3)
> >
> > The (very simple) `lambda' (as the `fun' keyword is already taken and
> > our parser can't differentiate between the two constructions
> > automatically yet) macro should make it to tonight's snapshot unless I
> > fail to convince Kamil, who's opposing to pollute the language with
> > such syntactic sugar.
> 
> Very nice :-). What is the syntax for functions that take more than one 
> argument? 
> 
> 
>   lambda x y -> x+y 
> 
> ?

Only one argument is available in this macro (and there is currently no
easy way to extend it). It will probably be possible to do in future. 

> 
> >
> > > I understand the syntax is meant to be similar to C#, but this should be
> > > taken into consideration. Does nobody feel this as a problem?
> >
> > Personally, I am a natural born LISP person :)
> >
> > > PS: Even better would be:
> > >
> > > List.Map [B()]  (fun x -> x.foo);
> > >
> > > but I understand this would make too much of a change.
> >
> > This looks like partial application to me and we're not supporting that.
> 
> No, no, it's not a partial application: Map requires two arguments and two are 
> given. What gave you that impression? 

http://www.haskell.org/hawiki/PartialApplication
Actually partial application is performed here, first [B()] is applied
to List.Map, resulting in a function, which takes other function as its
argument and applies it to already supplied list ([B()]). If you write
full expression like 'List.Map [B()]  (fun x -> x.foo)' application is
performed twice, first [B()] to List.Map, then (fun...) to (List.Map
[B()]).

Consider following code:
def f = List.Map [B()]  // oops, ; missing here
bar ();
foo (f);

You end up with weird error message about appling result of bar () to
functional value  ('a -> 'a) -> list <'a>  (the type of List.Map [B()])
This argument is also described in 
http://www.nemerle.org/rationale.html#call-parens

Note, that you can perform partial application in Nemerle by
fun (f) { List.Map ([B()], f) }

> It was just an attempt to write a ocaml/clean/haskell-like syntax (see the 
> ocaml example above). With this notation, what in nemerle you write
> 
> f(x, g(x, y, h(z)))
> 
> becomes
> 
> f x (g x y (h z))
> 
> See how much nicer it is to the eye? ;-)

actually I never liked that notation (well, it's my opinion, and
actually did not like it till I began to fully understand, that it is
partial application).

And see how error prone and hard to distinguish what exatly is playing
part of function / argument here.

> 
> > > PPS: And what about removing () from B()?
> >
> > You need the () to differentate the construction of an instance of
> > type B from referencing the type B. Moreover the `B ()' notation is
> > consistent with the rest of the language.
> 
> Right. 
> 
> > And I'd hate to see `()' being replaced by the `new' keyword, it seems
> > redundant to me as you have to write the parens anyway if the called
> > constructor has any parameters ;]
> 
> Unless you adopt the above notation, where instead of 
> 
>   f(a, g(x, y));
> 
> you write
> 
>   f a (g x y);
> 
> Are there any reasons not to? (other than similarity to C#)
> 
> > Thanks to your feedback, I have a feeling that this topic is going to
> > attract a lot of attention :)
> >
> > Pawel Olszta
> 
> :-)
> keep up the good work.

BUT, probably with new syntax extender the partial application syntax
could be written us macro. You can then simply keep a new language in
your project's library (if it would not get into mainstream language /
compiler).

Kamil Skalski