Larry on p6i? I didn't expect some kind of Perlish Exposition!
On Fri, Jul 08, 2005 at 11:18:01AM -0700, Larry Wall wrote:
> Even in the absence of a hash representation, the brute force approach
> will often beat the finessed approach for a small number of arguments,
Well-taken. (Not that the rest isn't, but the danger of misoptimization
is always with us.) More commentary may be forthcoming soon.
Incidentally, under the "appropriate amount of fun" topic: An
interesting Parrot/Perl6 intersection problem with named parameters
is the representation of <==. Given
foo('a' => 1) <== ('b' => 2, ...)
It's necessary to _somehow_ pass the first pair distinctly from the
second pair without knowing the _name_ of the user-declared slurpy
parameter of &foo. I suppose the Perl 6 compiler will have to settle
on a pseudo-parameter-name that will be used to represent a <== style
list. Assuming that name is '_', the above call could be compiled to:
foo('a' => 1, '_' => ('b' => 2, ...))
or something similar. It would then be the responsibility of a Perl 6
function preamble to bind the contents of the '_' argument, if any, to
the user-declared slurpy parameter, if any. Non-Perl6 functions would
perhaps see the '_' parameter and have to deal with it.
> : Therefore, it's possible that there will
> : eventually no longer be a single loop through the parameters. The
> : concept of strict temporal ordering might thus be lost,
>
> Why would strict temporal order be needed for mere binding?
>
> : and the idea of "optional parameter up to this point" might also be lost.
>
> I don't grok that part.
It's a Parrot calling convention API thing. Leo proposed (and
implemented) a highly time-bound feature for subroutines to learn
whether optional parameters were passed in or not. It more or less
lets the user request: "Store >here< the number of optional parameters
that _so_far_ have been filled in _since_ the last time I asked".
That API requires either strict left-to-right binding or an amazing
simulation thereof.
I've since requested an API that doesn't impose even a simulation of
left-to-right processing among parameters: "Store >here< whether the
caller passed a value for >that< specific optional parameter."
> : So apparently I'm going to have to figure out exactly how we support
> : named parameters or this won't get settled. Fine....
>
> Mmm, have the appropriate amount of fun... :-)
/me giggles madly
--
Chip Salzenberg <[EMAIL PROTECTED]>
