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
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, [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
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
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
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. Cpop is only the opposite of Cpull if you're thinking about a stack; if you're thinking about a queue then Cshift is the current named used. So Cpop 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
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
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 Cfor 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 Cscalar! Maybe we _do_ need to revive
$()!
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 Cscalar! 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(); # taken, probably
say .myfunc(); # taken
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
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 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
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
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
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
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
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
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 %hashkey.
Luke
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
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, Cfor $foo 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
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
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
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 Cfor 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, 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 Cfor, 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
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 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
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 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 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
