Boost logo

Boost :

From: joel de guzman (djowel_at_[hidden])
Date: 2002-03-20 19:27:53


----- Original Message -----
From: "Jaakko Jarvi"

> > Simple non-jobs like dropping an argument shouldn't require
> > extra notational support: that just pushes users closer to the place
> > where they're forced to debate whether or not to use the library
> > facilities.
>
> The design rationale for this was that we
> really do not know many (any) programming languages which would silently
> ignore extra arguments to functions.
> True that you can ignore arguments, say in C++:
> int foo(int x, int y, int z) { return x; }
> but here too the function is explicitly marked to take 3 arguments.

I think there is a mismatch in metaphor here. The lambda function,
IMO, is the *function body* detached from the declaration. For
example, the code:

    int
    foo(int _1, int _2, int _3)
    {
        return _1 + _2;
    }

has the corresponding lambda expression:

    _1 + _2

This above should not restrict the arity. IMO, _3 can be safely ignored.
As I mentioned in my other post regarding Phoenix, I need to use
it as callbacks. For example, with Spirit, once a match is found, it
calls a semantic action function passing in iterator first and last. In
many cases, the iterators are not needed at all by the callback function
because the context where the function itself is called is already
sufficient information. The function knows what to do. The iterators
passed in are *optional* data that can be safely ignored. Take an
obvious example:

    r = a_very_complex_production
        [
            ref(cout) << "rule foo was invoked\n"
        ];

Here, I don't need the iterators at all. The point where the lambda
function is called is enough information already. The iterators are
optional information that is there when it's needed.

Regards,
--Joel


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