Re: perl 6 requirements
Alan Burlison [EMAIL PROTECTED] writes:
"Randal L. Schwartz" wrote:
Graham sub def { my @a = (9,8,7); return @a; }
That's not returning the array. That's returning a copy of the contents
of @a in a list context, and the number of elements of @a in a scalar
context, using the "@a" operator. You still haven't "returned the array".
So then in fact it is impossible to return an array - yes? You can
either return a single scalar or a list. The closest you can come to
returning an array as an entity is to return a reference to it - \@a.
Have I got that straight?
At the perl level yes. The core C can push an AV * on the stack
but perl does not know what it means. (Tk did this for a while
internally before I decided to comply with the perl semantics.)
--
Nick Ing-Simmons
Re: perl 6 requirements
Tom Christiansen [EMAIL PROTECTED] writes: True, but maybe a lower precedance keword is needed like we did or || and . I think someone suggested "then" print $string1, $string2, "\n" then return 3 if $cond; then again, maybe not. Why not just piss everybody off? return 3 after print $string1, $string2 if $cond; honk love forth if. Don't you mean honk forth love if -- Piers
Re: perl 6 requirements
On Thu, Aug 03, 2000 at 06:39:02AM -0700, Randal L. Schwartz wrote: Nope. Sometimes my brain prefers the EXPR if EXPR form because of the much smaller punctuation footprint. Removing the comma doesn't seem to serve anything but making Perl less powerful, and not confusing Chaim quite as often. True, but maybe a lower precedance keword is needed like we did or || and . I think someone suggested "then" print $string1, $string2, "\n" then return 3 if $cond; then again, maybe not. Graham.
Re: perl 6 requirements
Randal L. Schwartz writes: | "Chaim" == Chaim Frenkel [EMAIL PROTECTED] writes: | | Chaim It's the overloading of the ',' operator. | | Just like the overloading of the @ARRAY_NAME operator or the | getpwuid() operator. Perhaps you are back to merely complaining about | all context-sensitive things again. :-) Possibly, although I must ask: since everything is up-for-grabs, I ask (without implying any feeling one-way-or-tother): How useful is the , operator in it's C-style statement separator, as opposed to list separator guise? It seems to be a common cause of confusion. Mx. -- See, the stars are shining bright Everything's all right tonight -- (Martin L. Gore, Never Let Me Down Again)
Re: perl 6 requirements
"GB" == Graham Barr [EMAIL PROTECTED] writes: GB On Tue, Aug 01, 2000 at 07:41:59PM -0700, Randal L. Schwartz wrote: "Chaim" == Chaim Frenkel [EMAIL PROTECTED] writes: Chaim It's the overloading of the ',' operator. Just like the overloading of the @ARRAY_NAME operator or the getpwuid() operator. Perhaps you are back to merely complaining about all context-sensitive things again. :-) GB No, I think the main problem is that many do not graps the list vs GB array distinction and would possibly document the sub wrong, giving GB a surprise when it is used. Then perhaps, just get rid of the list/array distinction? Make everything an array? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: perl 6 requirements
"RLS" == Randal L Schwartz [EMAIL PROTECTED] writes: "Chaim" == Chaim Frenkel [EMAIL PROTECTED] writes: Chaim It's the overloading of the ',' operator. RLS Just like the overloading of the @ARRAY_NAME operator or the RLS getpwuid() operator. Perhaps you are back to merely complaining about RLS all context-sensitive things again. :-) I'm not complaining about it. I'm bringing it to the table. I've been doing perl for a number of years, and I still don't have the get*() scalar/list memorized. I keep looking it up. Its a useful feature. But not useful enough that I expedend the effort to memorize them. As Graham pointed out. It might simply be the list/array division. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: perl 6 requirements
"Graham" == Graham Barr [EMAIL PROTECTED] writes: Graham You say "operator" and you are right. I think the issue is a sub Graham can return either. Really? How does a sub return "an array"? (Unless you're about to mutter something about "lvalue subs" :) a sub can return only an rvalue. An "array" as an rvalue is always a list. Unless we disagree on the meaning of array and list. In that case, let's get back to terminology. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: perl 6 requirements
On Wed, Aug 02, 2000 at 09:42:09AM -0700, Randal L. Schwartz wrote:
"Graham" == Graham Barr [EMAIL PROTECTED] writes:
Graham You say "operator" and you are right. I think the issue is a sub
Graham can return either.
Really? How does a sub return "an array"?
There is a difference
sub abc { return (7,8,9) }
sub def { my @a = (9,8,7); return @a; }
print scalar abc(),"\n";
print scalar def(),"\n";
__END__
9
3
(Unless you're about to mutter something about "lvalue subs" :) a sub
can return only an rvalue. An "array" as an rvalue is always a list.
Unless we disagree on the meaning of array and list. In that case,
let's get back to terminology. :)
I am not refering to context, but what the user types. If an author
does not document the two subs above correctly as returning a list and an array
then a user may get surprised.
Graham.
Re: perl 6 requirements
"Graham" == Graham Barr [EMAIL PROTECTED] writes:
Graham There is a difference
Graham sub abc { return (7,8,9) }
That's returning either a list or a comma operator result, depending
on context.
Graham sub def { my @a = (9,8,7); return @a; }
That's not returning the array. That's returning a copy of the contents
of @a in a list context, and the number of elements of @a in a scalar
context, using the "@a" operator. You still haven't "returned the array".
Graham I am not refering to context, but what the user types. If an author
Graham does not document the two subs above correctly as returning a list and an array
Graham then a user may get surprised.
Yes, but the first part is getting the naming right. You don't
"return an array". :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: perl 6 requirements
"Randal L. Schwartz" wrote:
Graham sub def { my @a = (9,8,7); return @a; }
That's not returning the array. That's returning a copy of the contents
of @a in a list context, and the number of elements of @a in a scalar
context, using the "@a" operator. You still haven't "returned the array".
So then in fact it is impossible to return an array - yes? You can
either return a single scalar or a list. The closest you can come to
returning an array as an entity is to return a reference to it - \@a.
Have I got that straight?
--
Alan Burlison
Re: perl 6 requirements
"Randal L. Schwartz" wrote:
"Martyn" == Martyn Pearce [EMAIL PROTECTED] writes:
Martyn Possibly, although I must ask: since everything is up-for-grabs, I ask
Martyn (without implying any feeling one-way-or-tother):
Martyn How useful is the , operator in it's C-style statement separator, as
Martyn opposed to list separator guise? It seems to be a common cause of
Martyn confusion.
I use it a lot, in places where I want two expressions executed,
especially as one part of "EXPR while EXPR" or "EXPR if EXPR".
Yeah, I could use a do-block on either side, but then I might
as well go to a full while statement.
warn("too much information"), return 3 if $some_condition;
Very handy.
warn("too much information") and return 3 if $some_condition;
works, but depends on the return value of warn. I bet it would cover
most uses, though. I'd love to eliminate the comma ambiguity.
We could add a 'then' keyword.
Re: perl 6 requirements
"Steve" == Steve Fink [EMAIL PROTECTED] writes: Steve We could add a 'then' keyword. We have one. It's called "comma in a scalar context". :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: perl 6 requirements
On 02 Aug 2000 16:42:35 -0700, Randal L. Schwartz wrote: Steve We could add a 'then' keyword. We have one. It's called "comma in a scalar context". :) Now do the same with a print command. Aren't you trying to hard leaning backwards? -- Bart.
Re: perl 6 requirements
Thank you for your compliments. Would you be willing to give us a first shot at what Perl *is* to get the discussion going? Only as slogans; deep analysis will require ascending a nearby summit. "Perl is a language you already know, but that you just don't know that you know." "Perl is a language for getting your job done." "Perl is the Cliff Notes of Unix." "Perl tries to fit itself around your brain instead of insisting on the reverse." And most importantly: "Perl makes programming fun again." --tom
Re: perl 6 requirements
'Scuse me, but I'm a bit puzzled by this whole 'What is Perl' thing. My
understanding of the rewrite was that it was primarily to provide a
cleaner implementation than the current 'worn out' one, and to remove
some of the more egregious features, e.g. the over-reliance on globs in
some places, move some functionality out of the core and into modules
etc. I certainly didn't expect a wholesale language redesign to be on
the cards. After all, I *like* the current language features (well,
mostly). I *like* the punctuation characters (they tell me what sort of
thing I am looking at). What other language allows such poetry as
"@{$hash}{@keys} = @values"? I humbly submit that perl without the
perlisms is not perl.
--
Alan Burlison
CARP - CAmpaign for Real Perl
Re: perl 6 requirements
Chaim Frenkel [EMAIL PROTECTED] writes: "CF" == Chaim Frenkel [EMAIL PROTECTED] writes: "TA" == Ted Ashton [EMAIL PROTECTED] writes: TA In general, they do what you want, unless you want consistency. CF Randal, Tom, et. al. CF How locked in to your brain is this lack of consistency? How un-perlish CF would it be to cleanup, crypto-context, or the meaning of a list in CF a scalar context, or ... (Kirrily, this one is for the record.) I'd also like to add, redo, next, last escaping a subroutine. They do? Cool. -- Piers
Re: perl 6 requirements
"Chaim" == Chaim Frenkel [EMAIL PROTECTED] writes:
Chaim I don't find this meaningful:
Chaim sub foo() { return (1,7) }
Chaim $x = foo();# $x == 7;
I do. It's perfectly consistent.
$x = SUBROUTINE CALL
...
SUBROUTINE CALL = (1,7)
You just factor out the subroutine call there. It's the same
as
$x = (1,7) # $x is 7
I've never gotten why you don't get that. :) It's a very simple rule:
the return context is the context of the invocation, and is determined
at runtime as well as being detectable at runtime (see wantarray()) if
you want to do something special.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: perl 6 requirements
"Chaim" == Chaim Frenkel [EMAIL PROTECTED] writes:
"CF" == Chaim Frenkel [EMAIL PROTECTED] writes:
CF (Kirrily, this one is for the record.)
CF I'd also like to add, redo, next, last escaping a subroutine.
Chaim Make that _NOT_ escaping a subroutine.
Chaim map { ...; last; ...} @foo
Chaim should simply terminate the map, not go to the next containing loop.
So using map as it SHOULD be used (heh), what would you have @a
contain after:
@a = map { last if $_ 5; $_ } 1..10;
Would it be 1..5, 1..6, 1..10, whatever it had before, or ()? I could
make arguments for each of them. :)
I think making that *not* a looping block makes more sense, so we
don't get into this nonsense. The "last" cleanly breaks out of the
innermost loopblock, which by definition doesn't have a return value,
so there's no chance we'll freak out an assignment.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: perl 6 requirements
Johan Vromans writes: : On Mon, Jul 31, 2000 at 09:50:11PM -0600, Nathan Torkington wrote: : So Larry is doing most of the evaluation for us. He's the one who : gave us the good things in the Perl language we have now. He'll be : the one vetoing the ridiculous ideas. : : Larry said: "Perl5 was my rewrite of Perl, Perl6 will be the community's : rewrite of Perl." I think it is not realistic to keep shooting around, : trusting Larry to prevent anyone from getting hurt. We have our own : responsibilities as well. Yes, I don't mind other people shooting down the bad ideas, as long as they do it politely, and with good reasoning to back it up. It's the mindless sniping that is destructive, particularly when we're still brainstorming. People need to have a safe forum for bringing up half-baked ideas, even if we're also trying to create a more official RFC mechanism. On the flip side, we need to be Very Careful not to get our egos irrevocably tied to our proposals. I have a particular distaste for the sort of argument that goes, "If I can't have it my way, I'm going to take all my marbles and go home." That's not an argument--that's nuclear blackmail. I'm the only one who's allowed to make that sort argument, and you'll never hear me making it. Unless, of course, you count Rule 1 as a form of it. :-) But you'll notice I almost never invoke Rule 1. I am, in fact, rather more fond of Rule 2. I think everyone should be allowed to change their mind occasionally. Larry
Re: perl 6 requirements
Thus it was written in the epistle of Matthew Persico, Johan Vromans wrote: On Mon, Jul 31, 2000 at 09:50:11PM -0600, Nathan Torkington wrote: So Larry is doing most of the evaluation for us. He's the one who gave us the good things in the Perl language we have now. He'll be the one vetoing the ridiculous ideas. Larry said: "Perl5 was my rewrite of Perl, Perl6 will be the community's rewrite of Perl." I think it is not realistic to keep shooting around, trusting Larry to prevent anyone from getting hurt. We have our own responsibilities as well. In support, I got the impression that Larry wasn't even going to play Supreme Court on this one and that this was the whole point of all these groups and Perl6 - get Larry out from under all the piles of responsibility and to make Perl truck-proof. ;_) If that's really the case, then the efficiency of the whole project just dropped massively. After all, if Perl is to stay Perl and Larry has abandoned us, then we as a community will have to function as a Larry-emulator, a task which p5p pretty-well established as impossible. Somebody needs to tell Larry that he can't get out of being dad to this kid even if it has grown up a little :-). Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == For God's sake, please give it up. Fear it no less than the sensual passion, because it, too, may take up all your time and deprive you of your health, peace of mind and happiness in life. -- Bolyai, Wolfgang (1775-1856) [Bolyai's father urging him to give up work on non-Euclidian geometry.] == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: perl 6 requirements
Johan Vromans wrote: On Mon, Jul 31, 2000 at 09:50:11PM -0600, Nathan Torkington wrote: So Larry is doing most of the evaluation for us. He's the one who gave us the good things in the Perl language we have now. He'll be the one vetoing the ridiculous ideas. Larry said: "Perl5 was my rewrite of Perl, Perl6 will be the community's rewrite of Perl." I think it is not realistic to keep shooting around, trusting Larry to prevent anyone from getting hurt. We have our own responsibilities as well. In support, I got the impression that Larry wasn't even going to play Supreme Court on this one and that this was the whole point of all these groups and Perl6 - get Larry out from under all the piles of responsibility and to make Perl truck-proof. ;_) -- Matthew O. Persico "If you were supposed to understand it, we wouldn't call it code." - FedEx NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
