On Thu, Jul 22, 2010 at 4:52 PM, Jon Lang <datawea...@gmail.com> wrote:
> I do have to admit that that's awfully clean-looking, but the > implementation > > would force a closure in a series to behave differently from a closure > > anywhere else. > > How so? > Unlike some of you, I haven't managed to memorize all of the synopses. For poor dolts like me who have only read some sections once, it would be nice if you could clarify the more obscure syntax ;-) > > Without changing closure definitions and without extending the syntax > any, > > you could make the series operator do a little bit more introspection > work > > and if a parameter is named "index", track an index value and pass it by > > name, passing any remaining parameters positionally from the previous n > > values as normal. > > ...which differs from my example in several ways, all of which are > detrimental: it puts the index in among the positional parameters, > No, that's not true. Sure, if you used the syntax I used, then it's allowed to be passed either way, but since the series operator will always pass it by name, the only positionals are the remaining parameters (I did test this out before sending my mail, just to verify that $^x could be passed as :x<...> or as a positional). More importantly the syntax you used works just as well, and as far as ... is concerned, there's no substantial difference. So... what are you suggesting? That any named-only parameter is passed the index? Or that a named-only parameter called "i" is passed the index? If the latter, then you're suggesting the same thing as I am, but with a different name (I prefer the longer name, given the restrictions it places on the closure). If you're suggesting that this apply to any named-only parameter, I don't think that's a good idea. That's even MORE restrictive than what I suggested (remember, it's usually going to be a closure, defined right there, but even the Synopsis gives one example of using an existing subroutine). > meaning that odd things would have to happen if you ever decide to > use, say, $^i and $^j as your "prior items" parameters; Why? > and it locks > you into a specific name for the index instead of letting you choose > one of your own liking. > Well, true, but you have to have some convention, and a name is a common way to establish such conventions in a parameter-passing API... Essentially, my suggestion is this: if the step function's signature > (or implied signature, in the case of a function with placeholder > variables) includes any named parameters, You meant "named only" > then the index is used as > the argument corresponding to the first one. Named only... first... these terms are non-miscible, aren't they? I don't think named-only parameters have an ordering. -- Aaron Sherman Email or GTalk: a...@ajs.com http://www.ajs.com/~ajs
