ralph wrote:
> So what is driving you
guys to deliberately avoid a brief def
syntax?
Can't speak for Larry. But what's driving me is the desire
to balance conciseness with comprehensibility, and to keep the
overall cognitive load manageable.
If you're proposing that there be some special
exemption for $^_ so that it (a) doesn't
placehold a parameter and (b) aliases the
caller's topic instead
Well it clearly does placehold something.
Sure. It's placeholds a parameter named $^_, which
may or may not be equivalent to a parameter named $_
(Larry will need to rule on that bit).
In
method f ($self : $a) { ... }
sub f ($a) is given ($line) { ... }
what do you call $self
The "invocant".
and $line?
A lexical variable that happens to be bound to the caller's topic.
I am talking about being able to placehold
these things, whatever you choose to call
them.
You can't placehold the invocant, since placeholders create subroutines,
not methods.
We probably *could* find a notation to placehold the C<is given> variable,
but I just can't see the need, when all you have to do now is write
C<is given($var)> after the closure.
Why bother with currying?
You mean placeholders.
I meant currying. (I was listing mechanisms
that I believed existed to enable coding
brevity.)
Currying is more about efficiency and algorithmic integrity than
brevity. In fact, I would argue that it explciitly *not* about brevity.
Compare:
$incr = &add.assuming(x=>1);
with:
$incr = { add(1,$^y) };
The currying syntax was (deliberately) chosen to be verbose because
powerful or unusual things should be clearly marked.
Ultimately we're discussing philosophy, which is a waste of time since
we are unlikely to convince each other. I think we should just agree
to disagree here, and let Larry decide.
Damian
