Methods, and such
I've always liked how VB allowed you to define "instance methods."
Basically a more elegant way of doing callbacks, plus allows some
structure within your callbacks. Will Perl6 allow this (Perl5 sortof did,
but since the "bless" way of doing things is going away...)
Perhaps...
class foo {...}
$x = new foo; #BTW, is there some standard way of creating instances
#now?
method $x.frob() {...}
$x.frob;
Luke
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
On Wed, 2002-05-15 at 13:02, Larry Wall wrote:
> Aaron Sherman writes:
> : Should a tied and/or lazy array be forced to present a length on demand,
> : or can length return undef on indeterminate arrays?
>
> An array implementation can return anything it jolly well pleases, but
> I'd say undef would be a reasonable thing to return if the length is
> indeterminate. Then you can at least get warnings if you try to use
> the undefined value later. The class could even tag the undef with a
> property containing an unthrown exception that explains why the length
> is indeterminate, since Perl 6 will support interesting values of
> undef.
I had to give this one a day... First off, I'm sick so I wasn't really
thinking clearly enough to respond yesterday. But more importantly, I
learned more from this one post about how you see things working in
Perl6 than from most of the Apocalypses.
So, you see something like:
method length() {
if (...we think we know...) {
return .len; # See discussion on inlining accessors
} else {
return undef but exception("Homer::Doh: no known length");
}
}
[...]
$foolen = @foo.length // die("$0: Why, oh why: $!");
Interesting. Even more so because applications that don't take the time
to check @foo.length's return value for definedness will go on assuming
it has no elements, which is probably a good fall-back for code that
isn't paying enough attention (and of course, there's the warning).
Re: Methods, and such
On Wed, 2002-05-15 at 21:38, root wrote:
>
> I've always liked how VB allowed you to define "instance methods."
> Basically a more elegant way of doing callbacks, plus allows some
> structure within your callbacks. Will Perl6 allow this (Perl5 sortof did,
> but since the "bless" way of doing things is going away...)
>
> Perhaps...
>
> class foo {...}
>
> $x = new foo;#BTW, is there some standard way of creating instances
> #now?
my $x is foo; # I think that's correct
> method $x.frob() {...}
>
Since these are more for run-time sorts of things than compile-time
sorts of things, perhaps you want that to be a closure. You could have a
autoload check in UNIVERSAL (even in Perl5, not sure how in Perl6) that
would work like so (Perl5 syntax):
$x = foo->new();
$x->insmeth 'frob', sub {...}; # name wins 'cause it sounds Lovecraftian
$x->frob();
So, you can already do this, though I would sit down and think long and
hard about adding an autoload to UNIVERSAL in Perl5. Hopefully
autoloading will be able to chain correctly in Perl6.
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
SUMMARY Arrays should always have known lengths because that's what arrays do. This requirement is enforced culturally, not programmatically. DETAILS I submit for consideration the idea that if an array doesn't always have a defined length then it ceases to be that incredibly handy construct that we currently call "array". If arrays can answer "I dunno" when asked how long they are, that's taking away a useful feature, not adding one. If we dumb down arrays we're going to have to spend a lot of time smarting up our code. Suddenly every time you want to use an array in scalar or numeric context you first have to check if it has a defined length. That doesn't appeal to my sense of laziness, and it triggers my sense of impatience. OTOH, it doesn't seem Perlish to force the programmer to do something he or she may really not want to do. As always, Larry is wise in saying "an array implementation can return anything it jolly well pleases". So my proposal is that building array classes is like tying arrays and hashes is right now: there are certain expectations and people won't like your code if you don't follow the norms. You should always return a defined length. Documentation for arrays should indicate that they should always return a defined length. If you don't then you've broken the social contract and people will frown at you. If applicable to Perl6: the base class for tied arrays that most people will use to create their own arrays should set the length method as abstract so it needs to be overridden. -Miko
Re: Methods, and such
On Wed, May 15, 2002 at 07:38:12PM -0600, root wrote: > #BTW, is there some standard way of creating instances > #now? Class::Classless and Class::Prototyped off the top of my head.
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
On Thu, 2002-05-16 at 12:36, Miko O'Sullivan wrote:
> I submit for consideration the idea that if an array doesn't always have a
> defined length then it ceases to be that incredibly handy construct that we
> currently call "array". If arrays can answer "I dunno" when asked how long
> they are, that's taking away a useful feature, not adding one. If we dumb
> down arrays we're going to have to spend a lot of time smarting up our code.
> Suddenly every time you want to use an array in scalar or numeric context
> you first have to check if it has a defined length. That doesn't appeal to
> my sense of laziness, and it triggers my sense of impatience.
I don't see that that's the case. I do see that in some cases, you will
get a "useless array" in the sense that your "dumb" code:
my @ary is Too::Smart::Array = (1,2,3); # uh... is that how tie will work?
if @ary.length { ... do stuff ... }
So, this code will work correctly as long as @ary has a valid numeric
value, but if it doesn't your code will treat that has having zero
elements. That seems roughly correct to me. The only "correcter" thing
would be something like:
my @ary is Too::Smart::Array = (1,2,3);
if my $len = @ary.length {
...do stuff...
} else unless defined $len {
die "$0: Yes, we have no bananas: $!";
}
Why would you want to do this? Let's say that you're tying an array to a
very large, possibly infinite set of data, or a source of data that is
slow. You might not be able to REASONABLY get a length, so you return
undef. In your documentation, you advise users not to take the length,
but just dive right in and fetch the element you want, e.g.:
my $pi2k = @pi_digits[2000];
Users who do not understand this will get odd results, true, but they
get odd results that result in a reasonable default, IMHO.
Re: Accessor methods ?
> Languages like perl can't easily be inlined, since subs may be
> redefined at any time. If a sub's a leaf sub you can detect changes
> before calling safely, but if it's not a leaf sub you run into the
> potential issue of having the sub potentially redefined while you're
> in it.
If I'm in middle of executing function A, and I redefine function A, then
it doesn't matter for the execution of the function. Even un-inlined, the
execution continues as it did before. Perhaps this should be an argument
to appease the callee-save proponents. Their main argument was leaf subs.
If we can guarantee that these are inlined, then their only argument goes
away. :)
As such, I think we should be able to inline a call to A() with:
if( value A == value of A when we inlined it )
contents of sub
} else {
A()
}
Alternately, I think we should be able to mark subs as 'final' or 'inline'
to indicate our guarantee that they won't be modified. Of course, it'll
conflict with auto memoizing or auto currying modules that'd want to
override it, but that's their fault. :)
And even though distributed .pbc files and seperate compilation are some
goals of perl6, I still think we're okay. If we inline a function in
module A, and module A changes, Perl6 should ensure that the original
version is still loaded for our code, and thus our inlining should still
be valid.
Another avenue is that of self-modifying code. I know it would break
threads, or cause code duplication between threads, but when A changes, we
can either re-inline the new subroutine, or eliminate the 'if-else' check
to avoid the branch we know will be false from then on. Creating code
which optimizes itself as it's run based upon internal profiling would be
cool. But that's the topic of a different thread. :)
Of course, this is all starting to impose on p6i territory. I don't like
to start cross-posting unnecessarily, so someone please do that if it's
appropriate.
Thanks,
Mike Lambert
RE: FIRST, BETWEEN, etc.. (was Re: Loop controls)
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote: > You might not be able to REASONABLY get a length, so you return > undef. In your documentation, you advise users not to take the length, > but just dive right in and fetch the element you want, e.g.: > > my $pi2k = @pi_digits[2000]; In this case, I'd expect @pi_digits.length == Inf, not undef. Dave.
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
On Thursday 16 May 2002 01:13 pm, David Whipp wrote: > Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote: > > You might not be able to REASONABLY get a length, so you return > > undef. In your documentation, you advise users not to take the length, > > but just dive right in and fetch the element you want, e.g.: > > > > my $pi2k = @pi_digits[2000]; > > In this case, I'd expect @pi_digits.length == Inf, not undef. I'd agree with that. Perhaps you want *@lazy.length to work? Ashley Winters
RE: FIRST, BETWEEN, etc.. (was Re: Loop controls)
On Thu, 2002-05-16 at 16:13, David Whipp wrote: > Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote: > > You might not be able to REASONABLY get a length, so you return > > undef. In your documentation, you advise users not to take the length, > > but just dive right in and fetch the element you want, e.g.: > > > > my $pi2k = @pi_digits[2000]; > > In this case, I'd expect @pi_digits.length == Inf, not undef. If I'm wrong about no proof existing for pi's infiniteness, I apologize. Pick your favorite series of discrete units n, where n may or may not be infinite, but where series[x] can be determined (though possibly at great cost) for all Perl-available positive integers, x. That aside, the point holds. Tied arrays which point to complex systems may not have a known length (even in Perl5). We know this.
Re: Accessor methods ?
On Thu, 2002-05-16 at 16:07, Mike Lambert wrote:
> > Languages like perl can't easily be inlined, since subs may be
> > redefined at any time. If a sub's a leaf sub you can detect changes
> > before calling safely, but if it's not a leaf sub you run into the
> > potential issue of having the sub potentially redefined while you're
> > in it.
>
> If I'm in middle of executing function A, and I redefine function A, then
> it doesn't matter for the execution of the function. Even un-inlined, the
> execution continues as it did before. Perhaps this should be an argument
> to appease the callee-save proponents. Their main argument was leaf subs.
> If we can guarantee that these are inlined, then their only argument goes
> away. :)
Hmm... I see some conversational double-speak there, but I don't recall
the thread. Point granted.
> As such, I think we should be able to inline a call to A() with:
> if( value A == value of A when we inlined it )
> contents of sub
> } else {
> A()
> }
Yes, in the default case I think that's what was being discussed.
> Alternately, I think we should be able to mark subs as 'final' or 'inline'
> to indicate our guarantee that they won't be modified. Of course, it'll
> conflict with auto memoizing or auto currying modules that'd want to
> override it, but that's their fault. :)
Yes, I suggested "inline" or "const" I can't imagine that we would
want to do without this, regardless of what we call it. Otherwise,
auto-accessors will always be slower than using the variable. Would
everyone agree that this property should default to being set for
auto-accessors?
> And even though distributed .pbc files and seperate compilation are some
> goals of perl6, I still think we're okay. If we inline a function in
> module A, and module A changes, Perl6 should ensure that the original
> version is still loaded for our code, and thus our inlining should still
> be valid.
Oh, that one's easy (I think/hope/pray).
There're three stages:
1. "compile time" -- When a module or program is byte-coded
2. "load time" -- When byte-code is loaded off of disk
3. "run time" -- When the program begins to execute
There are complexities, but you get the idea. "Load time", I assume is
also when BEGIN executes.
In this model, you only ever inline at load time ***OR*** when the
compiler is attempting to produce a self-contained byte-code executable
(e.g. one which has all of the modules in it), in which case it executes
that part of the load time process early. If you like, call this a
sub-stage of load time, which I shall dub "link time". Link time can
only happen once per program, so it must happen when we actually know
what all of the program components are.
Any other way of doing this would seem to me to be a very dangerous
weapon to brandish so close to so many unsuspecting feet. :-(
> Another avenue is that of self-modifying code. I know it would break
> threads, or cause code duplication between threads, but when A changes, we
> can either re-inline the new subroutine, or eliminate the 'if-else' check
> to avoid the branch we know will be false from then on. Creating code
> which optimizes itself as it's run based upon internal profiling would be
> cool. But that's the topic of a different thread. :)
Code that does this by changing sub references should still work. Code
that does this by changing its own internal representation gets what it
paid for.
Re: Accessor methods ?
At 06:11 PM 5/16/2002 -0400, Aaron Sherman wrote: >On Thu, 2002-05-16 at 16:07, Mike Lambert wrote: >There're three stages: > > 1. "compile time" -- When a module or program is byte-coded > 2. "load time" -- When byte-code is loaded off of disk > 3. "run time" -- When the program begins to execute > >There are complexities, but you get the idea. "Load time", I assume is >also when BEGIN executes. > >In this model, you only ever inline at load time ***OR*** when the >compiler is attempting to produce a self-contained byte-code executable I don't think load time inlining is going to be within Parrot's spec. -Melvin
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
--
On Thu, 16 May 2002 12:36:42
Miko O'Sullivan wrote:
>SUMMARY
>
>Arrays should always have known lengths because that's what arrays do. This
>requirement is enforced culturally, not programmatically.
I totally agree that this should be enforced culturally. I think that the way a tied
array (or hash, for that matter) should handle this in this way:
sub LENGTH { #Possible implicit sub for determining length
return undef but true; #or would this be is?
}
As Larry (I think) approximately said module and class authors should not use undef
for false - it should mean undef. This seems pretty clear to me. "We have a length
here, yes, but we don't know what it is yet. It's undefined".
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
