Re: [boost] Re: Review Request: FC++

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-10-08 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 compiler-warnings 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])