Re: Apoc2 - STDIN concerns
On Thu, 10 May 2001 17:15:09 +0100, Simon Cozens wrote: What you could do, is treat an iterator as something similar to reading a line from a file. Tied filehandles allow something like it in Perl5. You know, if what you say is true, I'd expect to find a module on CPAN which turns the exotic 'each' function into the friendly tied filehandle model. But I don't see one. I think people are less confused by all this than you imagine. :) Perhaps it's because the people who are capable of writing such a module, are the ones who don't need it. But, not everyone is a conway. There must be some reason why a language like Sather isn't more popular. I think that iters are part of the problem. -- Bart.
Re: Apoc2 - STDIN concerns
On Mon, May 14, 2001 at 01:25:51PM +0200, Bart Lateur wrote: There must be some reason why a language like Sather isn't more popular. I think that iters are part of the problem. That smacks of the Politician's Syllogism: Something is wrong. This is something. Therefore this is wrong. I think the more immediate problem with Sather is that it's totally obscure. I'd never heard of it. I'd never read any articles about it. It has no publicity. If people haven't heard of it, it'll remain unpopular. Iters or no iters. -- yrlnry I think the real problem here is that he is a university CS professor and therefore knows very little about programming in the real world, in any languge.
RE: Apoc2 - STDIN concerns
On Mon, May 14, 2001 at 01:25:51PM +0200, Bart Lateur wrote: There must be some reason why a language like Sather isn't more popular. I think that iters are part of the problem. That smacks of the Politician's Syllogism: Something is wrong. This is something. Therefore this is wrong. I think the more immediate problem with Sather is that it's totally obscure. I'd never heard of it. I'd never read any articles about it. It has no publicity. If people haven't heard of it, it'll remain unpopular. Iters or no iters. Naw, they simply haven't gotten into the rage of Perlbashing, which seems to be how Python, PHP, and Ruby have made any headway. C# is going there too, but Microsoft makes it too obvious (nobody of any dignified talent reads about MS technology without a salt shaker handy.) p
Re: Apoc2 - STDIN concerns
On Thu, 10 May 2001, Larry Wall wrote:
Dave Storrs writes:
: should stick with . Also, I'd prefer to use the 'x' operator for
: specifying multiples:
:
: @foo = $STDIN x 4;
: @foo = $STDIN x mySub;
:
: The parallel with $foo = 'bar'x2;, where bar is simply repeated twice,
: is obvious: '$STDIN' iterates the, uh, iterator, and repeating that
: operation iterates it multiple times. It even reads nicely Fetch a line
: from STDIN times four (or, more idiomatically, ...four times).
Um, I don't think so. What I wrote above was just a fancy trick with
straight Perl 5 overloading. You could do that today.
I'd think that what you wrote would have to input one line from $STDIN
and then dup that line 4 times. Either that, or because it's in list
context it inputs all the lines and duplicates each 4 times, just like
@foo = @bar * 2;
maybe ought to multiply each element by two, at least the way some
numericists look at it.
Hmmm...I see your point, but I think it depends on what you see as
the operatee that 'x' is operating on. If it's the string(s) produced by
, then you're certainly right. But if it is the act of iterating
itself, then I think my suggestion is still valid. And yes, I realize
that the current behavior is always to act on the string, not the act of
calling the function that produced the string, or whatever. I just think
that we could extend 'x' to have a general repetition meaning. Imagine
the following:
our $a = 0;
our $baz = 'jaz';
sub blah {
$a++;
return 'Hi';
}
$foo = 'bar' x 2; # $foo = 'barbar'
$foo = $baz x 2;# $foo = 'jazjaz'
$foo = blah() x 2; # blah() called twice,
# $foo = 'Hi', $a = 2
$foo = join '', (blah() x 2)# blah() called twice,
# $foo = 'HiHi', $a = 4
$foo = $STDIN x 2;# read two lines, discard first,
# stick second into $foo
@foo = $STDIN x 2;# read two lines, stick into @foo
Dave
Re: Apoc2 - STDIN concerns
Dave Storrs writes:
: Hmmm...I see your point, but I think it depends on what you see as
: the operatee that 'x' is operating on. If it's the string(s) produced by
: , then you're certainly right. But if it is the act of iterating
: itself, then I think my suggestion is still valid. And yes, I realize
: that the current behavior is always to act on the string, not the act of
: calling the function that produced the string, or whatever. I just think
: that we could extend 'x' to have a general repetition meaning.
I think just patching one operator from verbal status to adverbial
status is not sufficiently general. Perl 6 will support adverbs of
some sort or other, so if you want to modify how a particular operator
works, we'll have a more general way to do that. Think of it as properties
on operators rather than on values. A number of cases come to mind
$STDIN MUMBLE 2 # read twice
1 .. 100 MUMBLE 3 # count by threes
`glob $x` MUMBLE /bin/csh # modify pseudoquote
It has not yet been decided what form these MUMBLEs will take, or even
whether they should have the same form. It may be that the default
adverbial MUMBLE is simply :. Which might cause the above to reduce
to:
$STDIN : 2# read twice
1 .. 100 : 3# count by threes
`glob $x` : /bin/csh # modify pseudoquote
Non-default adverbs might then be more qualified:
1 .. 100 :where { ok($^) }
If repeat count weren't the default adverb for , then maybe you'd write:
$STDIN :x 2
One could even imagine using colon as an optional indirect object
syntax disambiguator, analyzed as if the argument list were the default
adverb modifying the method call:
print $HANDLE{$dest} : @args;
Although making : take a list on the right by default would be, er,
interesting from a precedence point of view.
So I'm still MUMBLEing about that for now.
Larry
Re: Apoc2 - STDIN concerns
On Fri, 11 May 2001, Larry Wall wrote: Dave Storrs writes: : calling the function that produced the string, or whatever. I just think : that we could extend 'x' to have a general repetition meaning. I think just patching one operator from verbal status to adverbial status is not sufficiently general. [...] $STDIN MUMBLE 2 # read twice 1 .. 100 MUMBLE 3 # count by threes `glob $x` MUMBLE /bin/csh # modify pseudoquote It has not yet been decided what form these MUMBLEs will take, [...but maybe the default] adverbial MUMBLE is simply :. Which might cause the above to reduce to: $STDIN : 2 # read twice 1 .. 100 : 3 # count by threes `glob $x` : /bin/csh# modify pseudoquote Wow. This is great; very powerful and very elegant...how Perlish. $verb = I cc 'tow'x2 cc ' admiringly'; $verb =~ s/t/k/; # ; Dave
Re: Apoc2 - STDIN concerns ::::: new mascot?
(apologies if this is a duplicate - I think my last post has gotten lost). The RFC pleads for a community spirit from ORA. Barring that, it seeks a new symbol for the community entirely I'd suggest a mongoose - eats poisonous snakes for breakfast. There's a sort of tie-in with Perl Mongers == Perl Mongoose as well :-) Dave.
RE: Apoc2 - STDIN concerns ::::: new mascot?
/me likes. /me likes a lot. David T. Grove Blue Square Group [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Dave Hartnoll [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 10, 2001 8:56 AM To: [EMAIL PROTECTED] Subject: Re: Apoc2 - STDIN concerns : new mascot? (apologies if this is a duplicate - I think my last post has gotten lost). The RFC pleads for a community spirit from ORA. Barring that, it seeks a new symbol for the community entirely I'd suggest a mongoose - eats poisonous snakes for breakfast. There's a sort of tie-in with Perl Mongers == Perl Mongoose as well :-) Dave.
Re: Apoc2 - STDIN concerns
On Tue, 8 May 2001, Larry Wall wrote: In this view, * and could just be two different kinds of expandable flags. But I'm uncomfortable with that, because I'd like to be able to say lazy_sub($STDIN, $STDIN, $STDIN, $STDIN) to feed four lines to lazy_sub without defeating the prototype, er, signature checking. Maybe you have to us *$STDIN to do both. But that would probably say to slurp the whole rest of the file. You know, it would be really cool if you specify the number of lines you wanted like so: $STDIN # One line *$STDIN# All available lines *4$STDIN # Next 4 lines Or even: *$num_lines$STDIN # Numifies $num_lines, gets that many *int rand(6)$STDIN # Gets 0-5 lines *mySub($bar)$STDIN# mySub returns num, gets that many Dave
Re: Apoc2 - STDIN concerns
Dave Storrs wrote: *4$STDIN # Next 4 lines *$num_lines$STDIN # Numifies $num_lines, gets that many *int rand(6)$STDIN # Gets 0-5 lines *mySub($bar)$STDIN# mySub returns num, gets that many Shades of printf... -- John Porter
Re: Apoc2 - STDIN concerns
On Fri, 4 May 2001 18:20:52 -0700 (PDT), Larry Wall wrote: : love. I'd expect $FOO.readln (or something less Pascalish) to do an : explicit readline to a variable other than $_ It would be $FOO.next, but yes, that's the basic idea. It's possible that iterator variables should be more syntactically distinquished than that. One could, I suppose, make up something about $FOO or $FOO meaning the same thing thing as $FOO.next, for people who are homesick for the angles, but I haven't thought that out, and don't even dare to mention it here for fear someone will take it as a promise. Er, oops... Just my thoughts: this is sick. I am having great difficulties in trying to wrap my mind around iterators. I expect that I'm far from alone at that. People are *very much* familiar with reading a line from a file. People may steer clear from a language because it deeply relies on exotic stuff like iterators. So trying to turn read a line from a file into a special case for an iterator, is the wrong way around. What you could do, is treat an iterator as something similar to reading a line from a file. Tied filehandles allow something like it in Perl5. Doing the reverse is, er, insane. -- Bart.
Re: Apoc2 - STDIN concerns
Dave Storrs writes: : You know, it would be really cool if you specify the number of : lines you wanted like so: : : $STDIN # One line : *$STDIN# All available lines : *4$STDIN # Next 4 lines : : Or even: : : *$num_lines$STDIN # Numifies $num_lines, gets that many : *int rand(6)$STDIN # Gets 0-5 lines : *mySub($bar)$STDIN# mySub returns num, gets that many Given appropriate overloading on the iterator object: @foo = $STDIN * 4; Larry
Re: Apoc2 - STDIN concerns
At 05:56 PM 5/10/2001 +0200, Bart Lateur wrote: On Fri, 4 May 2001 18:20:52 -0700 (PDT), Larry Wall wrote: : love. I'd expect $FOO.readln (or something less Pascalish) to do an : explicit readline to a variable other than $_ It would be $FOO.next, but yes, that's the basic idea. It's possible that iterator variables should be more syntactically distinquished than that. One could, I suppose, make up something about $FOO or $FOO meaning the same thing thing as $FOO.next, for people who are homesick for the angles, but I haven't thought that out, and don't even dare to mention it here for fear someone will take it as a promise. Er, oops... Just my thoughts: this is sick. Right, but is this a good thing or a bad thing? I am having great difficulties in trying to wrap my mind around iterators. I expect that I'm far from alone at that. People are *very much* familiar with reading a line from a file. People may steer clear from a language because it deeply relies on exotic stuff like iterators. So trying to turn read a line from a file into a special case for an iterator, is the wrong way around. Really? I don't think so. Filehandles really *are* iterators on files. Granted I'm one of the folks homesick for the angles (I like the visual distinction and contextual diambiguation (And no, I can't believe I just typed that...)) but even without them it makes a lot of sense. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apoc2 - STDIN concerns
On Thu, May 10, 2001 at 05:56:41PM +0200, Bart Lateur wrote: People are *very much* familiar with reading a line from a file. People may steer clear from a language because it deeply relies on exotic stuff like iterators. ... What you could do, is treat an iterator as something similar to reading a line from a file. Tied filehandles allow something like it in Perl5. You know, if what you say is true, I'd expect to find a module on CPAN which turns the exotic 'each' function into the friendly tied filehandle model. But I don't see one. I think people are less confused by all this than you imagine. :) -- Having just ordered 40 books and discovered I have no change out of a grand, I'm thinking of getting a posse together and going after some publishers. I'd walk into a petrol station and buy lots of petrol on Monday, too, but I think I'd get funny looks. More funny looks. - Mark Dickerson
Re: Apoc2 - STDIN concerns ::::: new mascot?
The RFC pleads for a community spirit from ORA. Barring that, it seeks a new symbol for the community entirely I'd suggest a mongoose - eats poisonous snakes for breakfast. There's a sort of tie-in with Perl Mongers == Perl Mongoose as well :-) Dave.
Re: Apoc2 - STDIN concerns
QUOTE LARRY Dave Storrs writes: : You know, it would be really cool if you specify the number of : lines you wanted like so: : : $STDIN # One line : *$STDIN# All available lines : *4$STDIN # Next 4 lines : : Or even: : : *$num_lines$STDIN # Numifies $num_lines, gets that many : *int rand(6)$STDIN # Gets 0-5 lines : *mySub($bar)$STDIN# mySub returns num, gets that many Given appropriate overloading on the iterator object: @foo = $STDIN * 4; Larry END QUOTE Actually, on more reflection, I'm going to side with the people who say that the single-character version is not an improvement, and that we should stick with . Also, I'd prefer to use the 'x' operator for specifying multiples: @foo = $STDIN x 4; @foo = $STDIN x mySub; The parallel with $foo = 'bar'x2;, where bar is simply repeated twice, is obvious: '$STDIN' iterates the, uh, iterator, and repeating that operation iterates it multiple times. It even reads nicely Fetch a line from STDIN times four (or, more idiomatically, ...four times). Dave
RE: Apoc2 - STDIN concerns ::::: new mascot?
Probably not if it had scales, webbed feet, a hookbill, antennae, a furry coontail, and udders. Otherwise, if it looks like a camel at all, it's considered a trademark violation. I remember someone (whether at O'Reilly or not I don't remember) saying that, even if it looks like a horse but has a hump, it's not allowed. Or was that an alpaca with a llama... The RFC pleads for a community spirit from ORA. Barring that, it seeks a new symbol for the community entirely. A three-humped camel may give a good visual for Perl 6 as it exists today (fantasy and a bit convoluted), but it may be a bit difficult to apply to the upcoming completed language. ;-) BTW, what happened to meta? After a server outage of some length I believe I was removed, but it appears no longer to exist when I try to subscribe. David T. Grove Blue Square Group [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: RFC850 host name inserted by qmail-smtpd [mailto:[EMAIL PROTECTED]]On Behalf Of David L. Nicol Sent: Tuesday, May 08, 2001 5:12 PM To: Larry Wall; [EMAIL PROTECTED] Subject: Re: Apoc2 - STDIN concerns : new mascot? Larry Wall wrote: there seems to be a shortage of three-humped camels. At last! the unencumbered image for the mascot! Could O'Reilly really claim a three-humped camel was an image of a camel, with a straight face?
Re: Apoc2 - STDIN concerns ::::: new mascot?
On Wed, 9 May 2001 10:24:26 -0400, David Grove wrote: I remember someone (whether at O'Reilly or not I don't remember) saying that, even if it looks like a horse but has a hump, it's not allowed. Or was that an alpaca with a llama... The RFC pleads for a community spirit from ORA. Barring that, it seeks a new symbol for the community entirely. Several perl ports, and at least one book, use a shiny ball as a symbol. http://www.effectiveperl.com Scroll down to the heading Book Nickname (?). It took me a bit of thinking before I realized what this shiny ball represents. Odd. -- Bart.
Re: Apoc2 - STDIN concerns ::::: new mascot?
On Wed, May 09, 2001 at 04:50:51PM +0200, Bart Lateur wrote: Several perl ports, and at least one book, use a shiny ball as a symbol. It took me a bit of thinking before I realized what this shiny ball represents. Odd. Beginning Perl was going to use a blown-up microscope slide of a grain of sand - the beginnings of a pearl. Of course, nobody would have got it, so we went with a cat instead, which is even more oblique. -- You're never alone with a news spool.
RE: Apoc2 - STDIN concerns ::::: new mascot?
I've often thought about trademarking a Shiny Ball (Perl) and an oyster/clam/mussel shell with association to the Perl language. The first thought is to give a demonstration on how rude holding this type of symbol is. But, I'd have licensed it to the community openly after an initial snit. I didn't do it because it would have taken $600 to prove a point. David T. Grove Blue Square Group [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Bart Lateur [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 09, 2001 10:51 AM To: [EMAIL PROTECTED] Subject: Re: Apoc2 - STDIN concerns : new mascot? On Wed, 9 May 2001 10:24:26 -0400, David Grove wrote: I remember someone (whether at O'Reilly or not I don't remember) saying that, even if it looks like a horse but has a hump, it's not allowed. Or was that an alpaca with a llama... The RFC pleads for a community spirit from ORA. Barring that, it seeks a new symbol for the community entirely. Several perl ports, and at least one book, use a shiny ball as a symbol. http://www.effectiveperl.com Scroll down to the heading Book Nickname (?). It took me a bit of thinking before I realized what this shiny ball represents. Odd. -- Bart.
RE: Apoc2 - STDIN concerns ::::: new mascot?
/me ponders the use of a cat in that context... Furball? David T. Grove Blue Square Group [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Simon Cozens [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 09, 2001 10:55 AM To: [EMAIL PROTECTED] Subject: Re: Apoc2 - STDIN concerns : new mascot? On Wed, May 09, 2001 at 04:50:51PM +0200, Bart Lateur wrote: Several perl ports, and at least one book, use a shiny ball as a symbol. It took me a bit of thinking before I realized what this shiny ball represents. Odd. Beginning Perl was going to use a blown-up microscope slide of a grain of sand - the beginnings of a pearl. Of course, nobody would have got it, so we went with a cat instead, which is even more oblique. -- You're never alone with a news spool.
Re: Apoc2 - STDIN concerns ::::: new mascot?
On Wed, May 09, 2001 at 11:02:52AM -0400, David Grove wrote: oyster/clam/mussel shell with association to the Perl language. The first thought is to give a demonstration on how rude holding this type of symbol is. I think all it would demonstrate is how flawed the copyright system is. But then, we knew that, right? -- but I'm one guy working weekends - what the hell is MS's excuse? We don't care, we don't have to, we're the phone company. - Ben Jemmet, Paul Tomblin.
Re: Apoc2 - STDIN concerns ::::: new mascot?
And there was me thinking the shiny ball must be a camel dropping
Re: Apoc2 - STDIN concerns ::::: new mascot?
At 04:06 PM 5/9/2001 +0100, Simon Cozens wrote: On Wed, May 09, 2001 at 11:02:52AM -0400, David Grove wrote: oyster/clam/mussel shell with association to the Perl language. The first thought is to give a demonstration on how rude holding this type of symbol is. I think all it would demonstrate is how flawed the copyright system is. Nope. It'd demonstrate how flawed the trademark system is. Copyright flaws are completely different.. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Apoc2 - STDIN concerns ::::: new mascot?
Core Perl is probably trademarked to Sun Microsystems. ;-) David T. Grove Blue Square Group [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: John L. Allen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 09, 2001 1:29 PM To: [EMAIL PROTECTED] Subject: Re: Apoc2 - STDIN concerns : new mascot? On Wed, 9 May 2001, Simon Cozens wrote: Beginning Perl was going to use a blown-up microscope slide of a grain of sand - the beginnings of a pearl. Of course, nobody would have got it, so we went with a cat instead, which is even more oblique. Hmmm, I suppose a blown-up grain of sand could also be used on the cover of a book about advanced perl internals, because a grain of sand is what's at the core of a pearl. John.
Re: Apoc2 - STDIN concerns
At 16:17 May 7, Simon Cozens wrote: On Mon, May 07, 2001 at 01:14:12PM -0700, Nathan Wiger wrote: I think Uri's qh() suggestion is the cleanest: Interesting train of thought, since one of the ideas was that qw() is ugly and has to go. (Larry's been saying this for nearly two years now, it's just that people sometimes don't listen. :) Let's keep it and add something similarly ugly to keep it company! -- And the fact is, I've always loathed qw(), despite the fact that I invented it myself. :-) -- Larry Wall in [EMAIL PROTECTED] Well, one person's ugly is another person's joy forever. Regardless of the aesthetics of q//, qq//, qw//, et al, (and here docs too), they get the job done in a remarkably flexible, efficient way that is simply not possible with just about any other language out there. 9 times out of 100, qw saves a large number of keystrokes. (The other 1% of the time, you have to work around qw's inability to quote things with spaces). qq, q, and here-docs may be ugly, but that's a judgment call. What they are not is broken. Personally, I don't understand how using two alphabetic characters and a pair of delimiters, in order to save typing a whole mess of quotes and backslashes, can be construed as ugly. :-) And, while I'm on my soapbox here, I don't get how ... is a vast improvement over qw :-) -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: Apoc2 - STDIN concerns
In a fit of insanity, at 10:14 EDT Tue May 8, I wrote: 9 times out of 100, qw saves a large number of keystrokes. (The other 1% of the time, ... I hope it's obvious that I meant 99 times out of 100 sheepish look -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: Apoc2 - STDIN concerns
Eric Roode writes: : And the fact is, I've always loathed qw(), despite the fact that I : invented it myself. :-) : -- Larry Wall in [EMAIL PROTECTED] : : : Well, one person's ugly is another person's joy forever. : : Regardless of the aesthetics of q//, qq//, qw//, et al, (and here : docs too), they get the job done in a remarkably flexible, efficient : way that is simply not possible with just about any other language : out there. : : 9 times out of 100, qw saves a large number of keystrokes. (The : other 1% of the time, you have to work around qw's inability to : quote things with spaces). : : qq, q, and here-docs may be ugly, but that's a judgment call. What : they are not is broken. : : Personally, I don't understand how using two alphabetic characters : and a pair of delimiters, in order to save typing a whole mess of : quotes and backslashes, can be construed as ugly. :-) : : And, while I'm on my soapbox here, I don't get how ... is a vast : improvement over qw :-) Please pardon my hyperbole. I don't loathe qw() so badly that I want to get rid of it. I merely want to put it in the same status as the other general quote operators that also have a non-general pair of standard quote characters. I would feel the same about qq// if there weren't a . Larry
Re: Apoc2 - STDIN concerns
John Porter writes: : Pardon me if someone has already suggested this, but... : Couldn't labels really be (aliases to) iterator objects? : So that : next FOO : really *does* mean : FOO.next Ordinary next methods don't do a goto. Larry
Re: Apoc2 - STDIN concerns
Nathan Wiger writes:
: One thing I think we should avoid is as many special cases as possible.
: This is already why people hate currently - because it does both glob()
: and readline().
:
: I would say that having history is actually a good thing. It's a
: foundation, really, since readline() is an iterator of sorts. All we'd be
: doing is generalizing the notion. Not only does it apply to files, but it's
: a shortcut to more() wherever you feel like using it.
Taking history into account is good, though I'd argue that now is the
proper time to change history, if we're going to change. Perl would
never have been accepted in the first place had it been too different
from what came before, but now that Perl has its own momentum, we can
now look at how our own history gets in our way, and maybe do something
about it.
: As for as a qw() replacement, I think there are really two issues here.
: First, you're not really talking about a replacement, since you're
: mentioning different semantics. So qw() will still be widely used. I suggest
: that we simply create another q-op to do the qw-ish things you're proposing.
: Perhaps qi() for interpolate or something else.
I think someone mentioned qh() for hash. That's a possibility, but I'd
still love to have enough brackets to give all of these standard shortcuts.
: Plus has the terrible
: problem that the POD C stuff does w/ embedded chars. The really nice
: thing about the q's is you can choose any bracket you want. I think fleshing
: out this series of constructs makes the most sense.
No problem with that, though we probably need to reserve qA .. qZ for
the user.
: I'd so this differently, as hinted at above:
:
:%foo{$STDIN};# return all values
:%foo{$STDIN); # return one value
:%foo{$STDIN}; # pass the $STDIN variable
Syntactically speaking it's too ambiguous to have both a unary and a
bracketing .
: This is assuming that we want to exist and have a different semantics. But
: I'm not sure that's a good idea. For one thing, you'd have to mention it
: several times if you want a couple values. I think there's got to be a
: better way to request the number of lines based on context.
:
:%foo{$STDIN}; # the whole thing
:%foo{ (1..2) = $STDIN }; # anonymous list request?
:%foo{ $STDIN[1..2] }; # or notate it as a list?
:%foo{ ($STDIN.more)[1..2] }; # same thing
:
: The last one seems to make sense (it's got those (localtime)[2,3] roots),
: with the third one as a shortcut.
:
: Looking at it from the iterator object end, there might really be three
: methods:
:
: $STDIN.next # Return one element regardless of context.
: $STDIN.more # Return number of element wanted by context.
: $STDIN.all # Return all element regardless of context.
:
: Or maybe there's only a more method, and you simply have to force the
: context if you don't want it to guess.
:
: I think one method is the way to go. Let the subs and other contexts request
: the number of elements to get back using lazy evaluation:
:
:@foo[1..10] = $STDIN; # get 10 iterations
:$bar = $STDIN;# next one
:lazy_sub($STDIN);# lazily
:
: Assuming:
:
:sub lazy_sub ($a, $b, $c, $d) { }
:
: Then the last line above would lazily grab the next four lines.
I'd say that interpretation makes it a non-greedy equivalent to the
unary *, in that it defeats the prototype, er, signature. That would
be an argument for unary , I think.
: We don't actually have a good
: notation for forcing a scalar context yet, let alone a scalar context
: wanting a certain number of arguments.
:
: Personally, I'd look at it differently. I don't think that getting a number
: of arguments out of a scalar context makes sense. Rather, I think you need
: to call a member function or do whatever to get a list, then lazily evaluate
: that.
:
:@a = $STDIN;# @a gets a single element - $STDIN
:@b = $STDIN; # @b gets the entire contents of $STDIN
:# iterations via calls to more()
You don't actually get the entire contents of $STDIN. You get a value
of $STDIN marked as a placeholder in the list assigned to @b, and that
placeholder says the RHS requested expansion of this in a manner
appropriate to the context supplied by the LHS.
Assuming Perl 5 semantics of = continue, a similar thing will happen
when you say:
@a = @b;
or
push(@c, @b);
Perl 6 might not put all the elements of @b on the stack as a temporary
list. Rather, it might just put \@b marked as expandable. (It might
also have to put some kind of copy-on-write lock on @b to keep it from
changing out from under, depending on how lazy the assignment (or
subroutine) actually gets about reading out the array.)
In this view, * and could just be two different kinds of expandable flags.
But I'm uncomfortable with that, because I'd like to be able to say
lazy_sub($STDIN, $STDIN, $STDIN, $STDIN)
to feed
qX (was Re: Apoc2 - STDIN concerns)
LW == Larry Wall [EMAIL PROTECTED] writes: LW Please pardon my hyperbole. I don't loathe qw() so badly that I LW want to get rid of it. I merely want to put it in the same status LW as the other general quote operators that also have a non-general LW pair of standard quote characters. I would feel the same about LW qq// if there weren't a . larry, we forgive you. but can you understand our concern? you did use very strong language describing your negative feelings about qw without the context you provided above. but now a question arises, why must there be a non-q version of qw to be symmetrical with /qq? i (and i sense many others) feel that qw by itself is fine and stealing for it is not a great use of precious funny chars. and if there is an extension as i have proposed of other qX operators, then you won't be able to make them all have funny char counterparts. speaking of qX and qh in particular, i realized that supporting a way to have = as a key or value is not worth the effort. just as with qw and embedded white space, if you want complex data, use a normal list of quoted strings. qw and qh are meant as shortcuts for common and simple data sets. embedded white space and = as a string are not simple. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11 Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
Re: Apoc2 - STDIN concerns
Lipscomb, Al writes:
: --_=_NextPart_001_01C0D71B.8F67C8EA
: Content-Type: text/plain;
: charset=iso-8859-1
:
:
:
: $$STDIN # Return one element regardless of context.
: @$STDIN # Return number of element wanted by context.
: *$STDIN # Return all element regardless of context.
:
:
: How about
:
:
: $STDIN.$ # Return one element regardless of context.
: $STDIN.@ # Return number of element wanted by context.
: $STDIN.* # Return all element regardless of context.
Well, those would be the same thing according to the identity:
word $obj
$obj.word
if you consider '$', '@', and '*' as words. There's some destructive
interference with the Perl 5 dereferencing meaning, which probably
means that casts can't simply be funny characters when there's a $ on
the inside. That's why I was looking at $: and $ variants. But
there's also the $() and @() variants, which we've already said will do
interpolation of scalar and list expressions in strings. So $($foo)
probably means a cast rather than a dereference like ${$foo} (note
curlies). I suppose it's fair to ask whether $$foo ought to mean the
first rather than the second, but that's definitely going again history
to make it a cast.
Larry
Re: Apoc2 - STDIN concerns
Peter Scott writes: : At 01:51 AM 5/6/01 +0100, Simon Cozens wrote: : The debate rages on: Is Perl Bactrian or Dromedary? : : It's a Dromedary, it says so in the Colophon. : : But maybe the symbol of Perl 6 should be a Bactrian, with the extra hump : symbolizing the increased power. : : You knew this was coming... That question already arose for the second edition of the Camel book. The answer is related to the fact that we already have a third edition, and there seems to be a shortage of three-humped camels. Larry
Re: Apoc2 - STDIN concerns
At 09:32 AM 5/8/2001 -0700, Larry Wall wrote: Perl 6 might not put all the elements of @b on the stack as a temporary list. Rather, it might just put \@b marked as expandable. (It might also have to put some kind of copy-on-write lock on @b to keep it from changing out from under, depending on how lazy the assignment (or subroutine) actually gets about reading out the array.) s/might not/won't/; One of the places I hope to gain some speed is in eliminating flattening and reconstitution of aggregate variables as much as possible. I'm hoping to exploit this really heavily to save both the memory for the flattened lists and the time it takes to flatten and reconstitute. (If we're really lucky we might even be able to rehome some of the underlying data structures, making returning a 10M entry hash cost about one pointer assignment) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apoc2 - STDIN concerns
On Tue, May 08, 2001 at 09:44:57AM -0700, Larry Wall wrote:
there seems to be a shortage of three-humped camels.
No wonder we're short, they're rather careless with them...
The Three-humped Camel:
An advertisement once appeared in a Welsh local paper which
read: 'Last - one three-humped camel. Owner desperat.
Reward.' A telephone number was given for people to ring. The
landlord of the local pub was not very pleased. It was his number
that had been given and over 70 people rang him, claiming to
have seen his non-existent camel.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
grep { ref and ref !~ /^[A-Z]+$/ } kill 9, @ARGV;
Re: Apoc2 - STDIN concerns
Larry Wall wrote: Ordinary next methods don't do a goto. Well, of course, the next method of a syntactic loop control iterator object would not be ordinary. :-) -- John Porter
Re: Apoc2 - STDIN concerns
Dan Sugalski writes: : At 09:32 AM 5/8/2001 -0700, Larry Wall wrote: : Perl 6 might not put all the elements of @b on the stack as a temporary : list. Rather, it might just put \@b marked as expandable. (It might : also have to put some kind of copy-on-write lock on @b to keep it from : changing out from under, depending on how lazy the assignment (or : subroutine) actually gets about reading out the array.) : : s/might not/won't/; : : One of the places I hope to gain some speed is in eliminating flattening : and reconstitution of aggregate variables as much as possible. I'm hoping : to exploit this really heavily to save both the memory for the flattened : lists and the time it takes to flatten and reconstitute. (If we're really : lucky we might even be able to rehome some of the underlying data : structures, making returning a 10M entry hash cost about one pointer : assignment) I suspect one way this saves us a lot of overhead is in knowing how much memory to allocate for a given subroutine's stack frame. The way it is done in Perl 5, we pay the variadic stack overhead even on subroutines that are known not to be variadic. This is suboptimal, since you have to be ready to extend the stack at any moment. (It also tends to pessimize linkage into pseudo-variadic languages like C.) Larry
Re: Apoc2 - STDIN concerns
On Tue, May 08, 2001 at 01:32:24PM -0400, John Porter wrote: a syntactic loop control iterator object I surely hope you're joking. -- I respect faith, but doubt is what gives you an education. -- Wilson Mizner
Re: Apoc2 - STDIN concerns
At 10:32 AM 5/8/01 -0700, Larry Wall wrote: : One of the places I hope to gain some speed is in eliminating flattening : and reconstitution of aggregate variables as much as possible. I'm hoping : to exploit this really heavily to save both the memory for the flattened : lists and the time it takes to flatten and reconstitute. (If we're really : lucky we might even be able to rehome some of the underlying data : structures, making returning a 10M entry hash cost about one pointer : assignment) I suspect one way this saves us a lot of overhead is in knowing how much memory to allocate for a given subroutine's stack frame. The way it is done in Perl 5, we pay the variadic stack overhead even on subroutines that are known not to be variadic. This is suboptimal, since you have to be ready to extend the stack at any moment. (It also tends to pessimize linkage into pseudo-variadic languages like C.) Um, how do you know for sure a subroutine isn't variadic? Even if it has a fixed-length prototype, is Perl smart enough to know that it can't be called as an object method, bypassing prototype checking? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: Apoc2 - STDIN concerns
Simon Cozens wrote: John Porter wrote: a syntactic loop control iterator object I surely hope you're joking. Why? It sounds reasonable to me (if not necessarily desirable). Perl is a highly dynamic language, I think it could support this. -- John Porter
Re: Apoc2 - STDIN concerns
Peter Scott wrote: Even if it has a fixed-length prototype, is Perl smart enough to know that it can't be called as an object method, bypassing prototype checking? Maybe p6 won't have that loophole. -- John Porter
Re: Apoc2 - STDIN concerns
Simon Cozens writes: : On Tue, May 08, 2001 at 01:32:24PM -0400, John Porter wrote: : a syntactic loop control iterator object : : I surely hope you're joking. It could certainly be argued that anything you can put a label on is an object by some definition or other. And certainly it turns into a kind of parse tree object to which the label can be pasted. And while the parse tree object is hopefully totally static, the use of it in a dynamic context may require keeping track of some amount of state, which we might deign to keep in an object of some sort or other. Whether there's any point in making these internal objects visible to the user is another matter indeed. It's possible to view Perl 5 as full of objects that the user has no direct access to. Just because Perl 6 might give more access to some of these internal objects does not mean that most people can't go blissfully on their way in ignorance of the underlying mechanisms. larry
Re: Apoc2 - STDIN concerns
John Porter writes: : Peter Scott wrote: : Even if it has a : fixed-length prototype, is Perl smart enough to know that it can't be : called as an object method, bypassing prototype checking? : : Maybe p6 won't have that loophole. It won't, if the type of the object can be determined at compile time. If you declare Cmy Dog $spot, it'll be assumed you're calling methods that are consistent with the declarations in the Dog interface, even if it happens to be a Poodle or a Chihauhau. I hope that named argument notation of some sort will prevent this from being a burden on subclasses that wish to extend methods of base classes that weren't defined to be sufficiently extensible in the first place. But I could be wrong... Larry
Re: Apoc2 - STDIN concerns
At 10:57 AM 5/8/2001 -0700, Peter Scott wrote:
At 10:32 AM 5/8/01 -0700, Larry Wall wrote:
: One of the places I hope to gain some speed is in eliminating flattening
: and reconstitution of aggregate variables as much as possible. I'm hoping
: to exploit this really heavily to save both the memory for the flattened
: lists and the time it takes to flatten and reconstitute. (If we're really
: lucky we might even be able to rehome some of the underlying data
: structures, making returning a 10M entry hash cost about one pointer
: assignment)
I suspect one way this saves us a lot of overhead is in knowing how
much memory to allocate for a given subroutine's stack frame. The way
it is done in Perl 5, we pay the variadic stack overhead even on
subroutines that are known not to be variadic. This is suboptimal,
since you have to be ready to extend the stack at any moment. (It also
tends to pessimize linkage into pseudo-variadic languages like C.)
Um, how do you know for sure a subroutine isn't variadic? Even if it has
a fixed-length prototype, is Perl smart enough to know that it can't be
called as an object method, bypassing prototype checking?
Why assume that method calls will bypass prototype checking?
Larry and I were sort of talking about different things, too. I was
contemplating the case of return values that looks like:
sub bar {
my @foo;
$foo[time]=1;
return @foo;
}
while Larry seems to be talking about passing parameters into subs. Both
are certainly issues, and related ones. (I'd not given passing parameters
in much thought)
The optimizer's in a pretty good position to figure out exactly what you're
doing if it's given enough time to do it in. By the time it gets the
bytecode, there's not a whole lot of uncertainty left. (If I'm lucky, and
yes I know we'll have stuff like $foo-$bar to contend with, however the
syntax ultimately goes)
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Apoc2 - STDIN concerns
At 10:32 AM 5/8/2001 -0700, Larry Wall wrote: Dan Sugalski writes: : At 09:32 AM 5/8/2001 -0700, Larry Wall wrote: : Perl 6 might not put all the elements of @b on the stack as a temporary : list. Rather, it might just put \@b marked as expandable. (It might : also have to put some kind of copy-on-write lock on @b to keep it from : changing out from under, depending on how lazy the assignment (or : subroutine) actually gets about reading out the array.) : : s/might not/won't/; : : One of the places I hope to gain some speed is in eliminating flattening : and reconstitution of aggregate variables as much as possible. I'm hoping : to exploit this really heavily to save both the memory for the flattened : lists and the time it takes to flatten and reconstitute. (If we're really : lucky we might even be able to rehome some of the underlying data : structures, making returning a 10M entry hash cost about one pointer : assignment) I suspect one way this saves us a lot of overhead is in knowing how much memory to allocate for a given subroutine's stack frame. The way it is done in Perl 5, we pay the variadic stack overhead even on subroutines that are known not to be variadic. This is suboptimal, since you have to be ready to extend the stack at any moment. (It also tends to pessimize linkage into pseudo-variadic languages like C.) Yup, I definitely want to get things in a position to optimize fixed-input subs, if possible. Might eevn be able to do something like: PMC *foo(); fetch_perl_sub_pointer(foo, bar); my_pmc = foo(12); give or take bad C syntax on my part. I was contemplating the case where subs return huge arrays and lists, though, rather than the case where they're passed them. (I have a nasty habit of writing code that passes around monster arrays and hashes, so I tend to feel it more) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apoc2 - STDIN concerns
Simon Cozens wrote:
I'm sure a pure virtual base template class sounds reasonable
to a C++ programmer, but that doesn't mean it's the clearest thing
in the world. :)
Nothing changes at the syntactic level.
FOO: while ( $cond ) {
# FOO is now (an alias to) a loop control object...
next FOO;
What's unclear?
In fact, no one needs to know this is going on, except
the guy who wants to know why Cnext FOO looks like
a method call. (And he only thinks that because next
looks like a method name.)
--
John Porter
All men are subjects.
Re: Apoc2 - STDIN concerns
On Tue, May 08, 2001 at 02:34:25PM -0400, John Porter wrote: the guy who wants to know why Cnext FOO looks like a method call It doesn't, any more than next FOO looks like a method call in Perl 5 right now. -- I'm a person, not a piece of property. Happily, I'm both! - Lionel and Stephen Harris.
Re: Apoc2 - STDIN concerns
Simon Cozens wrote: John Porter wrote: Cnext FOO looks like a method call It doesn't, Oh, but it does, to the perl6 programmer who's used to thinking $source.next (or its indirect object alternative, next $source ) iterates the iterator in $source. Not that there are any such people. Yet. -- John Porter
Re: Apoc2 - STDIN concerns
From: Larry Wall [EMAIL PROTECTED] To: Eric Roode [EMAIL PROTECTED] Sent: Tuesday, May 08, 2001 11:03 AM Subject: Re: Apoc2 - STDIN concerns Eric Roode writes: : And, while I'm on my soapbox here, I don't get how ... is a vast : improvement over qw :-) Please pardon my hyperbole. I don't loathe qw() so badly that I want to get rid of it. I merely want to put it in the same status as the other general quote operators that also have a non-general pair of standard quote characters. I would feel the same about qq// if there weren't a . Might I suggest, then, that instead of making foo bar a synonym for qwfoo bar, we use it for iterators, and use foo bar (by which I mean the character twice, not the « character -- though probably either should work). That lets us keep foo for somthing iteratorish, which saves special-caseing (I do occasionaly use a qw list with one element), and lets us keep continuity. Anyway, I'm fairly certian that I'll use iterators more then qw lists. -=- James Mastros
Re: Apoc2 - STDIN concerns
On Tue, May 08, 2001 at 02:47:19PM -0400, John Porter wrote: Not that there are any such people. Yet. Indeed. And I suspect that the first Perl 6 programmers are Perl 5 programmers, who know damned well what next FOO means. -- Dogs believe they are human. Cats believe they are God.
Re: Apoc2 - STDIN concerns
On Tue, May 08, 2001 at 02:34:25PM -0400, John Porter wrote: Nothing changes at the syntactic level. Then I call Occam's Razor. Perl is supposed to be easy, no? -- And it should be the law: If you use the word `paradigm' without knowing what the dictionary says it means, you go to jail. No exceptions. -- David Jones
Re: Apoc2 - STDIN concerns
Simon Cozens writes: : On Tue, May 08, 2001 at 02:47:19PM -0400, John Porter wrote: : Not that there are any such people. Yet. : : Indeed. And I suspect that the first Perl 6 programmers are Perl 5 : programmers, who know damned well what next FOO means. Well, it's certainly the case that next by itself has to infer a much different object than, say, length by itself. I don't think anybody is going to argue with you that next has to be treated specially. My original point was merely that the parser could be parsing it that way, not that it didn't have extraordinary semantics once parsed. The exception would be at the semantic binding level, not at the parsing level. That's all. Larry
Re: Apoc2 - STDIN concerns
Simon Cozens wrote: Indeed. And I suspect that the first Perl 6 programmers are Perl 5 programmers, who know damned well what next FOO means. Would it really cause you that much consternation to find, after you've been programming in Perl6 for some months or years, that next FOO is actually a method call on a loop control object? -- John Porter
Re: Apoc2 - STDIN concerns
On Tue, May 08, 2001 at 01:59:47PM -0400, John Porter wrote: Perl is a highly dynamic language An object with exactly one and only one method doesn't sound that dynamic to me. -- Can you sum up plan 9 in layman's terms? It does everything Unix does only less reliably - kt
Re: Apoc2 - STDIN concerns
Simon Cozens wrote: Then I call Occam's Razor. Perl is supposed to be easy, no? It's also supposed to have an implementation. And to have a consistency level somewhat greater than zero. Also, consider the implications for user-defined control constructs. -- John Porter
Re: Apoc2 - STDIN concerns
Simon Cozens wrote: An object with exactly one and only one method doesn't sound that dynamic to me. Bit of a digression; but, the dynamicity of a language is in no way implicated by the number of methods in one build-in class. (Besides, this class will have at least three.) -- John Porter
Re: Apoc2 - STDIN concerns
On Tue, May 08, 2001 at 02:59:09PM -0400, John Porter wrote: It's also supposed to have an implementation. I think those of us who are actually likely to write a single line of code or more should be concerned with that, thank you. -- [It is] best to confuse only one issue at a time. -- KR
Re: Apoc2 - STDIN concerns
On Tue, May 08, 2001 at 03:00:51PM -0400, John Porter wrote: Bit of a digression; but, the dynamicity of a language is in no way implicated by the number of methods in one build-in class. (Besides, this class will have at least three.) Ooh, at least three. Again, why special-case a class that's inextensible? -- Nuclear war can ruin your whole compile. -- Karl Lehenbauer
Re: Apoc2 - STDIN concerns
[Tom's away at the moment, I'm filling in until he gets back.] -- Asynchronous inputs are at the root of our race problems. -- D. Winker and F. Prosser
Re: Apoc2 - STDIN concerns
Simon Cozens writes: : On Tue, May 08, 2001 at 03:00:51PM -0400, John Porter wrote: : Bit of a digression; but, the dynamicity of a language is in : no way implicated by the number of methods in one build-in : class. (Besides, this class will have at least three.) : : Ooh, at least three. Again, why special-case a class that's inextensible? It's not clear that it isn't. We're not so far off of a yield-like method on continuations here, except that yield statements typically assume the current sub as the continuation object. Perhaps Perl 6 will have ordinary blocks that can function as continuations to the surrounding list context. It's a long shot, but ya never know, ya know. Larry
Re: Apoc2 - STDIN concerns
Larry Wall wrote: We're not so far off of a yield-like method on continuations here... ... ordinary blocks that can function as continuations to the surrounding list context. Ah! Now we're talking! -- John Porter
Re: Apoc2 - STDIN concerns
* Larry Wall [EMAIL PROTECTED] [05/08/2001 09:36]: Taking history into account is good, though I'd argue that now is the proper time to change history, if we're going to change. Perl would never have been accepted in the first place had it been too different from what came before, but now that Perl has its own momentum, we can now look at how our own history gets in our way, and maybe do something about it. Very true. To this end I just would add that I think many JAPHs are used to and like as readline. I know I do. I'm not going to harp on this point endlessly, but this is one aspect that I do like about Perl. And keep in mind that unlike - vs . , *everyone* knows about FILEHANDLE. It is as pervasive as $ and @. That being said, I'm open to the idea of simply replacing with and tweaking the semantics a little. For one thing, it's a char shorter. For another, there's a equivalent. So: $x = $STDIN;# read from STDIN.more So could mean more and could mean less. Or something like that. Whether or not was implemented in 6.0 is unknown, but having that analogous functionality may be interesting. @a = $STDIN[0..3]; # @a = ($STDIN.more)[0..3] @b = $STDIN[0..3]; # @a = ($STDIN.less)[0..3] more and less could be inverses, more reading from the current position forward and less from the current position backwards. This notion could be generalized to files/networks/stacks/datastructs/etc/etc. I think someone mentioned qh() for hash. That's a possibility, but I'd still love to have enough brackets to give all of these standard shortcuts. It is worth noting that qr// has no true shortcut. That is these: $x = /\w+/; $x = \w+; Are definitely not the same as this: $x = qr/\w+/; I also think that looking at qr// or qw// as being in the same class as qq// is not 100% accurate. Really, qw// is a special type of q// that also splits on whitespace. : We don't actually have a good : notation for forcing a scalar context yet, let alone a scalar context : wanting a certain number of arguments. : : Personally, I'd look at it differently. I don't think that getting a number : of arguments out of a scalar context makes sense. Rather, I think you need : to call a member function or do whatever to get a list, then lazily evaluate : that. : :@a = $STDIN;# @a gets a single element - $STDIN :@b = $STDIN; # @b gets the entire contents of $STDIN :# iterations via calls to more() You don't actually get the entire contents of $STDIN. You get a value of $STDIN marked as a placeholder in the list assigned to @b, and that placeholder says the RHS requested expansion of this in a manner appropriate to the context supplied by the LHS. Assuming Perl 5 semantics of = continue, a similar thing will happen when you say: @a = @b; or push(@c, @b); Perl 6 might not put all the elements of @b on the stack as a temporary list. Rather, it might just put \@b marked as expandable. (It might also have to put some kind of copy-on-write lock on @b to keep it from changing out from under, depending on how lazy the assignment (or subroutine) actually gets about reading out the array.) Nice. In this view, * and could just be two different kinds of expandable flags. But I'm uncomfortable with that, because I'd like to be able to say lazy_sub($STDIN, $STDIN, $STDIN, $STDIN) to feed four lines to lazy_sub without defeating the prototype, er, signature checking. Maybe you have to us *$STDIN to do both. But that would probably say to slurp the whole rest of the file. That would be my guess. Assuming instead of , how about lazy_sub($STDIN[0..3]); # same as ($STDIN.more)[0..3] lazy_sub(*$STDIN); # same as ($STDIN.more)[0..-1] I would define * and as: * - greedy glob/list flattener - more iterator - less iterator All of those are unary, of course. : Basically, is left as direct access to the iterator, but it's not : magically called except where it clearly make sense (and I don't think : normal variable manip like passing into subs and hashes should be in this : category). : : $$STDIN # Return one element regardless of context. : $STDIN # Return number of element wanted by context. : @$STDIN # Return all element regardless of context. : : or some other casting mechanism yet to be devised. : : I'd do a variation on the above. Looking from a functional perspective: : : $STDIN.more # context-dependent : ($STDIN.more)[0..3] # just selected elements (lazily) : ($STDIN.more)[0..-1] # forced all : : Then we'd have the following shorcuts as a side-effect: : : $STDIN # context-dependent :($STDIN)[0..3] # just selected elements (lazily) :($STDIN)[0..-1] # forced all : : Seems to be easy and clean, without lots of new syntax. I'd lose the
Re: Apoc2 - STDIN concerns
At 01:19 PM 5/8/2001 -0700, Nathan Wiger wrote: * Larry Wall [EMAIL PROTECTED] [05/08/2001 09:36]: Taking history into account is good, though I'd argue that now is the proper time to change history, if we're going to change. Perl would never have been accepted in the first place had it been too different from what came before, but now that Perl has its own momentum, we can now look at how our own history gets in our way, and maybe do something about it. Very true. To this end I just would add that I think many JAPHs are used to and like as readline. I know I do. I'm not going to harp on this point endlessly, but this is one aspect that I do like about Perl. And keep in mind that unlike - vs . , *everyone* knows about FILEHANDLE. It is as pervasive as $ and @. That being said, I'm open to the idea of simply replacing with and tweaking the semantics a little. For one thing, it's a char shorter. For another, there's a equivalent. The one thing I worry about with a single-character readrecord character is determining when someone's reading from the default filehandle. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apoc2 - STDIN concerns
Nathan Wiger wrote: So could mean more and could mean less. That would sure confuse the math subcommunity! ;-) more and less could be inverses, more reading from the current position forward and less from the current position backwards. This notion could be generalized to files/networks/stacks/datastructs/etc/etc. Ugck. means read, means write. Do you want to be that different from shell? Or from Perl, for that matter? -- John Porter All men are subjects.
Re: Apoc2 - STDIN concerns
On Tue, May 08, 2001 at 12:58:24PM -0700, Larry Wall wrote: Perhaps Perl 6 will have ordinary blocks that can function as continuations to the surrounding list context. OK, now you've broken my brain. Can you give me an example that is i) useful and ii) reasonably obvious to the untrained eye? If not, I humbly suggest it has little business being in the blue-collar language we call Perl. -- Feed me on TOASTIES! There's no HALL for PHILOSOPHERS on FRIDAYS. - Henry Braun is Oxford Zippy
Re: Apoc2 - STDIN concerns
At 09:42 PM 5/8/2001 +0100, Simon Cozens wrote:
On Tue, May 08, 2001 at 12:58:24PM -0700, Larry Wall wrote:
Perhaps Perl 6 will have ordinary blocks that can function as continuations
to the surrounding list context.
OK, now you've broken my brain. Can you give me an example that is i) useful
and ii) reasonably obvious to the untrained eye? If not, I humbly suggest it
has little business being in the blue-collar language we call Perl.
@foo = ({scalar each %some_tied_hash});
with the function being called only when you access a particular element?
(Presumably calling it for elements 0-9 and caching them if the first
element you access is 10)
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Apoc2 - STDIN concerns
Simon Cozens wrote: Can you give me an example that is i) useful and ii) reasonably obvious to the untrained eye? If not, I humbly suggest it has little business being in the blue-collar language we call Perl. Rather than head off down this time-wasting tangent yet again, I refer readers to the archived discussions of RFC28. Suffice it to say that, contrary to some opinions, OO and FP are useful to more than just CS graduates. Part of Perl being Perl is being something greater than a lowest common denominator. -- John Porter
Re: Apoc2 - STDIN concerns
Simon Cozens wrote: On Tue, May 08, 2001 at 01:59:47PM -0400, John Porter wrote: Perl is a highly dynamic language An object with exactly one and only one method doesn't sound that dynamic to me. nonsense! It's got accessor methods too, for everyone who wanted to magicalize $index and so forth. Remeber those threads from last year?
Re: Apoc2 - STDIN concerns ::::: new mascot?
Larry Wall wrote: there seems to be a shortage of three-humped camels. At last! the unencumbered image for the mascot! Could O'Reilly really claim a three-humped camel was an image of a camel, with a straight face?
Re: Apoc2 - STDIN concerns
Larry Wall wrote:
Syntactically speaking it's too ambiguous to have both a unary and a
bracketing .
Cool. Do we get a operator to use as an l-value, instead of print?
$log = join localtime, 'difficult cramigudgeo';
It's possible we're thinking of iterators wrong here. Perhaps
iterators should typically be stored in @iter, not $iter. Then it's
pretty obvious that
for (@cases) { }
iterates, because it's in a list context.
but it is not obvious that @cases is an iterator. Unfortunately we don't
have an infinite supply of line-noise to arbitrarily extend this optimized
hungarian notation ($@%)
for Cfor ($cases){...} to do anything interesting, there's something
special about $cases, making iterator-in-scalar more visible than
iterator-in-array,
where it could easily be mistaken for a container instead of a generator.
I think iterator magic
always works in list context, and never in scalar.
okay, that disambiguates copy and retrieve handily, guess I'll delete the
five unsent e-mails eulogizing angles now
Re: Apoc2 - STDIN concerns
Nathan Wiger wrote: I think Uri's qh() suggestion is the cleanest: me too And it would make hash declarations cleaner: %hash = qh( foo bar jim = 'bob' var ); Plus maybe even a pragma to set the default value: use default hashval = 'closed'; ... Looks like a job for a new LineNoiseVar. is $% anything yet? format_page_number HANDLE EXPR $FORMAT_PAGE_NUMBER $% The current page number of the currently selected output channel. (Mnemonic: % is page number in nroff.) how about $% is that if we are using, umm, the format module, or the $QH_DEFAULT_VALUE if we aren't. Or go to $%%. Additionally, the qh syntax could very easily become a packed-structure sytnax.
Re: Apoc2 - STDIN concerns
I know it is an annoying and bad habit but I'm still young enough so
at first glance I think I know it all.
[billions and billions of]
SYN_A # Return one element regardless of context.
SYN_B # Return number of element wanted by context.
SYN_C # Return all element regardless of context.
Left out are the Defined? (SYN_D) and Copy (SYN_E)
operations.
For files in p5 we have A and C in scalar or array context of bracketed
file handles. Introduction of counted busy context gives us B in
bracketed file handles:
($first, second_holder(), third_holder()) = $generator
($first, second_holder(), third_holder(), @AllTheRest) = $generator
Which lets us keep unbracketed for D and E.
The basic underlying question is, what is the context that should fire
off an iterator? Everyone thinks @foo[1..10] should just do the right
thing, whatever that is.
okay I'll bite. It's the second through eleventh values of @foo, a
10-element sized busy.
Assuming the following makes an iterator,
and doesn't set $iter to 1 the first time through:
$iter = 1..10;
something we might be able to currently do with a source rewrite
to a tied scalar
How many of these work?
while ($x = @foo[$iter]) { ... }
$x becomes a true and defined reference to a continuable expression ,
and a compile-time warning is issued about suspicious use of an
iterator, suggesting angle brackets.
while ($x = @foo[$iter]) { ... }
still doesn't DWITYM, or does it? It does, due to the relaxation of
the @arrayname[index] syntax being an accessor rather than a slice,
so it is equivalent of
while (($x) = @foo[$iter]) { ... }
would be a lazy while-equivalent of
foreach $x (@foo[1..10]){ ... }
while ($x = $iter) { ... }
unless the code has Creset $iter in it somewhere this will advance
the iterator, breezing right past false and only stopping on undef
(semantic shift triggered by appearance of angles)
(although there are no falses in 1..10)
while ($x = $iter) { ... }
endless loop unless $iter gets set to false or undef
for ($iter) { ... }
Cfor having some magic in it to iterate iterators seems reasonable
I think that iterators must be dereferenced by something explicit, and
we will have to be very clear as to what is explicit enough. Subscripts
may be explicit enough:
@foo[$iter] # okay?
@foo[$iter] # kludgey
Obviously, $iter.method doesn't want to iterate:
$iter.more # can't iterate, or you call $iter.more.more.more...
$iter.more# okay, iterates over some iterators.
Well, that's enough brainwracking for the moment. Gloria is making me
go eat something...
Larry
fascinating
Re: Apoc2 - STDIN concerns
On Tue, May 08, 2001 at 05:11:52PM -0400, John Porter wrote: Can you give me an example ... Rather than head off down this time-wasting tangent yet again, That smacks of avoiding the question. Again, do you have a useful example? -- You will never find a more wretched hive of scum and villainy.
Re: Apoc2 - STDIN concerns
On Tue, May 08, 2001 at 05:08:58PM -0400, Dan Sugalski wrote:
@foo = ({scalar each %some_tied_hash});
with the function being called only when you access a particular element?
I'm still confused. Firstly, this doesn't involve first-order blocks, which
was kinda what the entire question was about. Secondly, it isn't clear what it
means. scalar each in Perl5-think means return the first element. (Try:
perl -le '%a=(a=b, c=d); print while $_ = scalar each %a') Is this not
merely @foo=(keys %some_tied_hash), which should call the tied functions in
the same way? Not a convincing example, I'm afraid.
--
The problem with big-fish-little-pond situations is that you
have to put up with all these fscking minnows everywhere.
-- Rich Lafferty
Re: Apoc2 - STDIN concerns
Nathan Wiger wrote:
Perhaps qi() for interpolate or something else.
coming to Perl from Scheme I recall some distress that
I had to create
($j=$i) =~ s/(\$\S+)/$1/ge;
instead of what I wanted to do
$j=qqq/$i/;
so my nomination is for tokens matching /qq*/ to behave like
subsequent applications of evaluation within quotes, even though
it opens the door to a world of taint.
...
Basically, is left as direct access to the iterator, but it's not
magically called except where it clearly make sense (and I don't think
normal variable manip like passing into subs and hashes should be in this
category).
me too
Hmmm, I'm not sure about the iterator object you're implicitly proposing
above. Is it going to be standard fare to assume certain types of objects
are created from certain constructs? What would this do?
I took the iterator object assumption to imply that dotdot in scalar
context was being defined to return tied scalars that return consecutive
numbers, so we can forget about storing all these eminently optimizable
sequential temporary arrays.
$iter = (1..10);
The same thing as above? What about:
What would these do?
I'd parse them, in my hubris, like so:
$iter = (1,2,3,4);
p5: $iter = \(1,2,3,4);
instead of this parsing into comma operator which is what p5 appears
to do with it.
$iter = (5,7..10);
since the dotdot is within another array constructor here, we get
another reference to an array instead of a magic iterator. It can
become a rfc123-compliant magic iterator like so
$iter = ?(5,7..10);
For the rest, assignment is stronger than comma, unless that gets changed.
$iter = 1, 2, 3;
$iter = a, b, c;
$iter = 1, 4 .. 10;
Assuming, however, that we had an iterator object concept, I would say:
while ($x = @foo[$iter]) { ... }
Works.
so undef always passes through an array-lookup?
defined(@arrayA[undef]) # always false?
Phew! My brain hurst. ;-)
-Nate
i agree w/ e-thing
Re: Apoc2 - STDIN concerns
David L. Nicol wrote: That also wraps up the for should have an explicit iterator access method thread handily! Just label your loop and there you are! Well, right. Every loop would have a control object, whether it's nonymous or a-. -- John Porter
Re: Apoc2 - STDIN concerns
At 10:23 PM 5/8/2001 +0100, Simon Cozens wrote:
On Tue, May 08, 2001 at 05:08:58PM -0400, Dan Sugalski wrote:
@foo = ({scalar each %some_tied_hash});
with the function being called only when you access a particular element?
I'm still confused. Firstly, this doesn't involve first-order blocks, which
was kinda what the entire question was about.
Well, it's a block in list context, which is what I was shooting for.
Secondly, it isn't clear what it
means. scalar each in Perl5-think means return the first element. (Try:
perl -le '%a=(a=b, c=d); print while $_ = scalar each %a')
Odd.
%foo = (a = 1, b=2);
while ($_ = scalar each %foo) {
print $_, \n;
}
does the expected thing. (printing a and b) Which is what I was shooting for.
Is this not
merely @foo=(keys %some_tied_hash), which should call the tied functions in
the same way? Not a convincing example, I'm afraid.
Well, we currently don't call the tied function that way. But yes. (And the
example was supposed to be illustrative, not convinving)
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Apoc2 - STDIN concerns
David L. Nicol writes:
: Larry Wall wrote:
:
: Syntactically speaking it's too ambiguous to have both a unary and a
: bracketing .
:
: Cool. Do we get a operator to use as an l-value, instead of print?
:
: $log = join localtime, 'difficult cramigudgeo';
I don't think so.
: It's possible we're thinking of iterators wrong here. Perhaps
: iterators should typically be stored in @iter, not $iter. Then it's
: pretty obvious that
:
: for (@cases) { }
:
: iterates, because it's in a list context.
:
: but it is not obvious that @cases is an iterator.
Except insofar as all arrays are iterators of some sort or other, and
can produce a list in a list context. All lists are created equal,
but some are more equal than others.
: Unfortunately we don't
: have an infinite supply of line-noise to arbitrarily extend this optimized
: hungarian notation ($@%)
Don't see the need yet. English gets by with $singular and @plural,
and a bit of leftover %dual from Indo-European days. It's pretty
obvious in English from context when you say miles to go before I
sleep that the miles come one at a time. It's a kind of iterator. On
the other hand, with a can of worms, you usually consider that you
get all the worms at once.
: for Cfor ($cases){...} to do anything interesting, there's something
: special about $cases, making iterator-in-scalar more visible than
: iterator-in-array,
: where it could easily be mistaken for a container instead of a generator.
:
:
: I think iterator magic
: always works in list context, and never in scalar.
:
: okay, that disambiguates copy and retrieve handily, guess I'll delete the
: five unsent e-mails eulogizing angles now
Well, I was speaking of iterators in @worms, not $worms. I still don't
think $worms should do anything special in list context. Maybe $STDIN
should really be spelled @STDIN. Perhaps iterators really want to
implement a form of highlander variable:
my @worms is alias($worms) tie(Iterator);
or
my $@worms; # highlander declaration
Just shooting my mouth off here, if not my foot...
A argument could also be made that iterators are neither scalars nor
arrays--they're functions.
Doubtless Damian could come up with a way to view them as hashes...
Well, hey, at least we'll all go mad together.
Larry
Re: Apoc2 - STDIN concerns
Doubtless Damian could come up with a way to view them as hashes...
Well, of course.
An iterator is neither pure state nor pure behaviour. It's an
inextricable commingling of the two. In other words: an object.
So they are *most naturally* viewed as hashes:
package Iterator;
sub new { my $class = shift; bless {@_}, $class }
sub next { croak 'Abstract next method called on ' . ref $_[0] }
sub reset { my $self = shift; $self-{next} = undef; }
package Iterator::Range;
use base 'Iterator';
sub next {
my $self = shift;
$self-{next} = $self-{from} unless defined $self-{next};
return $self-{next}++ if $self-{next} = $self-{to};
$self-{next} = undef;
return;
}
package Iterator::Step;
use base 'Iterator::Range';
sub next {
my $self = shift;
$self-{next} = $self-{from} unless defined $self-{next};
return ($self-{next}+=$self-{step})-$self-{step}
if $self-{next} = $self-{to};
$self-{next} = undef;
return;
}
package Iterator::Array;
use base 'Iterator';
sub next {
my $self = shift;
return ($self-{array}[$self-{next}++]
if ($self-{next}||=0) @{$self-{array}};
$self-{next} = undef;
return;
}
# etc.
# etc.
# etc.
See? Nothing but hashes.
;-)
Damian
Re: Apoc2 - STDIN concerns
Simon Cozens [EMAIL PROTECTED] writes: On Tue, May 08, 2001 at 01:59:47PM -0400, John Porter wrote: Perl is a highly dynamic language An object with exactly one and only one method doesn't sound that dynamic to me. Three methods, surely: next, last, redo. -- Piers Cawley www.iterative-software.com
RE: Apoc2 - STDIN concerns
$$STDIN # Return one element regardless of context. @$STDIN # Return number of element wanted by context. *$STDIN # Return all element regardless of context. How about $STDIN.$ # Return one element regardless of context. $STDIN.@ # Return number of element wanted by context. $STDIN.* # Return all element regardless of context.
Re: Apoc2 - STDIN concerns
* Simon Cozens [EMAIL PROTECTED] [05/05/2001 17:51]:
%foo = ( foo = 1, bar = 1, '=' = 'baz' )
Of course, that could be spelt
%foo = +foo +bar =(baz);
Actually, it couldn't be because the in = would end the parsing.
Same problem that the POD chars have.
I think Uri's qh() suggestion is the cleanest:
use CGI qh(:standard !h2 !h3 version = 1.4);
And it would make hash declarations cleaner:
%hash = qh(
foo
bar
jim = 'bob'
var
);
Plus maybe even a pragma to set the default value:
{
use default hashval = 'closed';
%dotcoms = qh(
pets
amazon = 'open'
onlinechoice
etour
nettaxi = 'life support'
);
}
In fact use default could set stuff like what should mean truth too:
use default false = qw(0 ),
true = qw(!undef);
Or something like that. That last one might help take care of the |||
flamewars.
-Nate
Re: Apoc2 - STDIN concerns
I think Uri's qh() suggestion is the cleanest: Interesting train of thought, since one of the ideas was that qw() is ugly and has to go. (Larry's been saying this for nearly two years now, it's just that people sometimes don't listen. :) Let's keep it and add something similarly ugly to keep it company! i use Perl everyday, so from my practical standpoint, i find that qw() helps my code to look a lot cleaner and simpler to read monty
Re: Apoc2 - STDIN concerns
On Mon, May 07, 2001 at 01:27:52PM -0700, Nathan Wiger wrote: I'm not against a cleaner way to do qw() in principle, but I definitely think is not it for a lot of reasons (glob, readline, can't use =, iterators, ...) Sheesh. Yes, those would be problems with using in Perl 5. However, we are not designing Perl 5. -- `First Up Against The Wall When The Revolution Comes! Woohoo! So long as they promise to use latex gloves, I'm happy. :)' - Thorfinn, in the Monastery.
Re: Apoc2 - STDIN concerns
Uri Guttman wrote: what larry seems to want is qh() for quote hash. %foo = qh( foo bar baz ) is like %foo = ( foo = 1, bar = 1, baz = 1 ) Thank you for giving me a chance to drag out my favorite soapbox again. :-) What is needed is better support for treating hashes as sets. We want to be able to say keys(%foo) = (... list of keys ...); It is not sufficient to invent fancy syntaxes for the RHS of this equation, because the RHS should be able to be any list source. Ref. my RFC that didn't make it in in time: http://www.min.net/~jdporter/setashash.html -- John Porter All men are subjects.
Re: Apoc2 - STDIN concerns
Larry Wall wrote:
We do have to worry about the Cnext loop control function though.
It's possible that in
FOO: while (1) {
next FOO if /foo/;
...
}
the CFOO label is actually being recognized as a pseudo-package
name! The loop could well be an object whose full name is CMY::FOO.
Or something like that. But maybe that's a gross hack. Seems a bit
odd to overload Cnext like that. Maybe we need a different word.
Pardon me if someone has already suggested this, but...
Couldn't labels really be (aliases to) iterator objects?
So that
next FOO
really *does* mean
FOO.next
--
John Porter
All men are subjects.
Re: Apoc2 - STDIN concerns
* Simon Cozens [EMAIL PROTECTED] [05/07/2001 13:33]: I'm not against a cleaner way to do qw() in principle, but I definitely think is not it for a lot of reasons (glob, readline, can't use =, iterators, ...) Sheesh. Yes, those would be problems with using in Perl 5. However, we are not designing Perl 5. I know. My point is there's a lot of lessons that have been learned from the years of Perl development. They're coordinated into qw() in Perl 5. It works very well, as do the other q-ops. Incredibly well, actually. And = in is still a problem for any parser, even Perl 6's. To quote you: : http://dev.perl.org/rfc/28.pod : : Perl 6 is our opportunity to give Perl a good spring clean. When : you're spring cleaning a house, you throw out the trash and dust : down the ornaments, but you don't burn it down and build a shopping : mall instead. : : I think it's reasonably fair to assume that we're all Bprimarily : working on Perl 6 because we like Perl and we want to make it better, : not because language design is a fun thing to do of an evening. If : that's the case, nobody wins if we bend the Perl language out of all : recognition, because it won't be Perl any more. So let's not do this. : Let's keep Perl recognisably the language we know and love; let's : enhance it, by all means, but let's not turn it into something it : isn't. I'm not trying to be a jerk at all, but I think at times we're losing sight of the above. -Nate
Re: Apoc2 - STDIN concerns
On Mon, May 07, 2001 at 01:43:56PM -0700, Nathan Wiger wrote: To quote you: : http://dev.perl.org/rfc/28.pod I'm not trying to be a jerk at all, but I think at times we're losing sight of the above. I hope not, since it was primarily written with you in mind. :) -- He was a modest, good-humored boy. It was Oxford that made him insufferable.
Re: Apoc2 - STDIN concerns
* Simon Cozens [EMAIL PROTECTED] [05/07/2001 13:46]: To quote you: : http://dev.perl.org/rfc/28.pod I'm not trying to be a jerk at all, but I think at times we're losing sight of the above. I hope not, since it was primarily written with you in mind. :) Hmm, that's odd. As I recall I was one of the most fervent proponents of RFC 28: http://www.mail-archive.com/perl6-language@perl.org/msg00778.html Or did you mean something else? If you read my RFC's with a this guy loves Perl mindset I think you'll find most all of them are not actually that radical. The only ones that are really out there are ones like RFC 159, but even that's designed to be hidden under the hood. But I think we're getting a little off-topic... -Nate
Re: Apoc2 - STDIN concerns
Simon Cozens writes: However, we are not designing Perl 5. This gets to a theme that is turning into more and more of an irritant in following (and very occasionally participating) in the ongoing discussion here. There seems to be a sense among some participants that certain issues are Off Limits. I got quite a bit of static from my comments about the desirability of retaining the . concatenation operator. In any process like this, certainly some issues have reached a preliminary resolution before they are opened for public discussion, others are relatively undecided, and still others have two or more competing approaches that need to be resolved. It strikes me as counterproductive to say, Oh, that's ALREADY been decided (with the distinct undertone of by the way please note how out of touch you are), or That's fine but we're not designing Perl 5 here (with the apparent inference that concerns about syntax and efficiency have been trumped by the onrushing demands of the various new schemata being proposed). Especially in cases where Larry hasn't even addressed the specifics yet. This is not conducive to open discussion and gaining the widest review and consideration for all the complex/interactive aspects of a language development process. No doubt Larry will reject many of our notions out of hand, for a variety of reasons, but at the same time I note that he typically provides a precis and justification for those as they come along. Remember, A2 has been out for less than a week. Those who see their role as shepherding this process along by avoiding things already decided risk losing the input and involvement of those with practical concerns. I trust Larry and the others who are going to end up coding all this stuff to take all input and assess it accordingly. Now perhaps there would be some use for a process like the evidentiary and procedural rules of court. In a trial, certain things are stipulated as facts and not further discussed. Other things are put off the record as irrelevant or biased and are not included in the final decision. And so on. But I don't think we need to be that hypertechnical about this. While a word to the wise about nearly-finalized decisions ought to be sufficient, remember that none of us are mind readers, and if we wish to have the widest range of appropriate input, it is well to recognize that not everyone here is a core Perl developer. out, phred
Re: Apoc2 - STDIN concerns
On Mon, May 07, 2001 at 05:14:23PM +, Fred Heutte wrote: It strikes me as counterproductive to say, Oh, that's ALREADY been decided (with the distinct undertone of by the way please note how out of touch you are), or That's fine but we're not designing Perl 5 here (with the apparent inference that concerns about syntax and efficiency have been trumped by the onrushing demands of the various new schemata being proposed) Hrm, no. You completely misunderstood why I said that. I said that because if we *are* going to change the syntax, saying that it will clash with the old syntax is an invalid argument, because it won't clash because we'll change it! -- dd.c: sbrk(64); /* For good measure */ - plan9 has a bad day
Re: Apoc2 - STDIN concerns
Simon Cozens makes a good point in response to my slightly overamped oration on the qualities of dissent. I am seeing most of the current discussion on this list as being brainstorming on details, not painting the vast new blue skies, and that is as it should be. Acknowledging that making changes involves tradeoffs is an important part of that. We are ultimately dealing with the fact that the working subset of commonly shared non-alphanumeric keys on keyboards is somewhat limited (where IS that darn Compose key anyway!). This isn't so bad; the constrained set avoids APLism, and as many may know, that way lies madness! http://www.chilton.com/~jimw/keyboard.html And so there's a bit of a three-dimensional Rubik's Cube game here to try and rejigger the use of the keyboard to make the language more efficient and productive and maybe even clean out some of the accumulated crud out there. Onward. I resume my stance as interested layman... Fred
Re: Apoc2 - STDIN concerns
On Mon, May 07, 2001 at 05:47:59PM +, Fred Heutte wrote: And so there's a bit of a three-dimensional Rubik's Cube game here to try and rejigger the use of the keyboard to make the language more efficient and productive and maybe even clean out some of the accumulated crud out there. http://babe.pobox.com/~mengwong/pcd/yapc1999/orwant-1.html -- BITTERNESS: Never be Afraid to Share Your Dreams with the World, Because there's Nothing the World Loves More Than The Taste of Really Sweet Dreams http://www.despair.com
Re: Apoc2 - STDIN concerns
At 01:51 AM 5/6/01 +0100, Simon Cozens wrote: The debate rages on: Is Perl Bactrian or Dromedary? It's a Dromedary, it says so in the Colophon. But maybe the symbol of Perl 6 should be a Bactrian, with the extra hump symbolizing the increased power. You knew this was coming... -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: Apoc2 - STDIN concerns
On Sun, May 06, 2001 at 10:10:24PM +0200, Bart Lateur wrote: On Sat, 5 May 2001 15:22:40 -0700, Nathan Wiger wrote: I suggest that we simply create another q-op to do the qw-ish things you're proposing. Perhaps qi() for interpolate or something else. qqw Why I'm reminded of car, cdr, cadr, cdar, cddar, cadar, ... -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Apoc2 - STDIN concerns
On Fri, May 04, 2001 at 07:56:39PM -0700, Larry Wall wrote: Nathan Wiger writes: : : This one. I see a filehandle in *boolean* context meaning read to $_, : : just like the current while (FOO) magic we all know and occasionally : : love. I'd expect $FOO.readln (or something less Pascalish) to do an : : explicit readline to a variable other than $_ : : It would be $FOO.next, but yes, that's the basic idea. It's possible : that iterator variables should be more syntactically distinquished than : that. One could, I suppose, make up something about $FOO or $FOO : meaning the same thing thing as $FOO.next, for people who are homesick : for the angles, but I haven't thought that out, and don't even dare to : mention it here for fear someone will take it as a promise. Er, oops... : : So, just to clarify, the thought is: : :print while ($FOO);# like Perl 5 FOO :$var = $FOO.next; # like Perl 5 $var = FOO; : : I assume that this is indicative of a more general iterator syntax, and : subject to indirect objects? : :$FH = open $file or die Can't open $file: $!; :$line = next $FH; : : If so, I can live with that. Yes, that's the reason it's Cnext, and not something more specific like Creadline, which isn't even true in Perl 5 when $/ is mungled. We do have to worry about the Cnext loop control function though. I don't know. If it had to be written as $FH.next then there should be no ambiguity. Graham.
Re: Apoc2 - STDIN concerns
On Sat, May 05, 2001 at 02:46:46AM +0100, Michael G Schwern wrote:
On Fri, May 04, 2001 at 04:42:07PM -0700, Nathan Wiger wrote:
I'm wondering what this will do?
$thingy = $STDIN;
This seems to have two possibilities:
1. Make a copy of $STDIN
2. Read a line from $STDIN
While perhaps inconsistent, I'd really rather it did #2. Here's the
basic argument... compare how often you dup a filehandle with how
often you read from one. Duping is swamped by several orders of
magnitude. Dup with $fh = $STDIN.copy; (or whatever). $line =
$STDIN.next should still work normally.
How would you pass a handle to a subroutine, or store it inside
a hash or array ?
sub my_read {
my $fh = shift; # whoops
}
I don't think it should do a dup(), but we do need to pass file handles around
Graham.
Re: Apoc2 - STDIN concerns
:$FH = open $file or die Can't open $file: $!; :$line = next $FH; : : If so, I can live with that. Yes, that's the reason it's Cnext, and not something more specific like Creadline, which isn't even true in Perl 5 when $/ is mungled. I dunno. Color me unconvinced--I do use the enough in non-while context (and in non-implied while context) to make the whole idea of next feel rather... nasty. And $FOO.next? Yuck. You know, I was just thinking about this, and I agree with Dan. Actually, there's some big problems in trying to get rid of and make Perl do the right thing in boolean context (like the while loop example). Consider: $FH = open /etc/motd; die No good unless ($FH);# ??? What does that do? Per the proposal, $FH in a boolean context is supposed to call its next() method to get the next line. So, does that fail because the handle wasn't opened (and hence $FH was never defined) or because /etc/motd is zero-length? And having to write $line = next $FH is already getting cumbersome, to be honest. I say we should combine the two concepts. Why not make a shortcut to the proposed new general-purpose-iterator concept? So: $line = $FOO.next;# yuck, I agree with Dan $line = next $FOO;# better... $line = $FOO; # aaah :-) print while ($FOO); # infinite, assuming $FOO defined print while ($FOO.next); # while reading the file print while ($FOO); # still my favorite Otherwise, it seems like there's a lot of Black Magic with calling next() automatically, and for something as fundamental as I/O that makes me really nervous. -Nate
Re: Apoc2 - STDIN concerns
Nathan Wiger writes:
: You know, I was just thinking about this, and I agree with Dan. Actually,
: there's some big problems in trying to get rid of and make Perl do the
: right thing in boolean context (like the while loop example). Consider:
:
:$FH = open /etc/motd;
:die No good unless ($FH);# ???
You're right, that's a severe problem.
: What does that do? Per the proposal, $FH in a boolean context is supposed to
: call its next() method to get the next line. So, does that fail because the
: handle wasn't opened (and hence $FH was never defined) or because /etc/motd
: is zero-length?
:
: And having to write $line = next $FH is already getting cumbersome, to be
: honest.
True 'nuff.
: I say we should combine the two concepts. Why not make a shortcut to the
: proposed new general-purpose-iterator concept? So:
:
:$line = $FOO.next;# yuck, I agree with Dan
:$line = next $FOO;# better...
:$line = $FOO; # aaah :-)
:
:print while ($FOO); # infinite, assuming $FOO defined
:print while ($FOO.next); # while reading the file
:print while ($FOO); # still my favorite
:
: Otherwise, it seems like there's a lot of Black Magic with calling next()
: automatically, and for something as fundamental as I/O that makes me really
: nervous.
I expect the real choice is between $FOO and $FOO. I can convince
myself pretty easily that a unary is just another name for next, or
more, or something. On the other hand $FOO has history. And if
one special-cases $..., we could also have foo bar baz as a qw()
replacement. All we'd be doing is taking that syntax away from
globbing, and giving it to qw, more or less. (Less, because I'd like
foo bar baz($xyz) to mean {foo = 1, bar = 1, baz = $xyz} or some
such, where the 1's are negotiable.)
But maybe I should hold out for «» meaning qw() eventually. If we
continue to require quotes on the string of END, we could even use
foo bar baz($xyz) as an ASCII workaround, I suppose. That's not
much more readable than qw(), I admit.
That leaves free to be either a prefix or circumfix operator of
arbitrary complexity.
If is a unary operator, then one could have an arbitrary expression
returning an iterator:
$line = somefunc();
For a circumfix, you could just treat as funny parens:
$line = somefunc();
On the other hand, I wouldn't want to go so far as to require
1..10
merely to make the iterator iterate. Saying
@foo[1..10]
ought to be enough clue. But does that mean that
%foo{$STDIN}
should read one value or all of them? Or some number depending on the number
of values expected in the context? And now we're back to the question
of slice context, really. Obviously, given a list flattener *, we'd
expect
%foo{*$STDIN}
to return all the values. Maybe then
%foo{$STDIN}
returns exactly one value, and
%foo{$STDIN}
guesses.
Looking at it from the iterator object end, there might really be three
methods:
$STDIN.next # Return one element regardless of context.
$STDIN.more # Return number of element wanted by context.
$STDIN.all # Return all element regardless of context.
Or maybe there's only a more method, and you simply have to force the
context if you don't want it to guess. We don't actually have a good
notation for forcing a scalar context yet, let alone a scalar context
wanting a certain number of arguments. Doing violence to our current
notions of what various prefix operators currently mean, we might want:
$$STDIN # Return one element regardless of context.
@$STDIN # Return number of element wanted by context.
*$STDIN # Return all element regardless of context.
or
$STDIN # Return one element regardless of context.
=$STDIN # Return number of element wanted by context.
*$STDIN # Return all element regardless of context.
or
$-STDIN # Return one element regardless of context.
$=STDIN # Return number of element wanted by context.
$*STDIN # Return all element regardless of context.
or
$:$STDIN# Return one element regardless of context.
@:$STDIN# Return number of element wanted by context.
*:$STDIN# Return all element regardless of context.
or
$($STDIN) # Return one element regardless of context.
@($STDIN) # Return number of element wanted by context.
*($STDIN) # Return all element regardless of context.
or
$:$STDIN# Return one element regardless of context.
$STDIN# Return number of element wanted by context.
@:$STDIN# Return all element regardless of context.
or
$$STDIN# Return one element regardless of context.
$STDIN# Return number of element wanted by context.
@$STDIN#
Re: Apoc2 - STDIN concerns
Ok, this is long, so here goes...
I expect the real choice is between $FOO and $FOO. I can convince
myself pretty easily that a unary is just another name for next, or
more, or something. On the other hand $FOO has history. And if
one special-cases $..., we could also have foo bar baz as a qw()
replacement. All we'd be doing is taking that syntax away from
globbing, and giving it to qw, more or less. (Less, because I'd like
foo bar baz($xyz) to mean {foo = 1, bar = 1, baz = $xyz} or some
such, where the 1's are negotiable.)
One thing I think we should avoid is as many special cases as possible.
This is already why people hate currently - because it does both glob()
and readline().
I would say that having history is actually a good thing. It's a
foundation, really, since readline() is an iterator of sorts. All we'd be
doing is generalizing the notion. Not only does it apply to files, but it's
a shortcut to more() wherever you feel like using it.
As for as a qw() replacement, I think there are really two issues here.
First, you're not really talking about a replacement, since you're
mentioning different semantics. So qw() will still be widely used. I suggest
that we simply create another q-op to do the qw-ish things you're proposing.
Perhaps qi() for interpolate or something else. Plus has the terrible
problem that the POD C stuff does w/ embedded chars. The really nice
thing about the q's is you can choose any bracket you want. I think fleshing
out this series of constructs makes the most sense.
For a circumfix, you could just treat as funny parens:
$line = somefunc();
On the other hand, I wouldn't want to go so far as to require
1..10
merely to make the iterator iterate. Saying
@foo[1..10]
ought to be enough clue.
Yes, I think that could just be shortcut to wherever you wanted more()
called. Just like .. with a different notation:
@foo = $BAR;
@foo = @bar[1..10];
@foo[0..4] = $BAR;
This is nice because it looks Perlish, but fundamentally it could be reduced
to a single iterator concept.
But does that mean that
%foo{$STDIN}
should read one value or all of them?
I would say that this should return only one thing - the $STDIN variable. No
automatic iteration should be done. Otherwise you run into problems with how
to pass filehandles around as variables. I think iteration needs to be
explicit.
If you want iteration:
%foo{$STDIN}; # poll the iterator
%foo{$STDIN.more};# same thing
The iterator is just a member function, and you have to call it if you want
it.
$FOO = open bar;
do_stuff($FOO);# filehandle passed, not contents
do_more_stuff($FOO); # now filehandle is iterated (lazily)
do_more_stuff($FOO.more); # same thing
%holding_stuff{$FOO.more}; # same thing, just into a var
close $FOO;
I think these semantics make sense.
Obviously, given a list flattener *, we'd expect
%foo{*$STDIN}
to return all the values. Maybe then
%foo{$STDIN}
returns exactly one value, and
%foo{$STDIN}
guesses.
I'd so this differently, as hinted at above:
%foo{$STDIN};# return all values
%foo{$STDIN); # return one value
%foo{$STDIN}; # pass the $STDIN variable
This is assuming that we want to exist and have a different semantics. But
I'm not sure that's a good idea. For one thing, you'd have to mention it
several times if you want a couple values. I think there's got to be a
better way to request the number of lines based on context.
%foo{$STDIN}; # the whole thing
%foo{ (1..2) = $STDIN }; # anonymous list request?
%foo{ $STDIN[1..2] }; # or notate it as a list?
%foo{ ($STDIN.more)[1..2] }; # same thing
The last one seems to make sense (it's got those (localtime)[2,3] roots),
with the third one as a shortcut.
Looking at it from the iterator object end, there might really be three
methods:
$STDIN.next # Return one element regardless of context.
$STDIN.more # Return number of element wanted by context.
$STDIN.all # Return all element regardless of context.
Or maybe there's only a more method, and you simply have to force the
context if you don't want it to guess.
I think one method is the way to go. Let the subs and other contexts request
the number of elements to get back using lazy evaluation:
@foo[1..10] = $STDIN; # get 10 iterations
$bar = $STDIN;# next one
lazy_sub($STDIN);# lazily
Assuming:
sub lazy_sub ($a, $b, $c, $d) { }
Then the last line above would lazily grab the next four lines.
We don't actually have a good
notation for forcing a scalar context yet, let alone a scalar context
wanting a certain number of arguments.
Personally, I'd look at it differently. I don't think that getting a number
of arguments out of a scalar context makes sense. Rather, I think you need
to call a member function or do whatever to get a list, then lazily evaluate
