Re: RFC 73 (v1) All Perl core functions should return ob
On Thu, 10 Aug 2000 13:22:46 +1000 (EST), Damian Conway wrote: The RFC I'm writing specifies that if the subroutine being called has a lazy context specifier on a given argument, that argument is only evaluated when the value of the corresponding element of @_ is fetched, stored, or eval'd. So the subroutine that's being called is the one that decides. If this is the only rule, I wholeheartedly agree. Now, the only operators that do lazy eval are the booleans: 'and', 'or', '' and '||'. So here too it's the operator/function that decides. -- Bart.
Re: RFC 73 (v1) All Perl core functions should return ob
At 03:38 PM 8/10/00 +1000, Damian Conway wrote: An object that has many different -ify methods: stringify numify hashify listify objectify (!) Possible, but blech. Why is that more blech? Because it's "heavy". However, if Dan assures me that objects will have lower overheads in Perl 6, I will happily withdraw my "blech". Objects will have lower overhead in perl 6. This sort of thing doesn't have to be an object, either--it should be reasonably trivial to do with the perl 6 equivalent of magic, which should be even cheaper. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 73 (v1) All Perl core functions should return ob
Why push it through a user subroutine. Might as well make it part of the
core language.
Why add another keyword non_lazy. though it isn't an antonym, eval{}
has the right meaning and effect.
I can see the utility of having the callee specify the alacrity of the
parameter. But this would put quite a burden on the parser/runtime engine.
Package A and B both define a function foo. A-foo has non-lazy arguments
B-foo has lazy arguments. Then
$fooA = new A;
$fooB = new B;
$fooA-foo
$fooB-foo
What is a poor perl parser to do?
chaim
"DC" == Damian Conway [EMAIL PROTECTED] writes:
DC But, of course, lvalue subroutines give you the ability to impose the
DC choice externally as well. If you need to pass a lazy argument to a
DC normally non-lazy subroutine, you could just write:
DC sub enervate (?$) : lvalue { $_[0] }
DC And then:
DC non_lazy( a(), enervate(b()), c() );
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 73 (v1) All Perl core functions should return ob
Why push it through a user subroutine. Might as well make it part of the
core language.
Why exacerbate the core, when I one-line user sub can do it?
Why add another keyword non_lazy. though it isn't an antonym, eval{}
has the right meaning and effect.
No, "non-lazy" was just some ordinary subroutine that I was enervating an
argument for. It certainly isn't part of the proposal.
I can see the utility of having the callee specify the alacrity of the
parameter. But this would put quite a burden on the parser/runtime engine.
Package A and B both define a function foo. A-foo has non-lazy arguments
B-foo has lazy arguments. Then
$fooA = new A;
$fooB = new B;
$fooA-foo
$fooB-foo
What is a poor perl parser to do?
Ignore the prototype unless $fooA and $fooB are typed lexicals.
I.e. act just like it does now.
Damian
Re: RFC 73 (v1) All Perl core functions should return ob
"DC" == Damian Conway [EMAIL PROTECTED] writes: $fooA-foo $fooB-foo What is a poor perl parser to do? DC Ignore the prototype unless $fooA and $fooB are typed lexicals. DC I.e. act just like it does now. Hmm, would it be too nasty for perl to recognize that all foo's have the same prototype? (Consider the singular foo case.) chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 73 (v1) All Perl core functions should return ob
I think, if you look in the archives and the Camel, you'll find that turns out not to be the case. I really don't like putting words in other people's mouths, so I'll refrain. However, I have read comments from Larry and others in Camel and perl5-porters that say something akin to this: 1. Objects should be easily embedded and embeddable 2. But don't you dare lose the functionality of a simple interface That's what I aimed this proposal at, trying to find a way to satisfy both these key requirements. I would *never* ditch #2 in favor of #1, no way. I agree with what Ken said completely: Hey! That sounds like an implementation topic... ;) (The internals should be able to handle this if the language wants it, right?) Let's get the ideas going. The internals might have some honest concerns that cause us to radically rethink this or dump it later. However, let's figure out what we want the language to do first, and figure out how to do it second. Internals aside, I think if we could get the language to do this it would be a tremendous step forward. But that's just my opinion. -Nate
Re: RFC 73 (v1) All Perl core functions should return ob
=head1 TITLE All Perl core functions should return objects Yuck. Why not use the proposed want() and return hash-refs or slices, when appropriate. Hildo
Re: RFC 73 (v1) All Perl core functions should return ob
At 07:55 AM 8/9/00 -0700, Nathan Wiger wrote: It means a lot more code to write (and debug) for the things that return these objects, and that means parts of perl will be slower, take longer to write, and take up more space. Point taken. I don't think internals should be ignored altogether, just that they shouldn't be the driving force in the language design. Otherwise we'd wind up with something like C. :-) I do agree that the internals shouldn't drive the language (otherwise a crack team of Ninja would've already taken care of that Conway guy... :), but neither can they be completely ignored. I'm just weighing in with a rough estimate of the cost. It's someone else's job to balance that cost with the benefits, but that can't be done without at least some idea of the cost. (I expect Larry's got a good handle on that already, or will when he takes a hard look at the final proposal, but...) One alternative is to add a pragma to implement this, maybe called 'object'. So a person could 'use object' to get the objects flowing everywhere. But again, this is an implementation thing I'd rather save until at least v2, after people have given input on the idea itself. Honestly, I'd rather you put together a general scheme for handling the object/scalar morphing thingie and RFC it, and then we migrate the various functions that people think should do the object thing as time and effort allow. They all might not be in perl 6.0.0 (And what are we going to call the first dev release--perl 6.-1.0?) but could get added in as modules and make it into perl 6.2.0 or something) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 73 (v1) All Perl core functions should return ob
I do agree that the internals shouldn't drive the language (otherwise a crack team of Ninja would've already taken care of that Conway guy... :), but neither can they be completely ignored. Agreed. Which reminds me, we should call off those Ninja... :-) Honestly, I'd rather you put together a general scheme for handling the object/scalar morphing thingie and RFC it, and then we migrate the various functions that people think should do the object thing as time and effort allow. Agreed again. No reason to bloat the language with 10,000 pragmas. I think RFCs 49 (object STRING func) and 73 (this one), taken together, do a pretty good job of a first stab at this. However, as I get more input from people, integrating this all together into another RFC is probably a good idea, as you suggest. But I do like keeping 49 separate because it could be integrated into the language without having to include 73. -Nate
Re: RFC 73 (v1) All Perl core functions should return ob
I don't think it will be a half million objects. Let's take stat (and all the other long list returns). The underlying implementation object could be a packed structure psuedohash. (Think DSECT.) Then the only op would be the packed structure pseudohash lookup. Which would be done at compile time. (Fallbacks to the hash lookup if really generic.) For the other types, it would be quite invisible. The parser would translate the $foo-SCALAR into whatever you would want scalar($foo) to have returned. Similarly for other possible constructs. Just think of it as moving the internal access routines closer to the language. chaim "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS On 9 Aug 2000, Perl6 RFC Librarian wrote: =head1 TITLE All Perl core functions should return objects DS While an interesting idea, it'll mean we have a half-bazillion different DS types of objects floating around just from the core. The number of DS different vtables needed to deal with this (along with the functions in DS those tables) is rather formidable, and it will tend to impact DS performance. (The more different pieces of code you have the less cache DS coherency, which means things go slower) DS These really aren't objects anyway, they'd be magic scalars. (And yes, I DS know--the difference would be what, exactly? :) Regardless, I think this'd DS be rather slow, and I don't think it ought to be core. DS However... DS If you feel the need, it should be possible to let you do this, or at DS least a part of it for one or three ops, with a module. I think it might DS be better to wait until the plain way's in and then embellish it later. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 73 (v1) All Perl core functions should return ob
At 12:09 PM 8/9/00 -0600, Nathan Torkington wrote:
I want the core to stay useful but not complex. If localtime returned
a hashref in scalar context, that'd be enough for me:
$now = localtime;
print $now-{MONTH};
print $now-{YEAR}; # already has 1900 added onto it :-)
print $now-{INTEGER};# epoch seconds value
To get what is now scalar localtime, you'd say
print localtime-{STRING};
I'd just as soon that was scalar(localtime)--if we're going to do this,
then we should do it so the short-hand format's convenient and useful.
Which sort of argues for localtime in a numeric scalar context to return
epoch seconds, in a string scalar context to return a time string, and in a
plain scalar context a hashref. (or mini-object, or tied thingamabob, or
whatever) Of course, we're trying to kill $! which does that, which is a
counter-argument...
In list context it would return a simple list of values as it does now.
RFC 48 is way too complex for my liking. In particular it expects
Perl to be able to distinguish between assignment to array and to a
hash.
I smell a counter-RFC, or at least a mailing list on which to thrash
this out.
Nat
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: RFC 73 (v1) All Perl core functions should return ob
Dan Sugalski writes: Which sort of argues for localtime in a numeric scalar context to return epoch seconds, in a string scalar context to return a time string, and in a plain scalar context a hashref. (or mini-object, or tied thingamabob, or whatever) Of course, we're trying to kill $! which does that, which is a counter-argument... I'm nervous about these different contexts. I thought scalar vs list was confusion enough. Now we're talking about overloading even further? We need to think VERY long and VERY hard about this before thinking it's a good thing. Nat
Re: RFC 73 (v1) All Perl core functions should return ob
I'm nervous about these different contexts. I thought scalar vs list
was confusion enough. Now we're talking about overloading even
further? We need to think VERY long and VERY hard about this before
thinking it's a good thing.
Well, I have, and I do.
(Though I'm no longer sure whether that's an argument for or against! ;-)
The problem is not multiple contexts; it's inconsistent return values.
That is, there's no way of guessing what a particular "listish" function
-- such as map, each, reverse, etc. -- will return in a scalar context,
without actually *knowing* what it's defined to return).
In some senses additional contexts actually help, by improving DWIMity.
If I can say:
my $month = date-{month};
then I'm much more confident what I'm going to get back. As opposed to:
my $what = date;
which might return epoch seconds as an integer, or a date string, or a
hash- or array ref, or the number of elements in the date array :-(
With extra contexts I can be surer:
my $yesterday = date() - 86400; # reasonable to expect epoch integer
my $today = "today is " . date(); # reasonable to expect date string
my $tomorrow = date()-{DoY} + 1; # reasonable to expect hash ref
Damian
Re: RFC 73 (v1) All Perl core functions should return ob
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS At 01:33 PM 8/9/00 -0400, Chaim Frenkel wrote: I don't think it will be a half million objects. Let's take stat (and all the other long list returns). The underlying implementation object could be a packed structure psuedohash. (Think DSECT.) Then the only op would be the packed structure pseudohash lookup. Which would be done at compile time. (Fallbacks to the hash lookup if really generic.) DS stat makes some sense. (local|gm)time makes some sense. The socket DS functions make some sense. The message and shared memory functions DS make some sense. Basically most of the 'advanced' functions make DS some sense. That's the problem--they all make some sense, which DS is a lot of code to get right for the .0 release. I'm not quite in favor of the proposal, but I'm not sure it is so extensive. (As I see it, all of the internals are being rewritten. So the work has to be done.) This isn't an N - N problem. This is more limited. The perl - op level, would be the access method. The advance funcs, would only have to get the mapping correct. Actually, by rationalizing the return "object" you might be making the internal coder's life easier. What am I missing? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 73 (v1) All Perl core functions should return ob
Johan Vromans wrote: Be reminded that Perl++ will increment Perl, but return the _current_ value. Heh, at least we're not python = python + 1 -- John Porter
Re: RFC 73 (v1) All Perl core functions should return ob
Nathan Torkington wrote: Dan Sugalski writes: Which sort of argues for localtime in a numeric scalar context to return epoch seconds, in a string scalar context to return a time string, and in a plain scalar context a hashref. (or mini-object, or tied thingamabob, or whatever) Of course, we're trying to kill $! which does that, which is a counter-argument... I'm nervous about these different contexts. I thought scalar vs list was confusion enough. Now we're talking about overloading even further? We need to think VERY long and VERY hard about this before thinking it's a good thing. Nat We could stop insisting on these finitely enumerated and nonextendable "contexts" and start allowing overloading assignment, like so: The assignment operator is selected from the Rvalue's methods, therefore the Rvalue gets to examine the type of the Lvalue and decide what to give it. In this scheme, "time" could by default return an integer, except if the Rvalue has a defined time-override method, in which case it is used instead. -- David Nicol 816.235.1187 [EMAIL PROTECTED] On hold for tech support since 1995
Re: RFC 73 (v1) All Perl core functions should return ob
I'm pretty much opposed to this idea. It's pushing OO too far onto perl.
Re: RFC 73 (v1) All Perl core functions should return ob
At 09:16 PM 8/9/00 +, David L. Nicol wrote: Nathan Torkington wrote: Dan Sugalski writes: Which sort of argues for localtime in a numeric scalar context to return epoch seconds, in a string scalar context to return a time string, and in a plain scalar context a hashref. (or mini-object, or tied thingamabob, or whatever) Of course, we're trying to kill $! which does that, which is a counter-argument... I'm nervous about these different contexts. I thought scalar vs list was confusion enough. Now we're talking about overloading even further? We need to think VERY long and VERY hard about this before thinking it's a good thing. Nat We could stop insisting on these finitely enumerated and nonextendable "contexts" and start allowing overloading assignment, like so: The assignment operator is selected from the Rvalue's methods, therefore the Rvalue gets to examine the type of the Lvalue and decide what to give it. Both the l and rvalues will need to participate somehow, if for no other reason as to make sure that: @foo = @bar; doesn't bother with the list flattening/unflattening trick. I'm not sure that giving the rvalue unconditional control's a good idea. In this scheme, "time" could by default return an integer, except if the Rvalue has a defined time-override method, in which case it is used instead. Gack. The problem there is then you need to worry about time-return, stat-return, shm-return, foo-return, bar-return... Icky. I think perhaps Plan B would be better. (And no, I have no plan B at the moment) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 73 (v1) All Perl core functions should return ob
"DC" == Damian Conway [EMAIL PROTECTED] writes:
DC Urgh. If you want lazy eval, say so explicitly:
DC sub somesub (?@) {
DC my @foo = @_;
DC }
Where do you want the lazy specified on the caller or the callee?
Or should it be available to both? (and of course the opposite
eval{}, to make it evaluate the arguments immediately.)
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 73 (v1) All Perl core functions should return ob
DC Urgh. If you want lazy eval, say so explicitly:
DC sub somesub (?@) {
DC my @foo = @_;
DC }
Where do you want the lazy specified -- on the caller or the callee?
Or should it be available to both? (and of course the opposite
eval{}, to make it evaluate the arguments immediately.)
The RFC I'm writing specifies that if the subroutine being called has
a lazy context specifier on a given argument, that argument is only
evaluated when the value of the corresponding element of @_ is fetched,
stored, or eval'd.
So the subroutine that's being called is the one that decides.
But, of course, lvalue subroutines give you the ability to impose the
choice externally as well. If you need to pass a lazy argument to a
normally non-lazy subroutine, you could just write:
sub enervate (?$) : lvalue { $_[0] }
And then:
non_lazy( a(), enervate(b()), c() );
Damian
Re: RFC 73 (v1) All Perl core functions should return ob
An object that has many different -ify methods: stringify numify hashify listify objectify (!) Possible, but blech. Why is that more blech? Because it's "heavy". However, if Dan assures me that objects will have lower overheads in Perl 6, I will happily withdraw my "blech". :-) Damian
Re: RFC 73 (v1) All Perl core functions should return ob
Damian Conway writes:
With extra contexts I can be surer:
my $yesterday = date() - 86400; # reasonable to expect epoch integer
my $today = "today is " . date(); # reasonable to expect date string
my $tomorrow = date()-{DoY} + 1; # reasonable to expect hash ref
(please hold, thinking out loud)
What is:
$x = date();
going to return? An object that has many different -ify methods:
stringify
numify
hashify
listify
objectify (!)
How then does this work?
somesub( date() );
Depends on the prototype, we could determine it before the subroutine
call. Might also be able to lazily evaluate the argument list for
non-prototyped lists. If it says:
sub somesub {
my @foo = @_;
}
then listify the object.
But that way lies casts so you can say that you want the first thing
from date()'s list value I hate casts. I would trust mjd to
tell me that it could be done right, but until he says that, I'm
against anything that requires casting.
Of course, down my argument leads Python. DWIM is best served
when it Does only one thing. Therefore you never Mean anything
but what it Does. Bleuch.
Nat
Re: RFC 73 (v1) All Perl core functions should return ob
What is:
$x = date();
going to return?
Probably the current scalar context result (i.e. a date string)
An object that has many different -ify methods:
stringify
numify
hashify
listify
objectify (!)
Possible, but blech.
How then does this work?
somesub( date() );
Usually list context, so usually returns list.
Depends on the prototype, we could determine it before the subroutine
call. Might also be able to lazily evaluate the argument list for
non-prototyped lists. If it says:
sub somesub {
my @foo = @_;
}
then listify the object.
Urgh. If you want lazy eval, say so explicitly:
sub somesub (?@) {
my @foo = @_;
}
But that way lies casts so you can say that you want the first thing
from date()'s list value I hate casts. I would trust mjd to
tell me that it could be done right, but until he says that, I'm
against anything that requires casting.
I'll be against casts *even* if MJD blesses them.
I REALLY hate casts.
Damian
Re: RFC 73 (v1) All Perl core functions should return ob
On Tue, 8 Aug 2000, Dan Sugalski wrote: If you feel the need, it should be possible to let you do this, or at least a part of it for one or three ops, with a module. I think it might be better to wait until the plain way's in and then embellish it later. I do believe (and please, folks, correct me if I'm wrong) that's Larry's intent with this whole project is to make Perl6 a fundamentally object-oriented language. At least, that's what I've been able to gather from the discussion threads in this mailing list. Which is the reason I suggest Perl++ as a name for the language, instead of Perl6. :) -- Mike Pastore [EMAIL PROTECTED]
Re: RFC 73 (v1) All Perl core functions should return ob
On Tue, 8 Aug 2000, Mike Pastore wrote: On Tue, 8 Aug 2000, Dan Sugalski wrote: If you feel the need, it should be possible to let you do this, or at least a part of it for one or three ops, with a module. I think it might be better to wait until the plain way's in and then embellish it later. I do believe (and please, folks, correct me if I'm wrong) that's Larry's intent with this whole project is to make Perl6 a fundamentally object-oriented language. At least, that's what I've been able to gather from the discussion threads in this mailing list. I think, if you look in the archives and the Camel, you'll find that turns out not to be the case. Dan
Re: RFC 73 (v1) All Perl core functions should return ob
Dan Sugalski wrote: The number of different vtables needed to deal with this (along with the functions in those tables) is rather formidable, and it will tend to impact performance. Hey! That sounds like an implementation topic... ;) (The internals should be able to handle this if the language wants it, right?) - Ken
Re: RFC 73 (v1) All Perl core functions should return ob
On Wed, 9 Aug 2000, Ken Fox wrote: Dan Sugalski wrote: The number of different vtables needed to deal with this (along with the functions in those tables) is rather formidable, and it will tend to impact performance. Hey! That sounds like an implementation topic... ;) (The internals should be able to handle this if the language wants it, right?) Larry can always come back to use and say: "No." :-) Mike
