Re: Synopsis 2 draft 1 -- each and every
On Fri, 20 Aug 2004, Luke Palmer wrote: > Austin Hastings writes: > > Larry Wall wrote: > > >Hmm. Gotta decided if S$foo.bar() is too ugly to live though... > > > > It is. > > Agreed. Though IMHO Perl has a long history of syntax allowances too ugly to live, and yet, as long as they are not *enforced*, I don't think they make a major problem, i.e. most people would write C<< S $foo.bar() >> anyway. Michele -- No one can ever predict all of the possible error conditions, of course; as soon as we write idiot-proof code, along comes a better idiot. But it's still worth making the attempt. - Sherm Pendley in clpmisc (edited)
Re: Synopsis 2 draft 1 -- each and every
David Green writes:
> On 8/20/04, [EMAIL PROTECTED] (Luke Palmer) wrote:
> >So all the laziness goes into the array implementation. But you don't
> >even need to write your iterator fancily. If you just write your scalar
> >version of postcircumfix:<>, Perl will do the rest.
>
> So if you use an iterator in list context, Perl will automatically call it
> repeatedly for you?
> That still means Perl has to know when something is an iterator, which is
> fine for <> (or whatever it ends up being called), but when your object
> has different ways to iterate (e.g. .keys, .values, .kv), they'd have to
> be defined as "is iterator" or some such.
Since operators are going to be less DWIMmy this time around, I suppose
I should have said "Perl does the rest if your class does iterator". So
the iterator role would define the listy version for you.
> >method postcircumfix:<> ($self: *%opt) returns List {
> >scalar $self.<*%opt>, $self.<*%opt> # [1]
> >}
> >If I write it functionally like that, Perl will still do all the rest.
> >Laziness is built right in the language.
>
> Ah, nice! But doesn't the scalar definition need to be part of the method
> too?
>
> method postcircumfix:<> ($self: *%opt) returns Scalar|List #??
> {
> given want
> {
> when Scalar { get_next_value, increment_counter, etc; }
> when List { return scalar $self.<*%opt>, list $self.<*%opt>; }
> # hm, what about void context?
> # (should probably iterate once, like scalar context)
> }
> }
>
> Or can you define separate methods for scalar and list contexts, and have
> Perl call whichever one is appropriate? (Which would be neat...
> polymorphism from the other end.)
That was the idea, but I realize that I did it wrong. I also realize
that there isn't a right way yet. Dispatching on return value is
something that is pretty hard to implement, and impossible to implement
correctly, as it has a tendency to create paradoxes.
So for now I'd say that you have to put them both in the same method.
Which seems to imply that the iterator role would look for a method name
to use for scalar context. Like sip :-)
Luke
Re: Synopsis 2 draft 1 -- each and every
On 8/20/04, [EMAIL PROTECTED] (Luke Palmer) wrote:
>So all the laziness goes into the array implementation. But you don't
>even need to write your iterator fancily. If you just write your scalar
>version of postcircumfix:<>, Perl will do the rest.
So if you use an iterator in list context, Perl will automatically call it
repeatedly for you?
That still means Perl has to know when something is an iterator, which is
fine for <> (or whatever it ends up being called), but when your object
has different ways to iterate (e.g. .keys, .values, .kv), they'd have to
be defined as "is iterator" or some such.
...or... you could just do the extra not-so-fancy work yourself. Multiple
iterators probably aren't really very common anyway, and it's not that
much work after all to make your own method that iterates lazily:
>method postcircumfix:<> ($self: *%opt) returns List {
>scalar $self.<*%opt>, $self.<*%opt> # [1]
>}
>If I write it functionally like that, Perl will still do all the rest.
>Laziness is built right in the language.
Ah, nice! But doesn't the scalar definition need to be part of the method
too?
method postcircumfix:<> ($self: *%opt) returns Scalar|List #??
{
given want
{
when Scalar { get_next_value, increment_counter, etc; }
when List { return scalar $self.<*%opt>, list $self.<*%opt>; }
# hm, what about void context?
# (should probably iterate once, like scalar context)
}
}
Or can you define separate methods for scalar and list contexts, and have
Perl call whichever one is appropriate? (Which would be neat...
polymorphism from the other end.)
-David "polly going crackers" Green
Re: Synopsis 2 draft 1 -- each and every
On Fri, 20 Aug 2004, Dan Hursh wrote:
> Peter Behroozi wrote:
>
> > I'm not particular to any of the verbs used yet, but maybe that's
> > because I don't think of the <> as a general iterator, but more of a
> > gobbler-type creature (and formerly a globber, too). Could we try:
> >
> > for $foo.fetch { ... } #or
> > for $foo.grab { ... } #or
> > for $foo.eat { ... }
> >
> > And to replace $/ we could have something like:
> >
> > for $foo.fetch :upto(",") { ... } #or
> > for $foo.fetch :until(",") { ... }
>
> general impose scalar impose list
> --- --
>D $foo.eat$foo.bite $foo.gobble
>N $foo.look $foo.peek $foo.peruse
>
> hmm, I don't like eat in this case
>
>D $foo.take $foo.grab $foo.horde
D $foo.drink $foo.sip$foo.slurp
N $foo.taste
Ok, I'll stop now. But I do sort of (very minorly) like sip as a mini-slurp.
>
> That assumes folks think of grab as being singular and take as being
> open ended. That, and I don't want take to colide with gather{take}.
> Oh well.
>
> Dan
>
--
Adam Lopresto
http://cec.wustl.edu/~adam/
Keyboard not found. Think F1 to continue.
Re: Synopsis 2 draft 1 -- each and every
On 8/20/04 5:30 PM, Austin Hastings wrote: > How about "scalar"? The fact that one person, one time, came up with a > need to invoke it doesn't mean we have to race it up the huffman tree. > P6 is winning the DWIM race most of the time contextually. Maybe [#] as > a macro, if you like. Yeah, that's my feeling too. I was going to suggest "sc", but I don't think having to writ out "scalar" is too much of a hardship. I think the drive for a single-char version is driven more by symmetry than expected usage frequency. (I also think S is ugly and _ looks like a typo in many situations) -John
Re: Synopsis 2 draft 1 -- each and every
Austin Hastings writes:
> Larry Wall wrote:
> >Hmm. Gotta decided if S$foo.bar() is too ugly to live though...
> >
>
> It is.
Agreed.
> >I still kinda like underscore.
> >
> How about "scalar"? The fact that one person, one time, came up with a
> need to invoke it doesn't mean we have to race it up the huffman tree.
> P6 is winning the DWIM race most of the time contextually. Maybe [#] as
> a macro, if you like.
I personally have no problem with "scalar", now that the majority of the
cases where it was necessary can now be replaced with ~, +, or ?. It
can't, of course, when you're dealing with objects generically, and
that's when you use "scalar".
But ever since Larry decided to make "{ }" interpolate, getting rid of
$() on account of adding ~, +, and ?, I've wanted it back so it can go
back in strings. But I'm sure that this is just another one of his
decisions that I'm going to hate for a little while, and then finally
understand and like much better. It worked that way for %hashÂkeyÂ.
Luke
Re: Synopsis 2 draft 1 -- each and every
chromatic wrote: On Fri, 2004-08-20 at 14:26, Austin Hastings wrote: Dan Hursh wrote: generalimpose scalarimpose list ----- D$foo.eat$foo.bite$foo.gobble N$foo.look$foo.peek$foo.peruse hmm, I don't like eat in this case D$foo.take$foo.grab$foo.horde s/horde/hoard/ If I'd written that, I'd claim that as deliberate. Though it does leave a problem with "grab" as a singular noun, Why? Horde is a noun, hoard is a verb like all the other entries in the table. (Some have dual use, like hoard does, as nouns, but...) =Austin
Re: Synopsis 2 draft 1 -- each and every
Chromatic wrote: On Fri, 2004-08-20 at 14:26, Austin Hastings wrote: Dan Hursh wrote: generalimpose scalarimpose list ----- D$foo.eat$foo.bite$foo.gobble N$foo.look$foo.peek$foo.peruse hmm, I don't like eat in this case D$foo.take$foo.grab$foo.horde s/horde/hoard/ If I'd written that, I'd claim that as deliberate. Though it does leave a problem with "grab" as a singular noun, It kinda looked wrong, but, well... 6 of one, a dozen of the other It's all the same to spell check... send it!
Re: Synopsis 2 draft 1 -- each and every
Larry Wall wrote: On Fri, Aug 20, 2004 at 12:52:56PM -0700, Larry Wall wrote: : Unfortunately, the only obvious one, 's', is taken. I remind myself that 'S' is equally obvious, and not taken. Like _, it suffers from spacing issues, but could be the ASCII backup for the § character. (As Y is likely to be the ASCII backup for ¥. Maybe Y is the nylon zipper operator.) Hmm. Gotta decided if S$foo.bar() is too ugly to live though... It is. I still kinda like underscore. How about "scalar"? The fact that one person, one time, came up with a need to invoke it doesn't mean we have to race it up the huffman tree. P6 is winning the DWIM race most of the time contextually. Maybe [#] as a macro, if you like. =Austin
Re: Synopsis 2 draft 1 -- each and every
On Fri, 2004-08-20 at 14:26, Austin Hastings wrote: > Dan Hursh wrote: > > generalimpose scalarimpose list > > ----- > > D$foo.eat$foo.bite$foo.gobble > > N$foo.look$foo.peek$foo.peruse > > > > hmm, I don't like eat in this case > > > > D$foo.take$foo.grab$foo.horde > > > s/horde/hoard/ If I'd written that, I'd claim that as deliberate. Though it does leave a problem with "grab" as a singular noun, -- c
Re: Synopsis 2 draft 1 -- each and every
Dan Hursh wrote:
Peter Behroozi wrote:
I'm not particular to any of the verbs used yet, but maybe that's
because I don't think of the <> as a general iterator, but more of a
gobbler-type creature (and formerly a globber, too). Could we try:
for $foo.fetch { ... } #or
for $foo.grab { ... } #or
for $foo.eat { ... }
And to replace $/ we could have something like:
for $foo.fetch :upto(",") { ... } #or
for $foo.fetch :until(",") { ... }
generalimpose scalarimpose list
-----
D$foo.eat$foo.bite$foo.gobble
N$foo.look$foo.peek$foo.peruse
hmm, I don't like eat in this case
D$foo.take$foo.grab$foo.horde
s/horde/hoard/
That assumes folks think of grab as being singular and take as being
open ended. That, and I don't want take to colide with gather{take}.
Oh well.
Dan
Re: Synopsis 2 draft 1 -- each and every
Peter Behroozi wrote:
I'm not particular to any of the verbs used yet, but maybe that's
because I don't think of the <> as a general iterator, but more of a
gobbler-type creature (and formerly a globber, too). Could we try:
for $foo.fetch { ... } #or
for $foo.grab { ... } #or
for $foo.eat { ... }
And to replace $/ we could have something like:
for $foo.fetch :upto(",") { ... } #or
for $foo.fetch :until(",") { ... }
general impose scalar impose list
--- --
D $foo.eat$foo.bite $foo.gobble
N $foo.look $foo.peek $foo.peruse
hmm, I don't like eat in this case
D $foo.take $foo.grab $foo.horde
That assumes folks think of grab as being singular and take as being
open ended. That, and I don't want take to colide with gather{take}.
Oh well.
Dan
Re: Synopsis 2 draft 1 -- each and every
On Fri, Aug 20, 2004 at 12:52:56PM -0700, Larry Wall wrote: : Unfortunately, the only obvious one, 's', is taken. I remind myself that 'S' is equally obvious, and not taken. Like _, it suffers from spacing issues, but could be the ASCII backup for the § character. (As Y is likely to be the ASCII backup for ¥. Maybe Y is the nylon zipper operator.) Hmm. Gotta decided if S$foo.bar() is too ugly to live though... I still kinda like underscore. Larry
Re: Synopsis 2 draft 1 -- each and every
On Thu, Aug 19, 2004 at 08:12:37PM -0500, Peter Behroozi wrote:
: And to replace $/ we could have something like:
:
: for $foo.fetch :upto(",") { ... } #or
: for $foo.fetch :until(",") { ... }
I suppose in <>-ese, that could be one of:
for $foo.< :upto(",") > { ... } #or
for $foo.< :until(",") > { ... }
That sort of thing lets you do context-sensitive chunking, which is
a plus. But I think in the usual case people will be setting the
chompish bits on the handle at open time. The option there might
be :chomp(","), so maybe the override should be the same:
for $foo.< :chomp(",") > { ... }
which kind of gets you back to your eating metaphor. (In either
case, the delimiter is removed from the input string, but available
as $_.chomped or some such.)
Larry
Re: Synopsis 2 draft 1 -- each and every
On Fri, Aug 20, 2004 at 10:49:17AM -0600, Luke Palmer wrote:
:
: method postcircumfix:<> ($self: *%opt) returns List {
: scalar $self.<*%opt>, $self.<*%opt> # [1]
: }
:
: [1] Look, Larry, I had to use C! Maybe we _do_ need to revive
: $()!
It's not clear to me that $() would have made this more readable...
I think if we ever come up with a single-character unary scalar
operator, it should be something other than '$'. I just don't like
the look of '$($', nor the fact that the inner $ is doing something
quite different from the outside one.
Maybe we could resurrect the '_' operator to mean scalar() at the
symbolic unary precedence level. Underline looks sufficiently
different from $. Your example would then be:
method postcircumfix:<> ($self: *%opt) returns List {
_$self.<*%opt>, $self.<*%opt> # [1]
}
Then I suppose binary _ would be defined as:
$a _ $b
is the same as
_($a, $b)
which is the same as
[$a, $b]
Not clear what $a _ $b _ $c would mean though...
Hmm. There's another possibility. We just got through explaining how
the => binary operator imposes scalar on its right side. There's no
corresponding unary operator. So we could make one:
method postcircumfix:<> ($self: *%opt) returns List {
=>$self.<*%opt>, $self.<*%opt> # [1]
}
then the definition of binary => is already obvious. On the other
hand, unary =>$x probably ought to mean $_ => $x or some such (where
"some such" includes "nothing at all"). And I'd prefer to keep all
the symbolic unaries single chars. So I lean towards _.
But something is tickling the back of my mind as a different proposed
meaning for bare _ as a token, and I can't remember what. Placeholders
for anonymous unification, a la Prolog, maybe. Whatever it is, it
could probably coexist with _ as a unary, much like we're thinking
of making unary * coexist with a splat slice in a multidimensional
subscript.
Since _ would primarily be used as a unary, it wouldn't suffer as
much from ambiguity as when it was proposed for string concat, where
$a_$b would be a syntax error. It would be a problem for functions
calls, however:
push @x, _ myfunc();
But really, that's no more characters than:
push @x, =>myfunc();
I don't see any other single-character candidates. It's probably
time to do an exhaustive check again. First of all, none of the
alphabetic ones are any better than underscore, except possibly
for mnemonic value. Unfortunately, the only obvious one, 's', is
taken. That leaves punctuation. Here's what my keyboard offers
in ASCII:
say `myfunc(); # taken
say ~myfunc(); # taken
say !myfunc(); # taken
say @myfunc(); # taken
say #myfunc(); # taken
say $myfunc(); # taken
say %myfunc(); # taken
say ^myfunc(); # possible, but easily confused with +^
say &myfunc(); # taken
say *myfunc(); # taken
say (myfunc(); # taken
say )myfunc(); # pragmatically impossible (breaks bracket matching)
say -myfunc(); # taken
say _myfunc(); # indentifer character in C culture
say +myfunc(); # taken
say =myfunc(); # visually and semantically confusing
say [myfunc(); # taken
say ]myfunc(); # pragmatically impossible (breaks bracket matching)
say {myfunc(); # taken (and then taken some more)
say }myfunc(); # pragmatically impossible (breaks bracket matching)
say \myfunc(); # taken
say |myfunc(); # visually and semantically confusing
say ;myfunc(); # too important as expression stopper: loop ;; {...}
say :myfunc(); # taken
say 'myfunc(); # taken
say "myfunc(); # taken
say ,myfunc(); # visually and semantically confusing
say myfunc(); # visually and semantically confusing
say /myfunc(); # taken
say ?myfunc(); # taken
If we're willing to take the Latin-1 hit, then we also have these
punctuational possibilities:
¡ 00A1INVERTED EXCLAMATION MARK
¢ 00A2CENT SIGN
£ 00A3POUND SIGN
¤ 00A4CURRENCY SIGN
¥ 00A5YEN SIGN
¦ 00A6BROKEN BAR
§ 00A7SECTION SIGN
¨ 00A8DIAERESIS
© 00A9COPYRIGHT SIGN
ª 00AAFEMININE ORDINAL INDICATOR
« 00ABLEFT-POINTING DOUBLE ANGLE QUOTATION MARK
¬ 00ACNOT SIGN
00ADSOFT HYPHEN
® 00AEREGISTERED SIGN
¯ 00AFMACRON
° 00B0DEGREE SIGN
± 00B1PLUS-MINUS SIGN
² 00B2SUPERSCRIPT TWO
³ 00B3SUPERSCRIPT THREE
´ 00B4ACUTE ACCEN
Re: Synopsis 2 draft 1 -- each and every
David Green writes:
> Then I thought that maybe "for" doesn't need to work lazily (except that
> the conveniently just-posted Synopsis 4 confirms that it is supposed to
> be lazy). Or maybe "for" is only "as lazy as is reasonable", meaning if
> it knows how (e.g. if you're using an array or filehandle, which have
> known ways to meander through lazily), or if you write a really fancy
> iterator for your object that can handle laziness.
The implementation of C will be very simple. Something like:
sub for ([EMAIL PROTECTED], *&code) {
code(*splice @args: 0, &code.arity) while @args;
}
So all the laziness goes into the array implementation. But you don't
even need to write your iterator fancily. If you just write your scalar
version of postcircumfix:<>, Perl will do the rest. The list version
isn't all that complicated either. Something like:
method postcircumfix:<> ($self: *%opt) returns List {
scalar $self.<*%opt>, $self.<*%opt> # [1]
}
If I write it functionally like that, Perl will still do all the rest.
Laziness is built right in the language. And that's one of the biggest
semantic differences from Perl 5.
Luke
[1] Look, Larry, I had to use C! Maybe we _do_ need to revive
$()!
Re: Synopsis 2 draft 1 -- each and every
On 8/19/04, [EMAIL PROTECTED] (Larry Wall) wrote: >It's hard to come up with an English word that means "next" in scalar >context but "all" in list context. I never know whether to name my arrays singular or plural, either. =) But couldn't there be Two Ways To Do It? One "singular" name and one "plural" that do exactly the same thing -- use whichever one sounds better in any given context. >So I lean toward punctuation, and since <> is historical, I like ><$IN> and $IN.<> for that. [...] Arguably .keys, .values, .pairs, >and .kv should all autoiterate in scalar context, which should >replace .each entirely. @array should respond to .pairs and .kv, >pretending the implicit array indexes are hash keys. Which reminds me that an object can have multiple iterators, that do different things. (Though there might always be a "default" iterator -- the one that "for" would use.) So that's another reason not to mandate iterator names at all; <> could still be the socially conventional name for iterators (or maybe it would only be used by filehandles, depending on what else we might use <> for). >It looks like most of the problem is that we're not consistent in >how to destructively read something in a context sensitive manner. >And I don't really like .read anyway. Without necessarily >deprecating .shift or .splice, how about a table that looks like >this: [.pull's and .value's] I like the idea of being able to distinguish destructive from non-d. behaviour when I need to. But a lot of the time I don't care -- I wouldn't want to have to specify whether I'm pulling or value-ing in every "for" loop. So we'd still need something like <> (that presumably defaults to the least destructive iterator available). - David "does like 'pull' as a good generic name" Green
Re: Synopsis 2 draft 1 -- each and every
On 8/19/04, [EMAIL PROTECTED] (Luke Palmer) wrote: >David Green writes: > > Hang on -- should we be saying "for each $foo" or "for $foo.each" > > anyway? We don't say "for @foo.each"; the iteration is implicit. So > > I'm thinking it should be "for $foo" or "while next $foo". > >Well, C gives you a one-iteration loop. Oops, I meant $foo to be some iterable object... but yes, that conflicts with referring to the object itself (such as a plain scalar... although I guess anything without an explicit iterator method could simply "iterate" by returning itself once). But I was confusing myself there anyway. I was thinking that "for" would somehow have to call the iterator implicitly because if the iterating method just returned the next value in scalar context and all values in list context, then "for $object" would pull everything (all the $object-s flattened) instead of pulling each subsequent $object one at a time (i.e. lazily). Then I thought that maybe "for" doesn't need to work lazily (except that the conveniently just-posted Synopsis 4 confirms that it is supposed to be lazy). Or maybe "for" is only "as lazy as is reasonable", meaning if it knows how (e.g. if you're using an array or filehandle, which have known ways to meander through lazily), or if you write a really fancy iterator for your object that can handle laziness. If your iterator (in list context) just returns everything at once, then "for" will effectively flatten the list because there's nothing else it can do. (If you need one-at-a-time behaviour, use a while loop!) Hm... but it still seems it would be good if "for" could know what the iterator method is for any given object, so that it could call the (single) iterator one at a time and get through any sequence as lazily as possible. >Which implies that iterators can behave as arrays. Then you get to >weird questions like what: >$foo[-1] >Does. Iterate to the end and return that? The array abstraction >doesn't work well for iterators, so perhaps that's not the best way to >go. Yeah... my instinct would be that if you want that much array-like behaviour, then tie your object to or inherit it from an Array. >I'm personally a fan of "every" as well as renaming Ruby's "each" to >something else. I was also warming up to "sequel", but it's kind of long to type. OK, using "next" is a problem because of things like: $foo='LINE'; next $foo; but what if labels had to be stored in special "label objects" instead of plain strings? Well, that could still cause problems if you ever wanted to iterate over some label names, I guess. (Don't ask me why you'd want to do that...) Anyway, now that everything's a closure, isn't labelling a block a lot like naming the block/closure/sub? (Probably not... =P) Hm -- you can also label a statement on its own... I forgot about that because I don't think I've ever actually seen Perl code that does that. (You can't 'next' to a statement anyway, only to a labelled block.) - David "starting to confuse myself again" Green
Re: Synopsis 2 draft 1 -- each and every
On Thu, 2004-08-19 at 12:17 -0400, Matt Diephouse wrote:
> At this point, you may as well use C<.records> (think C<$/> -- record
> separator):
>
>for $foo.records { ... }
>
> Then it'd be a small step to allow:
>
>for $foo.records :sep"," { ... }
> --or--
>for $foo.records(",") { ... }
>
I'm not particular to any of the verbs used yet, but maybe that's
because I don't think of the <> as a general iterator, but more of a
gobbler-type creature (and formerly a globber, too). Could we try:
for $foo.fetch { ... } #or
for $foo.grab { ... } #or
for $foo.eat { ... }
And to replace $/ we could have something like:
for $foo.fetch :upto(",") { ... } #or
for $foo.fetch :until(",") { ... }
P.
Re: Synopsis 2 draft 1 -- each and every
Dov Wasserman writes: > "Larry Wall" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > next D next N all D all N > > == == = = > > $iter $iter.pull ?1 $iter.pull ?2 > > @array @array.pull @array.values @array.pull @array > > $array $array.pull $array.values $array.pull @$array > > %hash %hash.pull %hash.values@array.pull %hash.values > > $hash $hash.pull $hash.values@array.pull $hash.values > > > > After all, a pull is the other end of a push. > > True in real life, but why not pop as the destructive evil twin of push? > > I think 'pop' more clearly indicates a removing iteration than 'pull'. > And its 25% shorter! But mainly because it's an established term for > the exact concept we're going for here. Except that it's an established term for an operation at the _opposite_ end of the list. C is only the opposite of C if you're thinking about a stack; if you're thinking about a queue then C is the current named used. So C would work, but would yield values in the opposite order to that which many people are expecting. Smylers
Re: Synopsis 2 draft 1 -- each and every
"Larry Wall" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > [H]ow about a table that looks like this: > > next D next N all D all N > == == = = > $iter $iter.pull ?1 $iter.pull ?2 > @array @array.pull @array.values @array.pull @array > $array $array.pull $array.values $array.pull @$array > %hash %hash.pull %hash.values@array.pull %hash.values > $hash $hash.pull $hash.values@array.pull $hash.values > > After all, a pull is the other end of a push. > > Larry True in real life, but why not pop as the destructive evil twin of push? I think 'pop' more clearly indicates a removing iteration than 'pull'. And its 25% shorter! But mainly because it's an established term for the exact concept we're going for here. A different concern I have, though, is this distinction we're assuming in an iterator between destructive (DS) and non-destructive (ND). It seems to me that, generally speaking, that should be an implementation detail of the iterated-upon object. For example, I might be reading lines from an arbitrary input stream. If the stream is stdin, this is clearly a "destructive" operation, in the sense of being non-reversible. However, the stream could just as easily be backed by a file on disk, where reading lines does not destroy or remove them. I shouldn't have to think about which method to use since I don't care about the effect. Huffman-wise, I imagine that's actually the most likely iteration scenario. I think the general iteration API should therefore be a via a name that does not care whether its underlying object is being consumed or not (the Callous Iterator). The syntactic <> should behave exactly this way. Then, for those occasions you do care about how the sequence is being processed, you can call either $seq.pop or $seq.next (or whatever names) for the specific DS/ND behavior you need. -Dov Wasserman
Re: Synopsis 2 draft 1 -- each and every
On Thu, Aug 19, 2004 at 05:26:38PM -0400, John Macdonald wrote: : In scalar context a non-destructive read of an iterator might : be called $iter.peek and the next .read will get (and remove) : the same value that .peek returns. Implementation would be : fairly simple - the control info for an iterator would have a : field containing the next value and a flag to specify whether : that value had been determined yet. Indeed, the Perl 6 argument-passing/parameter-binding mechanism is based on the notion that a list is composed of the part it knows about already and the part it may have to generate on the fly. Arrays and iterators can share this characteristic. But arrays are inclined to remember their past values while iterators are inclined to forget. Larry
Re: Synopsis 2 draft 1 -- each and every
On Thu, Aug 19, 2004 at 01:54:39PM -0600, Luke Palmer wrote:
: That is very tickley. But there's another kind of dissonance there.
: @array.pull needs to take arguments[1] when called with list pull,
: otherwise it's basically useless.
It's not useless if you just want to interpolate an entire array
destructively. But you can have an arguments to pull that say things
like how many values to pull out. That's assuming Perl doesn't just
up and figure out that
($a,$b,$c) = @array.pull;
really means
($a,$b,$c) = @array.pull(3);
: The same goes for %hash.pull, except I'm not sure what those
: arguments would be.
A pull of n arguments would be pretty useless if you don't know
an ordering. So maybe there's an interaction with sorting somehow.
But then you might as well sort it, put it into a temp array, and
pull from the sorted array, unless you're willing to hide an array
state somewhere in %foo.sort.pull(3). But I think the closest I
want to get to that is the implicit list passed by a pipe operator.
Suppose we named that @=. We might have
%hash.sort ==> do {
while @= {
say @=.pull(5);
}
}
: And I assume that %hash.pull would pull off values, to remain
: consistent as sortof an array with nonnumeric keys (and no inherint
: ordering?).
If it's going to pull destructively, I'd say it wants to pull a pair,
to avoid losing info.
: Or would it pull off kv pairs, obsoleting the .kv method?
But it wouldn't obsolete .kv anyway, since .kv is non-destructive.
: It's tempting to do it this way due to the parallelism argument, but
: it's also tempting to have different names for each, since they all have
: their various quirks or shades.
Yes, that's essentially the anti-perfect-language argument, which is
a very good argument indeed. One must strike a balance on that subject,
and other people will certainly disagree.
Larry
Re: Synopsis 2 draft 1 -- each and every
On Thu, Aug 19, 2004 at 12:31:42PM -0700, Larry Wall wrote:
> So let's rewrite the table (assuming that all the hash methods are just
> variants of .values), where N and D are non-destructing and destructive:
>
> next D next N all D all N
> == == = =
> $iter $iter.read ?1 $iter.read ?2
> @array @array.shift@array.for @array.splice @array
> $array $array.shift$array.for $array.splice @$array
> %hash ?3 %hash.values?4 %hash.values
> $hash ?3 $hash.values?4 $hash.values
>
> Hmm. Ignore ?1 and ?2, since it's not clear that iterators can be
> read non-destructively.
In scalar context a non-destructive read of an iterator might
be called $iter.peek and the next .read will get (and remove)
the same value that .peek returns. Implementation would be
fairly simple - the control info for an iterator would have a
field containing the next value and a flag to specify whether
that value had been determined yet.
sub peek {
unless ($iter.flag) {
$iter.nextval = $iter.getnext();
$iter.flag = true;
}
return $iter.nextval;
}
sub read {
if ($iter.flag) {
$iter.flag = false;
return $iter.nextval;
}
return $iter.getnext();
}
--
Re: Synopsis 2 draft 1 -- each and every
On Thursday 19 August 2004 02:14 pm, Paul Seamons wrote: > @array.push(3 => 'value'); # index 3 gets 'value' Hmm. Well that makes it hard to have an array of pairs - so never mind. Paul Seamons
Re: Synopsis 2 draft 1 -- each and every
> After all, a pull is the other end of a push. > > Larry So do we also get: %hash.push(key => 'value'); # harder than %hash<> = 'value'; %hash.unshift; # same as %hash.push %hash.shift; # same as %hash.pull %hash.pop; # same as %hash.pull Which then begs if you can do @array.push(3 => 'value'); # index 3 gets 'value' # which is harder han @array[3] = 'value' Paul Seamons
Re: Synopsis 2 draft 1 -- each and every
Larry Wall writes: > next D next N all D all N > == == = = > $iter $iter.read ?1 $iter.read ?2 > @array @array.shift@array.for @array.splice @array > $array $array.shift$array.for $array.splice @$array > %hash ?3 %hash.values?4 %hash.values > $hash ?3 $hash.values?4 $hash.values > > Hmm. Ignore ?1 and ?2, since it's not clear that iterators can be > read non-destructively. > > It looks like most of the problem is that we're not consistent in how > to destructively read something in a context sensitive manner. And I > don't really like .read anyway. Without necessarily deprecating > .shift or .splice, how about a table that looks like this: > > next D next N all D all N > == == = = > $iter $iter.pull ?1 $iter.pull ?2 > @array @array.pull @array.values @array.pull @array > $array $array.pull $array.values $array.pull @$array > %hash %hash.pull %hash.values@array.pull %hash.values > $hash $hash.pull $hash.values@array.pull $hash.values > > After all, a pull is the other end of a push. That is very tickley. But there's another kind of dissonance there. @array.pull needs to take arguments[1] when called with list pull, otherwise it's basically useless. The same goes for %hash.pull, except I'm not sure what those arguments would be. And I assume that %hash.pull would pull off values, to remain consistent as sortof an array with nonnumeric keys (and no inherint ordering?). Or would it pull off kv pairs, obsoleting the .kv method? It's tempting to do it this way due to the parallelism argument, but it's also tempting to have different names for each, since they all have their various quirks or shades. > Larry [1] And there's a-whole-nother beast in @array.pull arguments, dealing with the issue that I've been wanting to address of @array representing an ordered but not indexed list.
Re: Synopsis 2 draft 1 -- each and every
On Thu, Aug 19, 2004 at 10:53:06AM -0500, Jonathan Scott Duff wrote:
: I like "each" best though. Why exactly can't it work?
It could be made to work. The sources of cognitive interference are:
1. Perl 5's each(%hash) function, which is probably not a problem.
2. Ruby's array.each {|x| print x } construct, which probably ought to
be spelled differently anyway.
3. English's "each", which doesn't work so well in "while each $IN".
It's hard to come up with an English word that means "next" in scalar
context but "all" in list context. So I lean toward punctuation, and
since <> is historical, I like <$IN> and $IN.<> for that. But if I had
to pick a good generic word that doesn't commit, I'd pick .read as
a shortened form of Perl 5's .readline. (Leaving aside the conflict
with the current read() function, which *might* be resolvable with MMD.)
If we try to set up a table, we get something like:
next as scalar all as list
== ===
$iter $iter.read $iter.read
@array @array.shift@array
$array $array.shift@$array $array[]
%hash %hash.each %hash .keys .values .pairs .kv
$hash $hash.each %$hash .keys .values .pairs .kv
This table shows us a number of bogusoidal facts. .read and .shift
are destructive. Nothing else is. But .read and .shift are not
synonymous in list context. %hash.each doesn't actually return a
scalar if we follow Perl 5, which we probably aren't. %hash probably
means %hash.pairs in list context. Arguably .keys, .values, .pairs,
and .kv should all autoiterate in scalar context, which should replace
.each entirely. @array should respond to .pairs and .kv, pretending
the implicit array indexes are hash keys. There is no non-destructive
scalar iterator for arrays except a C, which makes me wonder if
there is a Rubyesque @array.for:{ dostuff }.
So let's rewrite the table (assuming that all the hash methods are just
variants of .values), where N and D are non-destructing and destructive:
next D next N all D all N
== == = =
$iter $iter.read ?1 $iter.read ?2
@array @array.shift@array.for @array.splice @array
$array $array.shift$array.for $array.splice @$array
%hash ?3 %hash.values?4 %hash.values
$hash ?3 $hash.values?4 $hash.values
Hmm. Ignore ?1 and ?2, since it's not clear that iterators can be
read non-destructively. It looks like most of the problem is that
we're not consistent in how to destructively read something in a
context sensitive manner. And I don't really like .read anyway.
Without necessarily deprecating .shift or .splice, how about a table
that looks like this:
next D next N all D all N
== == = =
$iter $iter.pull ?1 $iter.pull ?2
@array @array.pull @array.values @array.pull @array
$array $array.pull $array.values $array.pull @$array
%hash %hash.pull %hash.values@array.pull %hash.values
$hash $hash.pull $hash.values@array.pull $hash.values
After all, a pull is the other end of a push.
Larry
Re: Synopsis 2 draft 1 -- each and every
Matt Diephouse writes:
>for $foo.records :sep"," { ... }
>
> The trouble is that using a for loop builds a list in memory, which
> can be troublesome.
I think that in Perl 6 C doesn't build a list in memory, so as to
avoid the troublesome bits.
Smylers
Re: Synopsis 2 draft 1 -- each and every
On Thu, 19 Aug 2004 10:38:48 -0500, Dan Hursh <[EMAIL PROTECTED]> wrote:
> while another $foo {..}
>
> It's 5 characters too many, but it works.
>
> Dan
At this point, you may as well use C<.records> (think C<$/> -- record
separator):
for $foo.records { ... }
Then it'd be a small step to allow:
for $foo.records :sep"," { ... }
--or--
for $foo.records(",") { ... }
to override C<$/>. Ideally, you'd have C<.lines> to use as well. It's
not nearly general enough, but in many (most?) cases it would provide
the wanted behavior.
The trouble is that using a for loop builds a list in memory, which
can be troublesome. But I suppose a singular version could be used to
act as an iterator:
while my $rec = $foo.record :sep"\n" { ... }
while my $line = $foo.line { ... }
Or maybe one method could be used both ways, depending on whether it's
called in list or scalar context. But you wouldn't get the implicit
assignment to C<$_>.
--
matt
Re: Synopsis 2 draft 1 -- each and every
On Thu, Aug 19, 2004 at 05:08:55AM -0600, Luke Palmer wrote:
: Well, C gives you a one-iteration loop. But perhaps list
: flatten could work on iterators:
:
: for *$foo { ... }
I dislike that purely on visual grounds in the case of
for *$*IN { ... }
But I expect most folks will end up writing $IN instead of $*IN anyway.
[snip]
: The array abstraction doesn't work well for iterators, so perhaps
: that's not the best way to go.
At the moment there seem to be two related punctuational forms:
for <$iter> {...}
for $iter.<> {...}
: I'm personally a fan of "every" as well as renaming Ruby's "each" to
: something else.
We can settle on a word form later if necessary. Then if we make it
a long enough word almost nobody will use it unless they really want
to steal <> badly. :-)
Of course a conniving thief might steal the angles from <$iter>
without stealing them from $iter.<>.
Larry
Re: Synopsis 2 draft 1 -- each and every
On Thu, Aug 19, 2004 at 10:38:48AM -0500, Dan Hursh wrote:
> David Green wrote:
>
> >...but "print next $foo" is better than "print each $foo". ...
>
> print another $foo
>
> for another $foo {...}
>
> while another $foo {..}
>
> It's 5 characters too many, but it works.
print more $foo;
for more $foo { ... } # er ...
while more $foo { ... }
It sorta works.
I like "each" best though. Why exactly can't it work?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Synopsis 2 draft 1 -- each and every
David Green wrote:
...but "print next $foo" is better than "print each $foo". ...
print another $foo
for another $foo {...}
while another $foo {..}
It's 5 characters too many, but it works.
Dan
Re: Synopsis 2 draft 1 -- each and every
David Green writes:
> On 8/19/04, [EMAIL PROTECTED] (David Green) wrote:
> > >On Aug 14, 2004, at 5:52 PM, Larry Wall wrote:
> >
> > >>for all $*IN # all() is junction
> > >>for each $*IN # each method wants closure if we follow Ruby
> > >>for next $*IN # next $foo is a loop exit
> [...]
> >"Each" and "every" are the obvious choices, but I wouldn't want to
> >follow Ruby exactly: "each" has a definite connotation of
> >"separately", "one at a time" that works in "for each $foo"; "every"
> >works better for the overall method.
>
> Hang on -- should we be saying "for each $foo" or "for $foo.each"
> anyway? We don't say "for @foo.each"; the iteration is implicit. So
> I'm thinking it should be "for $foo" or "while next $foo".
Well, C gives you a one-iteration loop. But perhaps list
flatten could work on iterators:
for *$foo { ... }
Which presumably is the same thing as:
for @$foo { ... }
Which implies that iterators can behave as arrays. Then you get to
weird questions like what:
$foo[-1]
Does. Iterate to the end and return that? The array abstraction
doesn't work well for iterators, so perhaps that's not the best way to
go.
I'm personally a fan of "every" as well as renaming Ruby's "each" to
something else.
Luke
Re: Synopsis 2 draft 1 -- each and every
On 8/19/04, [EMAIL PROTECTED] (David Green) wrote:
> >On Aug 14, 2004, at 5:52 PM, Larry Wall wrote:
>
> >>for all $*IN # all() is junction
> >>for each $*IN # each method wants closure if we follow Ruby
> >>for next $*IN # next $foo is a loop exit
[...]
>"Each" and "every" are the obvious choices, but I wouldn't want to
>follow Ruby exactly: "each" has a definite connotation of
>"separately", "one at a time" that works in "for each $foo"; "every"
>works better for the overall method.
Hang on -- should we be saying "for each $foo" or "for $foo.each"
anyway? We don't say "for @foo.each"; the iteration is implicit. So
I'm thinking it should be "for $foo" or "while next $foo".
(If we could call it "next", which is even more desirable now, seeing as
the main place where "each" made sense was "for each", where it should
be implicit anyway -- "while each $foo" doesn't sound as good, though I
guess it's passable; "print each $foo" sounds like it's looping even
though it isn't. "print following $foo"? "print subsequent $foo"? The
latter could be abbreviated to $foo.seq )
Hm, we don't need a fixed name to be able to use the iterator
implicitly, though. Why not
method another is iterator { ... }
using a trait to identify the iterating method(s?). That neatly passes
the buck of what to call it to the individual programmer instead. =)
- David "not sure whether the idea of overloading ++ as
an iterator can be mentioned in polite company" Green
Re: Synopsis 2 draft 1 -- each and every
On 8/15/04, [EMAIL PROTECTED] (David Wheeler) wrote:
>On Aug 14, 2004, at 5:52 PM, Larry Wall wrote:
>>for all $*IN # all() is junction
>>for each $*IN # each method wants closure if we follow Ruby
>>for next $*IN # next $foo is a loop exit
>
>Hmm. Maybe the problem is that we shouldn't follow Ruby on .each's
>signature. How about we have .apply or .filter do the Ruby implicit
>iteration thing, and keep .each for iterating iterators.
"Each" and "every" are the obvious choices, but I wouldn't want to follow
Ruby exactly: "each" has a definite connotation of "separately", "one at a
time" that works in "for each $foo"; "every" works better for the overall
method.
("All" has an "all at once" sense that fits its junctive use; "next"
certainly has the right meaning: "for next $foo" sounds funnier than "for
each $foo", but "print next $foo" is better than "print each $foo". I
suppose loop-next could be renamed "cont" except that we just renamed the
continue block to NEXT -- perhaps there's some clever way to unify them and
use "next" for both cases?)
>>@bar = @foo.filter:{ $_ * 2 };
>>filter @foo: { $_ * 2 } ==> @bar;
>
>C is good for this; I like it. But if you decide you need to
>keep it as C,
>then I personally really don't mind using C for the iterator method.
morph @foo: { $_ * 2 } ==> @bar; ? #less typing than "transmute"
Personally, I like "apply", since the actual word "filter" means something
more like 'grep' than 'map', but I guess in computer lingo, filters are
often understood to map stuff. (FOLDOC tells me that Haskell's equivalent
to "grep" is spelled "filter". (Though it might make more sense for the
condition to be negated -- hm, if we have if/unless, while/until, why not
grep/filter?))
-David "munge @foo: { $_ * 2 } ==> @bar; ??" Green
