Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
On Sun, 2002-05-12 at 15:43, Miko O'Sullivan wrote: From: David Whipp [EMAIL PROTECTED] It it too much to ask, of the creator of a tied array, to implement their code in such a way that *reading* an element of that array does not have significant side-effects? Actually, I think that *is* a significant imposition. The whole point of tied arrays ( and hashes, scalars, etc) is that they act like arrays but internally do whatever they want. But could we go back a step? Could somebody explain why we need lookaheads, or perhaps what exactly a lookahead is in this context? Part of the current interface for tied arrays is that they know how long they are. It seems like it would be a relatively simply algorithm to say if there are still elements left in the array then populate the loop variable with the next element and run the block. Else, leave the variables as they are, run the LAST block. This brings up a concern that I've had with the idea of lazy arrays in Perl for a while. An awful lot of things in the current Perl codebase rely on the idea that an array (even a tied one) has a length at any given time (even if it changes). To change that assumption may have some serious impact on a lot of features of the language. You cannot, for example, reasonably do: (0..Inf).length You might special-case that particular one (return Inf if either end-point of a lazy array is Inf), but this is a simple example. Tie creates much more interestingly clever examples Should a tied and/or lazy array be forced to present a length on demand, or can length return undef on indeterminate arrays?
Re: Accessor methods ?
On Sat, 2002-05-11 at 17:43, Damian Conway wrote:
Paul Johnson wrote:
I've always found the word like to be very wishy-washy in a computer
langauge. In what way is newbaz like baz? And just how alike are they?
There must be a better way to describe this.
Perhaps:
method set_baz($newbaz is compatible($.baz)) { $.baz = $newbaz }
method set_baz($newbaz is typeof($.baz)) { $.baz = $newbaz }
I don't like the second one, as it implies that Perl has types, which it
really doesn't (properties are just that, properties).
The first is a bit long, but I could get behind it in a crunch.
However, my first thought is, why do we need a keyword here?
Since it's not otherwise valid syntax (the semi-unofficial battle-cry of
perl6-language ;-), I propose:
method set_baz($newbaz is $.baz) { .baz = $newbaz }
There's two ways to take C$x is $y. I think it's easy enough to get
people used to the idea that aliases are created vi C:=, so there's
really only one left.
And, yes I do think that using the auto-accessor is more correct. It
should be in-lined under most circumstances, but if someone comes along
later and moves that accessor into a super-class, we're still good.
Re: Accessor methods ?
On Fri, 2002-05-10 at 21:42, Damian Conway wrote: Wouldn't those be the same? Not quite. C$.bar is a direct access to the attribute. C.bar is a call to the accessor. There might well be performance issues. I would expect that there won't be, but perhaps I'm optimistically over-hyping Perl6's inlining before it exists. Surely, we would always prefer that every method except accessors use the accessors, though. After all, later modification of the class might move the member variables to a super-class.
Re: stringification of objects, subroutine refs
On Sat, 2002-05-11 at 00:39, Dan Sugalski wrote: At 8:58 PM -0700 5/10/02, [EMAIL PROTECTED] wrote: I was wondering how perl6 would stringify (as in Data::Dumper): That's not stringification. It's serialization, which is a different thing entirely. What you'll potentially get is a thing that can be completely reconstituted into what it originally was, complete with variables, methods, attributes, and whatnot. How much gets serialized depends on what you'll choose--in the worst case, your entire program will need to get serialized, but that'll be doable. This seems like a no-brainer to me, so I must be missing something ;-) Wouldn't it be possible to just settle on Parrot byte-code as a serialization form? If so, everything is serializable, no? Granted, your data might not come out intact if your writer and reader don't agree in module versions, but this is a minor nit in the scheme of things.
Re: Selective exporting of properties/methods
On Sat, 2002-05-11 at 13:58, Chris Dutton wrote:
method world is public_to(Bar) {
Might as well make that:
method world is private(Bar)
I tend to take any opportunity to recycle syntax, plus keywords with
underscores give me gas. ;)
Re: Why not {,n} in quantifiers?
On Tue, 2002-05-14 at 20:13, Larry Wall wrote:
It's unlikely that {n,m} will still have that meaning in Perl 6. Maybe we'll
have something like this:
Perl 5Perl 6
{1,3} 1..3
{3} 3
{3,} 3+
{0,3} 3-
Then again, maybe not...
Hopefully there will be some replacement. I can't count the number of
times I've relied on things like:
$b = qr/\d{1,3}/;
if (ip = ($addr =~ /($b)\.($b)\.($b)\.($b)/)) {
die $0: \$addr\: bad IP\n if grep {$_255} ip;
print(0x,(map {sprintf %02x, $_} ip),\n);
} else {
die $0: \$addr\ is not an IP address\n;
}
It would be a shame to loose that.
Re: stringification of objects, subroutine refs
At 10:10 AM -0400 5/15/02, Aaron Sherman wrote:
On Sat, 2002-05-11 at 00:39, Dan Sugalski wrote:
At 8:58 PM -0700 5/10/02, [EMAIL PROTECTED] wrote:
I was wondering how perl6 would stringify (as in Data::Dumper):
That's not stringification. It's serialization, which is a different
thing entirely.
What you'll potentially get is a thing that can be completely
reconstituted into what it originally was, complete with variables,
methods, attributes, and whatnot. How much gets serialized depends on
what you'll choose--in the worst case, your entire program will need
to get serialized, but that'll be doable.
This seems like a no-brainer to me, so I must be missing something ;-)
Wouldn't it be possible to just settle on Parrot byte-code as a
serialization form? If so, everything is serializable, no?
Mostly, yes, if we put aside the issue of code written in C.
There is the issue of how much gets serialized, and how things get
reconstituted, which is where things get interesting. Assume this:
package foo;
our @ISA = (Rezrov);
my $bar;
$foo = sub {$bar++};
$baz = sub {$bar++};
if you serialize and reconstitute $foo *and* $baz, should they share
a $bar? Should all of Rezrov be serialized with them and, if so, do
they each get a private copy? Do they both see the same @ISA, as its
global?
It's all doable, of course, and as much a matter of policy on
serializing and reconstituting.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Accessor methods ?
At 10:04 AM -0400 5/15/02, Aaron Sherman wrote: On Fri, 2002-05-10 at 21:42, Damian Conway wrote: Wouldn't those be the same? Not quite. C$.bar is a direct access to the attribute. C.bar is a call to the accessor. There might well be performance issues. I would expect that there won't be, but perhaps I'm optimistically over-hyping Perl6's inlining before it exists. 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. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Why not {,n} in quantifiers?
Aaron Sherman writes:
: Hopefully there will be some replacement. I can't count the number of
: times I've relied on things like:
:
: $b = qr/\d{1,3}/;
: if (ip = ($addr =~ /($b)\.($b)\.($b)\.($b)/)) {
: die $0: \$addr\: bad IP\n if grep {$_255} ip;
: print(0x,(map {sprintf %02x, $_} ip),\n);
: } else {
: die $0: \$addr\ is not an IP address\n;
: }
:
: It would be a shame to loose that.
Bear in mind we have to translate Perl 5 to Perl 6, so it's quite unlikely
that we would drop the general case. The only question here is what it
ought to look like in the general re-huffmanization of regexen.
Larry
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
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. Larry
Re: Accessor methods ?
On Wed, 2002-05-15 at 10:36, Dan Sugalski wrote:
At 10:04 AM -0400 5/15/02, Aaron Sherman wrote:
On Fri, 2002-05-10 at 21:42, Damian Conway wrote:
Wouldn't those be the same?
Not quite. C$.bar is a direct access to the attribute. C.bar is a call
to the accessor. There might well be performance issues.
I would expect that there won't be, but perhaps I'm optimistically
over-hyping Perl6's inlining before it exists.
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.
That seems like a tragic performance-sink Is there some way that the
caller and/or function could indicate that they want to avoid such
over-generalization? Something like an is const or is inline to
indicate that the subroutine is read-only and cannot be redefined?
When the parser sees:
sub subname(...) is inline { ... }
subname(...);
It could safely just inline the code without any sort of run-time check.
Normal inlining would still take a hit, but I'd hate to see:
$minusone = E ** (PI * I)
go through a run-time check for redefinition.
Of course, we're talking run-time. If you use two modules which both
define a common subroutine as inline (or only one does), there should be
no conflict and the second should override the first. It's only run-time
redefinition of a subroutine which would prevent efficient inlining.
So, in my example above, you could still Cuse Math::Pi::Simple to get
the version of PI that's defined as 3, but you could not have a
subroutine that swapped PI between the two values, based on a
command-line flag.
Re: Selective exporting of properties/methods
On Wednesday, May 15, 2002, at 10:17 AM, Aaron Sherman wrote:
On Sat, 2002-05-11 at 13:58, Chris Dutton wrote:
method world is public_to(Bar) {
Might as well make that:
method world is private(Bar)
I tend to take any opportunity to recycle syntax, plus keywords with
underscores give me gas. ;)
I had considered is public(Bar), but this works too.
Re: Why not {,n} in quantifiers?
From: Larry Wall [EMAIL PROTECTED]
It's unlikely that {n,m} will still have that meaning in Perl 6. Maybe
we'll
have something like this:
Perl 5 Perl 6
{1,3} 1..3
{3} 3
{3,} 3+
{0,3} 3-
What are your feelings on multiple ranges for matches? E.g. the following
expression means 1 to 3, 5, or 10 or more:
1..3|5|10+
-Miko
Re: Why not {,n} in quantifiers?
Miko O'Sullivan writes:
: From: Larry Wall [EMAIL PROTECTED]
: It's unlikely that {n,m} will still have that meaning in Perl 6. Maybe
: we'll
: have something like this:
:
: Perl 5 Perl 6
: {1,3} 1..3
: {3} 3
: {3,} 3+
: {0,3} 3-
:
: What are your feelings on multiple ranges for matches? E.g. the following
: expression means 1 to 3, 5, or 10 or more:
:
: 1..3|5|10+
My feelings are that nobody has ever asked me for it before, so it's
not something worth making special syntax for. On the other hand, if
instead of inventing new syntax we stick to a more Perlish syntax, we
could generalize it to an ordinary slice kind of list:
1..3,5,10..Inf
But you'd still have the complexity of making it work, and it still
seems like something almost nobody would ever use. And you could get
the same effect with an appropriate assertion:
(...)* { @$+.length =~ (1..3,5,10..Inf) or fail }
That's assuming that quantified captures produce arrays rather than
the final match as Perl 5 does.
Larry
Methods, and such
It seems something messed up while I tried to send this earlier. If this
is essentially a duplicate, ignore it.
I've always liked how VB allowed you to do instance methods. They allow
for more elegant callbacks, and more structure if callbacks are
complicated. Will Perl6 allow this? (Perl5 sortof did, but since the
bless way of life is going away...)
Perhaps...
class foo {...}
$x = new foo; #BTW: is there some unified way of creating instances
# in perl6?
method $x.frob() {...}
$x.frob;
Luke
Re: Methods, and such
This is perfectly possible in Perl5, so I don't see why it wouldn't be
possible in Perl6...
Create a new package.
Add the sub to that package.
Set the @INC of that package to your current package.
Re-bless yourself into the new package.
Granted a nice simple syntax would be nice, but that's what modules are
for.
You also run into issues of identity. If I add a method to an existing
object, is that object still of the same type? Should 'ref' return the
same classname, or is it okay if it returns some auto-generated name after
it's had instance methods added to it? The latter would occur with the
Perl5 solution above, and I would argue that it should stay that way,
since it's not exactly the same type.
Mike Lambert
Luke Palmer wrote:
Date: Wed, 15 May 2002 19:51:39 -0600 (MDT)
From: Luke Palmer [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Methods, and such
It seems something messed up while I tried to send this earlier. If this
is essentially a duplicate, ignore it.
I've always liked how VB allowed you to do instance methods. They allow
for more elegant callbacks, and more structure if callbacks are
complicated. Will Perl6 allow this? (Perl5 sortof did, but since the
bless way of life is going away...)
Perhaps...
class foo {...}
$x = new foo; #BTW: is there some unified way of creating instances
# in perl6?
method $x.frob() {...}
$x.frob;
Luke
