On Tue, May 15, 2007 at 01:14:44PM -0600, Luke Palmer wrote: > However, I do think that it's useful to be able to treat the rest of > the current scope as a block (usually with a parameter), for certain > kinds of closure-heavy code. Maybe this is a case for one of Mr. Lang's custom semicolons with added functionality: you could have something that worked a bit like the lambda-calculus ".". It would slurp up as much of the RHS as possible, which would almost always[1] be until the end of the enclosing block, and 'return' it (in a syntactic way) to whatever on the LHS wants a block. So, like Mr. Palmer's example, you would get something like
sub do_stuff() {
my @foo = get_me_a_list;
for @foo :-
.subst(/bar/,'baz').say;
}
[1] By "almost always" I mean I can't think of a reason for it to
sometimes not be that, but one or more may exist. Anywhere you would
want it to stop before the end of the enclosing block you should
probably use curlies anyway to stop it being confusing.
I'm not sure whether I would use these magic brace-opening semicolons
even if they were in. It seems to be to be less readable, but maybe
that's just because I haven't seen a compelling enough example. In the
worst case they would lead to code that looks like the old-style TeX
idiom of "normal {\bf bold} normal", where you open braces around the
whole block and do a state-change-like thing inside rather than a
functional thing that takes the thing you want operated on as an
argument. That doesn't mean we shouldn't allow custom semicolons with
added functionality; just that maybe this is not the best use for them
after all.
--
Mary had a little sprout, From week to week, from month to month,
Its fleece was green as grass, She kept the sprout in tow,
She hitched it to a bit of string, And everywhere that Mary went,
The silly little ass. The sprout was sure to go.
signature.asc
Description: Digital signature
