Michael Lazzaro wrote: > *Now*, what to do about the fantastic magic that pointy-sub provides? > The _spectacular_ win would be if we could just recognize an optional > parameter list as part of a block. > > map @a : ($a,$b) {...} # params + closure = closure with params? > for @a : ($a,$b) {...} > > So that anywhere you had a closure, you could put a paramlist in front > of it. Not likely we could get that to work, since best-case scenario > it would probably barf on $a and $b being undefined before it ever got > to the closure. But it might be possible, at the expense of some > parser complexity.
I agree that it might be difficult to recognize the ($a,$b) as a parameter list rather than a list expression. Smalltalk marks block parameters this way: b := [:a :b | a < b]. "Assign a two-paremeter block to b" ^b value: 1 value: 2. "Return the value of invoking b on 1 and 2" The "[" makes it clear that a block is next; the ":" marks parameters and the "|" ends the list. A literal translation to Perlish syntax would be map @a { :$a :$b | $a + $b } but then we get into discussions about Larry's 2nd law of colons. Besides, we perl mongers already use "|" for a sufficient multitude of other things. But my point is: just because C-ish programmers think "(...){ ... }" feels parameterish doesn't mean that the parameter declaration has to come *before* the opening curly brace. And no, despite two Smalltalk-related posts in the last three days, I don't want to turn Perl into Smalltalk; I just think that Smalltalk has a nice syntactic solution to the problem we're talking about here. The problem is, I can't think of any syntaxes better than map @a { $a $b: $a + $b } # hey, buddy, can you lend me a colon? map @a { args $a, $b; $a + $b } map @a { -> ($a, $b); $a + $b } map @a { $a, $b -> $a + $b } # can't coexist with A4-style pointy subs map @a { my^ $a, $b; $a + $b } # the ^ is reminiscent of "map @a { $^a + $^b } map @a {{$a, $b} $a + $b } # all other uses of consecutive curlies require space: "{ {" map @a { EXPLICIT_ARGUMENTS_TO_FOLLOW $a $b ARGUMENTS_STOP_HERE $a + $b } and they all look uglier than... well, um, uh... I want. I have a strong suspicion that this possibility was carefully considered by {LW, DC, ...} (that's set notation, not a code block :) before the Apocalypse 4 "pointy sub" syntax (and the for-loop syntax using it) was promulgated. And that it was rejected because it's hard to come up with something that "looks right." Even the Smalltalk syntax is a tad awkward-looking to me, and the warpage that is necessary to make it Perlish just compounds the problem. Hmmm. I guess I didn't really say anything here, did I? Do I post these ruminations, or should I just hit that cancel button before I "open my mouth and remove all doubt?" Nah. I'm goin' for it: maybe somebody else will think of a syntax that looks right! =thom "Must be a yearning deep in human heart to stop other people from doing as they please. Rules, laws--always for the other fellow. A murky part of us, something we had before we came down out of the trees, and failed to shuck when we stood up. Because not one of those people said: 'Please pass this so I won't be able to do something I know I should stop.' Nyet, tovarishchee, was always something they hated to see their neighbors doing. Stop them 'for their own good'--not because the speaker claimed to be harmed by it." Manuel Davis O'Kelley The Moon is a Harsh Mistress