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

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;


> 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

Reply via email to