Boost logo

Boost :

From: Juan Carlos Arevalo-Baeza (jcab.lists_at_[hidden])
Date: 2002-03-26 19:14:50


On Tue, 26 Mar 2002 14:04:37 -0800, Gary Powell wrote:

>Asger Alstrup Nielsen wrote:
>
>So the ball is back in your court: Why should LL include the advanced
>statement and exception support? I truly hope you can convince me that it is
>a
>good idea, and that the needed language support to make it great is
>realistic
>to achieve.
>------------------------
>Gary Powell Responds:
>
>Because in small lambda programs each is extremely useful. It's when you
>concatenate _ALL_ the features together that you would have been better off
>writing a subroutine or functor.

   The problem here is where you want to draw the line. As a language or library developer, you shouldn't, IMHO. The most you should do is provide guidelines.

   I am in favor of lambda statements because it can be done, and it can be useful to the programmer and the library engineer. I don't think anyone here knows where the limits will have to be set on how far these features should be used.

   Besides, it adds to the expression capabilities of the programmer. I'd argue it adds exactly the same as allowing definition of variables anywhere in the body did for C++: it allows the programmer to put definitions (a function or functor in this case) right where it is used, instead of elsewhere. How can that possibly be bad?

   As an example of this kind of feature, I urge you to examine the OpenC++ translator. It already offers this kind of construct to be used for class libraries, usually used for for_each-style members of containers.

   And, please, don't come saying that this feature is not necessary. Of course it isn't. Classes or structures are not necessary either, for that matter ;-) but they turn out to be useful because they add to the expressivity of the language. Keep focused on that thought.

   Salutaciones,
                        JCAB
email: jcab_at_[hidden]
ICQ: 101728263
Web: http://www.JCABs-Rumblings.com


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk