Having read this thread, I tend to think you're insane for bringing it
up again :-)  

That said, I'll entertain the discussion for a bit ...

On Tue, Aug 29, 2006 at 08:33:20AM +0200, Carl Mäsak wrote:
> Questions:
> - Is the itch big enough for this? The more I look at the first piece
> of code, the more I'm thinking "that's not so bad, really". (Though
> opinions differed on the IRC channel.) Is there a situation I'm not
> thinking of where the first piece of code would suck, and the second
> piece of code would rock? Or is this a case of oversugaring?

I think this is a case of too much sugar.  I also think making the
variable *explicit* rather than implicit is a good thing.  

Pointy blocks and .kv are simple and general and can be combined
in different ways for different contexts. A special "index into the
iterator" thingy doesn't sound that general. Just an observation.

> - I feel there's a trend of moving away from line-noise variables. I'd
> hate to be one to propose adding a new one to the language. Is there a
> better syntax than "$."?

Okay, stepping into the madness ...

If each iteratorish construct kept the iterator around in some easily
accessible way, then you could call methods on it.  There is a trend
away from line-noisy variables, but given our iterator looks like =<>,
maybe the variable should be $=  (hey, formats don't need it any more

    for @array { 
        say "The value $=.value is at index $=.index";
        say "The value $_ is at index $=.index";

I'd far and away rather say:

    for @array.kv -> $i, $v {
        say "The value $v is at index $i";


Hmm. Now that I think about it a little more, $= will surely be
conflated with the PODish variables in some way. But, I don't have a
better alternative. (It's at this point that I wish there was a
double-underscore glyph on my keyboard just to have an alternative ;)

> - How would this work with non-array data? Specifically, what happens
> with next, redo etc on a filehandle, for example?

I would expect the index to track the iterator on next/redo. That is, if
you've read line 5, then the index will be 5ish (I'm hand waving 0- vs
1-based counting).  On redo it would continue to be 5, and on next it
will be 6.

But what should happen when you're reading from multiple filehandles
or multiple arrays?  Should it reset at the start of a new file/array
or continue counting?  And how do you get the other behavior?

With the simple primitives we have now we can easily create whichever
behavior we desire.  So, I think the extra sugar for some implicit
index will do more harm than good.

Here's one useful semantic I can think of WRT $= ... if it's a true
global (yes, I know we're supposed to be shy of those too, but I'm brain
storming here) then its scope lasts beyond the bounds of the block in
which it's executing so that things like

    for @array { ... last if ...; }
    say "Stopped processing at $=.index";


But, again, we have other ways of making this work that don't involve
introducing some implicit thing.

-Scott (PerlJam)
Jonathan Scott Duff <[EMAIL PROTECTED]>

Reply via email to