Re: [boost] Review: lambda library

From: joel de guzman (djowel_at_[hidden])
Date: 2002-03-23 18:38:14

----- Original Message ----- 
From: "David Abrahams" :

> ----- Original Message -----
> From: "Gary Powell" <powellg_at_[hidden]>
> 
> > ----------------------------------
> > Ok, I think I understand your ambivalence. Let me try to clarify what
> I hear
> > are the objections (in no particular order)
> >
> > o) You'd like MSVC 6.5 compatibility.
> 
> 
> Yes. The unfortunate truth right now is that without it, LL becomes far
> less relevant to my work. If I was writing application code, it might
> not be that way, but I'm writing libraries and I can't dump MSVC6.5 yet.

And don't forget Borland 5.5.1. 

> > While I won't say its an
> > impossibility, I gave up after spending countless hours with ET and an
> early
> > version of LL. Although since then I've learned a number of useful
> > techniques for getting around the lack of template specialization.
> That
> > said, MS did the right thing and is about to release an update which
> does
> > handle LL just fine.
> 
> I doubt they're quite as close to release as you make out. They only
> just released 7.0 and people are not likely to adopt a near-complete
> rewrite like 7.1 on short notice.

Even after the release of 7.1, 6 will still be with us for a long time.
That's for sure. How many people are still using 5? Well 6 is a
good compromise I guess.
 
> > Although these should become the
> > same interface even if they are not the same underlying
> implementation, to
> > avoid user confusion.
> 
> Agreed. I think I agree with others that the default arity checking in
> bind is more appropriate than that in LL.

IMO, the rationale for strict arity checking has no teeth unless it
can catch things like this (which I still believe to be valid code):

    (_1 + _5)(a, b, c, d, e)

But it seems that it can't. Of course this can be done, but enforcing this 
will bloat the metaprogramming code more (read: longer compile times).
LL checks only for max-arity. This is not really strict arity in the true sense
of the word "strict".

Thinking about it more yesterday, I was inclined to propose a compromise 
where a #define switch can be used to switch on and off (library wide) the 
arity checking. Yet, because of the severe limitation that I mentioned above,
I'll be blunt: LL style max-arity checking does not make sense. KILL IT!
Trust the programmer.

> > Jaakko and I are talking about extending the number of
> > placeholders. That appears to be a linear task. It's just really hard
> to
> > want to put the effort in unless people are really really using it, as
> > opposed to it just being "nice."
> 
> FWIW, the moment I released Boost.Python with support for 6 arguments I
> acquired users who wanted 10 and more.

Upgrading the maximum should be done such that the users who need
only 3 arguments will not pay a compile time penalty. This can be done
by making the maximum #defineable (as was done in Phoenix). 90+%
of the users will use it with 3, max 5 arguments. With Phoenix:

    #define PHOENIX_LIMIT 5  // currently 3..15

With Phoenix, implementation wise, not a single macro was used. Macros 
cause more trouble than its worth, regardless if they are used only in 
the implementation. A very early version of the framework did use 
macros to generate redundant code. The experience was to say the 
least, painful. 1) The code is so much more difficult to read 2) Compile 
errors take you in the middle of nowhere in a meaningless macro 
invocation without the slightest clue whatsoever what went wrong. The 
bottom line is: Macros are plain ugly. Exclamation point! No to 
macros. Period.

{{ BTW, I hear that there are some broken preprocessors that choke
on recursive macros?? Yet another reason? }}

> No, I agree. However, one reason for me to wait is that I still need to
> support platforms that LL does not. I may yet vote positively, but I'm
> not voting negatively because I don't want everyone else to have to
> wait.

Same here.

Regards,
--Joel