Re: [boost] Re: FC++ -- reminder formal review ends today at midnight PST

From: Brian McNamara (lorgon_at_[hidden])
Date: 2004-03-02 06:42:52

Thanks for your comments.  A few quick replies to questions:

On Mon, Mar 01, 2004 at 10:10:15PM -0800, Jared Roberts wrote:
> I've been generally impressed with the design.  There are a few things 
> that bother me.  I dislike having to manually promote direct functoids 
> to full functoids.  This is particularly sticky if the functoid is 
> recursive, as above.  I worked around this at (A) by using a lambda 
> variable to hold the full functoid, but I would have thought there was a 
> better way.  If there is, I didn't see it in the documentation.  I also 

For recursion, you can always just say "make_full1(*this)", but that's
still a little big/ugly; it would be nice if you could just say
"*this".  Alternatively, you can define the whole algorithm inside
lambda and use "letrec" to create a recursive function definition.

> One thing in particular that seems to have been overlooked by some 
> others about the lambda variables is that they allow you to do a fair 
> amount of type inference!  Looking again at the quicksort example, 
> rather than worry about types, I just declared everything lambda and the 
> compiler was able to figure everything out.  This is true even for 
> qs_rec, which is bound to the full-functoid version of quicksort to be 
> used in the recursive step at (B).  FC++ is able to figure all this out, 
> even though qs_rec isn't bound when declared.  It's not quite "auto", 
> but it's pretty cool!

Indeed!  I'd never really considered FC++'s lambda/let as a stop-gap
solution for the proposed "auto" type inference, but it does kinda
accomplish this.

> (side note:  Is there any reason the lambda() has to be there at all? 
> It seems a bit silly to define a lambda and then immediately evaluate 
> it.  Shouldn't the let ideally be able to suffice here?)

Well, "let[...].in[...]" is a lambda expression, so you need some
operation to transform it into its value.  But yeah, wow,
   lambda()[ blah ]()
is pretty ugly/verbose, and I could easily make just
   blah()
(or something similar) work.  Good idea.

> The documentation isn't great.  [...]
> I'm still not sure, for example:  In the quicksort example again, at 
> (B), there is a recursive call "qs_rec[rights]".  Is this call 
> automatically lazy?  Or do I have to do something to it?  Earlier 
> versions of the code didn't have this part wrapped up in a lambda, and I 
> was able to do thunk1(qs_rec, rights), but I couldn't figure out what I 
> needed to do here.  My hunch is that I need to do nothing, but I 
> couldn't find anything that told me so for sure.

It is not lazy.  (More precisely, it is not lazy with respect to the
lists, which I think is what you want.  It is lazy in the sense that it
is a lambda expression, and thus will not get evaluated until the lambda
is evaluated.)

To fix it, just change

   qs_rec[lefts] %cat% (pivot %cons% qs_rec[rights])

to

   qs_rec[lefts] %cat% (pivot %cons% thunk1[qs_rec,rights])

Except, that I just tried it and this doesn't work.  Doh!  Here's a
comment in the library implementation:

   // FIX THIS: the thunkNs are not full functoids.  Oh well.  Until I find
   // a need to make them so, I'm not going through the effort.

So consider this a bug/oversight, and watch the library author
sheepishly slink away to fix it.  :)

-- 
-Brian McNamara (lorgon_at_[hidden])