Larry Wall wrote:
> Arrays with explicit ranges don't use the minus notation to count from
> the end. We probably need to come up with some other notation for the
> beginning and end indexes. But it'd be nice if that were a little
> shorter than:
>
> @ints.shape[0].beg
> @ints.shape[0].end
>
> Suggestions? Maybe we just need integers with "whence" properties...
> :-)
Actually, I'd go for something a little bit longer in the first case:
@ints.shape[0].begin
'beg' is what you do when you're down on your luck; it oughtn't be how you
start out.
As for shortening things, a bit of dwimmery might be in order: if the
array in question only has one dimension, the [0] might be made optional;
and when you're using the postcircumfix:[] index operator, you might have
each expression evaluated in the context of the appropriate dimension:
@ints[.begin + 2, .end - 3]
would be equivalent to
@[EMAIL PROTECTED] + 2, @ints.shape[1].end - 3]
I wonder if this notion of contextualizing a method's signature could be
generalized... I could see a case for treating most methods as if the
expressions in each parameter were being evaluated within the caller's
class:
scratch $jack: .back
would be equivalent to
$jack.scratch($jack.back)
This isn't quite the same thing as the index operator given above:
@ints[.begin + 2, .end - 3]
would be equivalent to
@[EMAIL PROTECTED] + 2, @ints.end - 3]
by this logic, which isn't what we want. We'd either have to make this a
special case or say:
@ints[.shape[0].begin + 2, .shape[1].end - 3]
...which would be unneccessarily bulky. OTOH, it would be annoying if we
had to say
@[EMAIL PROTECTED], @ints.shape[0].begin]
if we wanted to access the index whose first dimension corresponds to the
lowest bound of the second dimension and vice versa - though why you'd
ever want to do something like that is beyond me. Perhaps this is
appropriate Huffman coding after all...
How to declare this? Perhaps you could do something like:
method postcircumfix:[]
($object: [EMAIL PROTECTED] is context($object.shape[$_])) {...}
where the "context" trait normally has a value of $object in a method.
The above is an example of how the thing would be applied to the list
parameter, with the context being applied to each element in turn and $_
being set to the list's index for that element; similarly, an anonymous
named parameter might work the same way, with $_ being set to the
parameter's key. Any function that has exactly one invocant would have a
default context of that invocant for every parameter, while any function
that has anything _but_ one invocant would have _no_ default parameter
context - which wouldn't stop programmers from explicitly adding contexts
where appropriate.
=====
Jonathan "Dataweaver" Lang
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
