
Boost : 
From: Brian McNamara (lorgon_at_[hidden])
Date: 20031008 17:56:20
On Wed, Oct 08, 2003 at 03:54:25PM 0400, David Abrahams wrote:
> My next comment:
>
> lambda(X)[ let[ Y == X %plus% 3,
> F == minus[2]
> ].in[
> F[Y]
> ]
> ]
>
> a. Is there a *reason* that square brackets have to be used for
> postfix function args in lambdas?
I'm not sure exactly what you are asking.
We chose this syntax because
 you need to choose _some_ alternate syntax (to go with the alternate
semantic: rather than "call function now", "bind up all the info so
it can be called later when the lambda is invoked")
 this syntax seemed to be among the most "intuitive", in that lambda
expressions look similar enough to normal expressions to make it
easy for anyone to convert between one and the other (see the DPCOOL
paper [McN&Sma03] for more on our syntactic design rationale)
(Aside: Would that C++'s operator[] were able to take more than one
argument! I really despised having to overload the comma operator,
because it means that while
f[X,Y] and f[X,3] and f[2,Y]
work as expected,
f[2,3] // means f[ (2,3) ]
will surprise you if you don't have the right compilerwarnings turned
on. (Fortunately, it is rare that a subexpression in lambda contains no
lambda variables.))
Somewhere else in the thread someone commented about % vs. ^, and I'll
say now that
x ^f^ y means f(x,y)
X %f% Y means f[X,Y]
which may dispel some confusion. This should be in the docs somewhere
(I don't recall if it already is now).
I should also note as an aside that this:
X %f% Y = f[X,Y]
is not quite true. The implementation of the operator% stuff does not
resort to calling the dreaded comma operator, which means
2 %plus% 3
works as expected.
> b. It seems like
>
> lambda(X)[ let[ Y == X %plus% 3,
> F == minus[2]
> ],
> F[Y]
> ]
>
> would be a little sweeter, syntactically speaking.
I chose
let[ ... ].in[ ... ]
to mimic Haskell (again), which spells it
let ... in ...
There are a number of syntactic niceties like this which are easy to
change, and I would not object to such changes if some alternate syntax
seems favorable to the majority of people here. I would prefer to
"table" such discussions until later rounds, though, since I imagine
there may be other (bigger, harder, more important, something) issues
about FC++ which ought to take priority over these.
 Brian McNamara (lorgon_at_[hidden])
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk