Re: Damian Conway's Exegesis 2
Nathan Torkington [EMAIL PROTECTED] writes: Edward Peschko writes: Ok, question here. Are these exegesises 'blessed'? What is open to debate on this? As Simon says, ask whatever questions you want. print Post order: ; show($root,$post); print \n; would be better off written as: print Post order: show($root, $post)\n; wouldn't it? Yes, except that you're relying on show() not returning a value there. If show() was written so that it happened to have a print statement as the last thing in the sub, then you'd get random 1s in your output. Am I the only one here who's confused? How does the printing happen in the correct order? I mean, if I said my $x = Post order: show($root, $post)\n; print $x; then (I hope) we're agreed printing would happen in the *wrong* order (first the output of show($root, $post), then the value of $x (and $x eq Post order: \n). So how come `print' gets to mung about with evaluation order? [...] Hoping for illumination, -- Ariel Scolnicov|GCAAGAATTGAACTGTAG| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658117 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: Exegesis2 and the is keyword
At 15.02 -0700 01-05-15, Nathan Wiger wrote: The only worry/problem/etc that I wonder about is the potential overuse of the is keyword. It is a very nice syntactic tool, but when I see something like this: $*ARGS is chomped; I wonder if that wouldn't be better phrased as: autochomp $*ARGS;# $ARGS.autochomp I see your point, but I see a clear difference between these properties and actions taken on the variable. When we say $*ARGS is chomped, we don't ask $*ARGS to do anything right away, just remember that when we later ask it to return something, we want that something chomped. Cajo -- Carl Johan Berglund, [EMAIL PROTECTED], 0708-136 236 Adverb Information, http://www.adverb.se, 08-555 788 80
Re: Damian Conway's Exegesis 2
At 10.39 +0300 01-05-16, Ariel Scolnicov wrote:
How does the printing happen in the correct order? I mean, if I said
my $x = Post order: show($root, $post)\n;
print $x;
then (I hope) we're agreed printing would happen in the *wrong* order
(first the output of show($root, $post), then the value of $x (and $x
eq Post order: \n).
Yes, it would, as would the Perl 5 equivalent:
sub show {print 6}
print Perl ${show()}\n;
(That prints 6Perl, not Perl 6.)
If you want to call the subroutine in the middle of the string, you
should make it _return_ something, not print it.
Cajo
--
Carl Johan Berglund, [EMAIL PROTECTED], 0708-136 236
Adverb Information, http://www.adverb.se, 08-555 788 80
Re: Damian Conway's Exegesis 2
On Wed, 16 May 2001 13:49:42 +0200, Carl Johan Berglund wrote:
sub show {print 6}
print Perl ${show()}\n;
(That prints 6Perl, not Perl 6.)
If you want to call the subroutine in the middle of the string, you
should make it _return_ something, not print it.
This person obviously expects a pipe effect, i.e. capturing of the
printed output.
Should Perl6 provide one? Is print() really easier to grasp, than
'return $buffer', with possibly lots of '$buffer.=$append' in the sub?
Actually, yes, the latter is annoying.
--
Bart.
Re: Damian Conway's Exegesis 2
At 14.07 +0200 01-05-16, Bart Lateur wrote: This person obviously expects a pipe effect, i.e. capturing of the printed output. Should Perl6 provide one? Is print() really easier to grasp, than 'return $buffer', with possibly lots of '$buffer.=$append' in the sub? Actually, yes, the latter is annoying. I have no problem with a lot of $buffer .= whatever, but this would be very handy when you write a long subroutine with a lot of prints, and then later decide you'd like to do something else with that output. Depending on whatever Larry is doing with iterators and file handles, it could be done by temporarily assigning $STDOUT to your own output handle, which stores whatever you print to it in a string, and then returning that string. Cajo. -- Carl Johan Berglund, [EMAIL PROTECTED], 0708-136 236 Adverb Information, http://www.adverb.se, 08-555 788 80
Parsing perl 6.0
Jumping the gun a little With the pluggable parser architecture, would it be a Good/Bad/Ugly Thing to freeze the parser itself after each Perl release? One of the omnipresent arguments against any change is how it affects legacy. Although Perl 6[.0] is a recognizable departure from Perl 5.x syntax, so have been Perl 5.x from Perl 5.(x-1) and will be Perl 6.x from Perl 6.(x-1), if only to a lesser extent. Perl 6 is planning on addressing the bulk of the Perl 5 legacy issue with a pluggable parser capable of parsing Perl 5.n. Why not do the same thing in the future with minor revs? Currently, with each release, the parser is extended/fixed/modified in place with the development of the next version. Instead, why not freeze the parser in place at each release, and then use it as a jumping off point for the next parser? The frozen parser could then be CPANned as a legacy parser. Bennies: - Guaranteed language basis for the future. Code written explicitly for Perl 6.0 will be parsed according to Perl 6.0 rules.(1) Code written generically for perl can easily be rolled back if the next version of Perl breaks some reliance on the older parsing rules. - Fits within the mix and match module munging that is being planned. Perl 6.0 code could potentially interface with Perl 7.0 modules/packages/classes, and vice versa. - By definition, doesn't need to be maintained.(2) Once it's frozen, it's frozen. This is behavior that people expect, however intentional or not the behavior actually is. Er, was. Troublespots: - (1) Parsing would be consistant, but obviously runtime behavior could still change, depending, for instance, on whether the parse-tree optimizer would be coupled with the parser or with the underlying architecture. Future optimizers may subtly change the behavior of a legacy parse-tree. This is the same issue that will plague compiled code, so it needs to be addressed somehow anyway. - (2) Obviously, opcode deletion (or something similar) may require the parser's output to be changed. - Who wants umpteen different perl parsers lying around their code base? Other impacts: - Cuse semantics would have to be changed. Or whatever the parser identifier will be. You'll need to differentiate between an exact match and a minimum match. use perl 6.0; use = perl 6.0; # or use perl = 6.0? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Damian Conway's Exegesis 2
--- Dan Sugalski [EMAIL PROTECTED] wrote: Oh, didn't Larry tell you? We're making perl's parser locale-aware so it uses the local language to determine what the keywords are. I thought that was in the list of things you'd need to take into account when you wrote the parser... ;-P mios @ventanas son inmutables; Oh! Joy! Oh! Rapture! Oh! Eternal bliss! __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: Damian Conway's Exegesis 2
On Tue, 15 May 2001, Simon Cozens wrote: On Tue, May 15, 2001 at 03:30:07PM -0700, Dave Storrs wrote: - A while ago, someone suggested that the word 'has' be an alias for 'is', so that when you roll your own properties, you could write more-grammatically-correct statements such as my $var has Colors(3). Since 'are' is being considered as a synonym, is there a possibility that 'has' will make it too? It would be disappointing if a substantial proportion of the built-in keywords were merely syntactic sugar for each other. is|are|has|: seem like far too many ways to express exactly the same concept. I understand your point, but I respectfully disagree with it. Consider that there are about 10 ways to do a loop (map, grep, for, foreach, while, and at least 4 others that I'm not remembering at the moment; before you say it, I grant you there are minor differences between the constructions, so they are not exactly the same concept, but they are very close). Perl has always put an emphasis on reading like grammatical English--see all the Perl poetry, or look at the 'unless' keyword, or the fact that conditionals can be prefix or postfix. Finally, is ':' actually sugar for is? I guess I missed that; I'll go back and read it again. Dave
Re: Damian Conway's Exegesis 2
On Wed, May 16, 2001 at 07:40:19AM -0700, Austin Hastings wrote: mios @ventanas son inmutables; It's all part of the secret plan to make Perl *even more* unmaintainable. :) -- CLUELESSNESS: There are No Stupid Questions, But There Are a LOT of Inquisitive Idiots http://www.despair.com
Re: Damian Conway's Exegesis 2
At 07:40 AM 5/16/2001 -0700, Austin Hastings wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: Oh, didn't Larry tell you? We're making perl's parser locale-aware so it uses the local language to determine what the keywords are. I thought that was in the list of things you'd need to take into account when you wrote the parser... ;-P mios @ventanas son inmutables; Oh! Joy! Oh! Rapture! Oh! Eternal bliss! Oh. It was a joke... :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Exegesis2 and the is keyword
Ok, this is basically a bunch of me too!s.
On Tue, 15 May 2001, Nathan Wiger wrote:
Awesome. Simple, Perlish, easy to read, etc. Also, I see you took the
suggestion of:
Access through... Perl 5 Perl 6
= == ==
Array slice @foo[@ns] @foo[@ns]
Hash slice @foo{@ks} %foo{@ks}
Which is kewl since it makes a good amount of sense IMO.
Here's the first one.
$*ARGS is chomped;
I wonder if that wouldn't be better phrased as:
autochomp $*ARGS;# $ARGS.autochomp
[...] I don't think actions should be declared using is,
necessarily. [...] In particular, it puts the action in the passive
voice[...]
It seems actions should be active functions, so:
autoflush $STDERR; # $STDERR.autoflush
$var = read $ARGS;
print $STDOUT Hello, World!\n;
Here's the second one.
:
:$ARGS prompts(Search? ); # Perl 6
:while ($ARGS) {
I'd think I'd rather see that as:
prompt $ARGS Search? ; # $ARGS.prompt(Search? )
Without the extra new ambiguity. Thoughts?
Hmmm...the '$ARGS prompts(Foo?)' version actually works better
for me. I think that, in line with what you said above, 'prompt $ARGS
Foo?' should be interpreted as an action...that is, something that
should be done _right_now_. But I don't want the prompt to be printed
right now...I want it to be printed just before I do a read on the
filehandle. In this case, I really am setting a property, not setting a
property.
I'm not sure what the appropriate way to disambiguate the two is,
or if there even needs to be a specific mechanism (can perl be smart
enough to DWIM on this?). Definitely something to think about.
Dave
Re: Damian Conway's Exegesis 2
--- Dan Sugalski [EMAIL PROTECTED] wrote: At 07:40 AM 5/16/2001 -0700, Austin Hastings wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: Oh, didn't Larry tell you? We're making perl's parser locale-aware so it uses the local language to determine what the keywords are. I thought that was in the list of things you'd need to take into account when you wrote the parser... ;-P mios @ventanas son inmutables; Oh! Joy! Oh! Rapture! Oh! Eternal bliss! Oh. It was a joke... :) Oh, yeah! __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
RE: Damian Conway's Exegesis 2
--- Dan Sugalski [EMAIL PROTECTED] wrote: Oh, didn't Larry tell you? We're making perl's parser locale-aware so it uses the local language to determine what the keywords are. I thought that was in the list of things you'd need to take into account when you wrote the parser... ;-P mios @ventanas son inmutables; Oh! Joy! Oh! Rapture! Oh! Eternal bliss! Have you ever tried to maintain a program written in Hindi? Will ebonics be included in this locale thingy? p
Re: Damian Conway's Exegesis 2
David Grove wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: Oh, didn't Larry tell you? We're making perl's parser locale-aware so it uses the local language to determine what the keywords are. I thought that was in the list of things you'd need to take into account when you wrote the parser... ;-P mios @ventanas son inmutables; Oh! Joy! Oh! Rapture! Oh! Eternal bliss! Have you ever tried to maintain a program written in Hindi? Will ebonics be included in this locale thingy? p it better, or that's discrimination :| -- #!/usr/local/bin/perl ## Mark Koopman ## Software Engineer ## ## WebSideStory, Inc ## ## 10182 Telesis Court ## San Diego CA 92121 ## 858.546.1182.##.318 ## 858.546.0480.fax
Re: Damian Conway's Exegesis 2
On Wed, May 16, 2001 at 09:24:33AM -0700, Mark Koopman wrote: Will ebonics be included in this locale thingy? it better, or that's discrimination :| YM that be discrimination HTH. -- If computer science was a science, computer scientists would study what computer systems do and draw well-reasoned conclusions from it, instead of being rabid clueless wankers who've never even seen a real world system before, let alone used one. These are the kind of people that brought us pascal, folks. - Charles J Radder, asr.
Re: Damian Conway's Exegesis 2
Mark Koopman writes: : now we can all be linguists! As they say: It used to be I couldn't spell lingrist, and now I are one. Larry
Re: Exegesis2 and the is keyword
* Michael G Schwern [EMAIL PROTECTED] [05/15/2001 17:49]: Is that autochomp as a keyword or autochomp as an indirect method call on $*ARGS? Who cares? ;-) The thing I worry about is this: I don't think actions should be declared using is, necessarily. $STDERR is flushed; $var = $ARGS is read; $STDOUT is printed to Hello, World!\n; This could be argued 'round and 'round as to what's an action and what's a property. 'chomped' and 'flushed' make sense as properties as they are descriptive. You're setting a property which the variable will take into account in its actions. Whereas things like 'read' and 'printed' are immediate actions. I guess my main problem is the the 'is' keyword is optional where it can be inferred part. That's a whole indirect-object-like can of worms, and I don't think we should be adding more of those. This could easily be fixed by writing Damian's example: $*ARGS prompts(Search? ); As a past-tense verb: $*ARGS is prompted(Search? ); It ends up being the same effective tense. I just really don't think that is should be sometimes-optional. Put down the indirect object syntax and step away from the keyboard with your hands up! ;) TMTOWTDI, TMTOWTDI! -Nate
apology (was Re: Exegesis2 and the is keyword)
I recently received the following email from someone whose name I have snipped. * Dave Storrs [EMAIL PROTECTED] [05/16/2001 08:11]: Ok, this is basically a bunch of me too!s. Keep the snide comments to yourself. Thanks. This was regarding a reply I had made to one of Nathan Wiger's posts in the Re: Exegesis2 and the is keyword thread. This is a case of miscommunication; the bunch of me toos was referring to what _I_ was writing...that is, I was saying that the majority of my email consisted of agreeing with what Nathan had written, which I thought was very well constructed and well thought out. Obviously, I was not clear enough, for which I apologize. Dave
Re: Damian Conway's Exegesis 2
Felicitations. Yours, c, Tony Olekshy
Re: Damian Conway's Exegesis 2
Ariel Scolnicov writes: Am I the only one here who's confused? How does the printing happen in the correct order? I mean, if I said my $x = Post order: show($root, $post)\n; print $x; then (I hope) we're agreed printing would happen in the *wrong* order (first the output of show($root, $post), then the value of $x (and $x eq Post order: \n). You're exactly right. I was mislead. So how come `print' gets to mung about with evaluation order? It doesn't. I need to put down the crack bowl and get back to work :-) Thanks for pointing that out. Nat
Re: apology (was Re: Exegesis2 and the is keyword)
* Dave Storrs [EMAIL PROTECTED] [05/16/2001 11:25]: I recently received the following email from someone whose name I have snipped. * Dave Storrs [EMAIL PROTECTED] [05/16/2001 08:11]: Ok, this is basically a bunch of me too!s. Keep the snide comments to yourself. Thanks. This was regarding a reply I had made to one of Nathan Wiger's posts in the Re: Exegesis2 and the is keyword thread. This is a case of miscommunication; the bunch of me toos was referring to what _I_ was writing...that is, I was saying that the majority of my email consisted of agreeing with what Nathan had written, which I thought was very well constructed and well thought out. Obviously, I was not clear enough, for which I apologize. Dave- No reason to publicly apologize, this was as much a result of my misreading your statements as anything else. I thought we had resolved this quite satisfactorily offline, but I sincerely appreciate the public apology. I must admit I've gotten a little on-edge reading this list lately. It seems many would like to turn many issues into flamewars. I hope that people begin to abide by Nat's requests to tone things down a little. I think a lot of people are unsure and afraid of where Perl's going, which is understandable in a way because we're in the middle of doing some big redesign, but it's not a reason to overreact and assume everyone else on the list is out to destroy Perl. I do agree, however, that we need to make sure people can still program in a subset of Perl effectively. -Nate
