Re: Iterating through two arrays at once
On Wed, Dec 10, 2003 at 11:44:15PM -0500, Joe Gottman wrote:
>In Perl 6, how will it be possible to iterate through two arrays at the
> same time? According to Apocalypse 4, the syntax is
> for @a; @b -> $a; $b {
>
> According to the book "Perl 6 Essentials" the syntax is
> for zip(@a, @b) -> $a, $b {
>
> Which of these is right? (of course, this being Perl, both may be right).
FWIW, I like the former even though the latter has lots of precedent
in other languages.
> Whichever of these syntaxes is right, what happens when @a and @b are
> of different sizes? I can think of three possible behaviors, each with
> its potential drawbacks:
>
> 1) The loop executes min(+ @a, + @b) times, then finishes
>successfully.
> 2) The loop executes min(+ @a, + @b) times, then throws an
>exception because the arrays were not of the same size.
> 3) The loop executes max(+ @a, + @b) times. If @a has fewer
>elements than @b, then after @a's elements are exhausted $a is
>set to undef, and similarly if @b has fewer elements than @a.
>
> In cases 1) and 2), the problem is how to get the elements of the
> larger array that were never iterated over. Case 2) is probably better
> than case 1), because the exception that is thrown might contain
> information about which array was larger and which elements of it have
> yet to be examined. In case 3), the problem is differentiating between
> an undef returned because the arrays were of different sizes, and an
> undef returned because one of the arrays contained an undef.
I believe that case 3) is the "right" answer. Why do you need to
differentiate the undefs? If you cared about whether one array was
bigger than the other, surely you could check that yourself. In any
case, run-time properties (is this redundant?) can help you out.
Perhaps you get an "undef but out_of_bounds" kind of value back when
you run off the end of the shorter array.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
enums and bitenums
Hi, I don't remember anything about enums and bitenums in the apocalypses. This is probably not very difficult to roll out something using macros but I feel that should belong to the standard language. -- stef
Re: enums and bitenums
On Thu, Dec 11, 2003 at 02:48:06PM +0100, Stéphane Payrard wrote:
: Hi,
:
: I don't remember anything about enums and bitenums in the
: apocalypses. This is probably not very difficult to roll out
: something using macros but I feel that should belong to the
: standard language.
[Warning: speculation ahead.]
I've been thinking that enums might just be subtypes of roles/properties.
After all, when you say
0 but true
it might really mean
0 but Boolean[1]
whereas
1 but false
means
1 but Boolean[0]
That is, type boolean can be thought of as enum(false,true).
So we might have a role declaration somewhere that says something like:
role *Boolean[Bit ?$val] does Property {
bit $.boolean = $val;
}
role *false does Boolean[0];
role *true does Boolean[1];
That's what the semantics might look like, but of course people would
probably want an enum or bitenum wrapper macro for real code. No reason
it couldn't be a standard macro though. Or even part of the grammar--we've
never shied away from defining one construct in terms of another for
teaching purposes. We define C in terms of C and C,
and C in terms of C. Perl 6 will do more of that, because
it makes things easy to learn.
A lot of this is negotiable, but I think it's a feature that you
can't have an enum without it being associated with a unique type
name/property. It's also appealing to me that enum "values" live
in the type namespace, since they're really subtypes (that is, types
that restrict values ranges of "real" types). There's nothing says
a subtype has to have only one value:
role Bit[Int ?$val] does Int[0|1];
Of course, I'm handwaving a lot here by using a junction. For
integer subtypes you'd typically want a range:
role Byte[Int ?$val] does Int[0..255];
That implies that the argument to Int[] has to be able to take a range.
I confess I don't know what the real declaration of "Int" looks like
yet. Certainly the first arg isn't simply an "Int". That only works
for enums. The arg has to represent some kind of generic constraint.
Pity the optimizer...
Anyway, this all implies that use of a role as a method name defaults to
returning whether the type in question matches the subtype. That is,
when you say
$foo.true
it's asking whether the Boolean property fulfills the true constraint.
When you say
$bar.red
it's asking whether the Color property fulfills the red constraint.
I suppose when you say
$baz.Byte
it's asking whether the Int property fulfills the Byte constraint, but
that's getting kind of strange.
Another implication is that, if properties are subtypes, we can't use
the same name as a cast method. Since
$baz.Byte
only returns true or false, we'd need something like (yuck)
$baz.asByte
Since class names are valid as bare names, perhaps we can improve
that to
$baz.as(Byte)
(That doesn't mean you have to write an "as" method that contains a
switch. More likely "as" is a multi method within the class of $baz.)
Another possibility is that .Byte would have to be context sensitive.
In which case we have the small problem that
if $foo.boolean { print "true" } else { print "false" }
prints "true" even if $foo is 0. You'd have to say
if +$foo.boolean { print "true" } else { print "false" }
to force a numeric context on the type. (Or use $foo.true.)
Alternately, we use the type name as a cast always, and distinguish
the boolean test:
if $baz.does(Byte) { my $byte = $baz.Byte }
I kinda like that.
Since "does" is a generalization of "isa", we probably need to generalize
smart matching to test "does" rather than "isa" for class/type names.
On the other hand, it'd be a major pain to have to write $foo.does(true).
I suppose a cast could return undef if it fails, which means that
$foo.true would return 1 or undef. Except $foo.false would return 0 or
undef. Urg.
I suspect the right solution from a linguistic point of view is to make it
context sensitive but also make it easy to disambiguate.
Explicitly:
$bar.does(Color)# does $bar know how to be a Color?
$bar.as(Color) # always cast to Color
Implicitly boolean:
$bar ~~ Color # $bar.does(Color)
?$bar.Color # $bar.does(Color)
if $bar.Color # if $bar.does(Color)
Implicitly non-boolean:
+$bar.Color # +$bar.as(Color)
~$bar.Color # ~$bar.as(Color)
$($bar.Color) # $($bar.as(Color))
@($bar.Color) # @($bar.as(Color))
Then $foo.true and $foo.false work as expected. Still have to be careful
about ?$foo.boolean though.
Interestingly, we have
$foo = $bar.Color || 0xfff;
that is equivalent to
$foo = $bar.does(Color) ?? $bar.as(Color) :: 0xfff;
which means $foo could validly end up 0. Of course, // gets there by
a different route:
$foo = $bar.Color // 0xfff;
means
$foo = defined($bar.as(Color)) ?? $bar.as(Color) :: 0xfff;
I think I'm happy with that. Maybe.
Larry
Re: enums and bitenums
On Thursday, December 11, 2003, at 10:04 AM, Larry Wall wrote:
Explicitly:
$bar.does(Color)# does $bar know how to be a Color?
$bar.as(Color) # always cast to Color
Implicitly boolean:
$bar ~~ Color # $bar.does(Color)
?$bar.Color # $bar.does(Color)
if $bar.Color # if $bar.does(Color)
Implicitly non-boolean:
+$bar.Color # +$bar.as(Color)
~$bar.Color # ~$bar.as(Color)
$($bar.Color) # $($bar.as(Color))
@($bar.Color) # @($bar.as(Color))
So C would be for casting, not coercion, right?
Suppose you have a class Foo, such that:
class Foo does (Bar, Baz) {
...
}
... or however that looks. May I then presume that
$foo.Bar.zap# ($foo.as(Bar)).zap)
calls the method C of role C, with $foo as the invocant?
MikeL
Re: enums and bitenums
Larry Wall writes:
> Anyway, this all implies that use of a role as a method name defaults to
> returning whether the type in question matches the subtype. That is,
> when you say
>
> $foo.true
>
> it's asking whether the Boolean property fulfills the true constraint.
> When you say
>
> $bar.red
So are you saying that, eg.
class Something does Color {...}
my Something $flib;
if $flib.red { print "Flib is red" }
if $flib.true { print "Should be an error before now" }
Since Something doesn't Boolean, true would be a "method not found"
error?
If that's the case, how do we attach out-of-band properties on objects
that don't expect them, but only some of them (as was the original
intent for properties, IIRC):
my role onlyonced;
sub onlyonce($arg is rw) {
die "onlyonce called twice on the same value" if $arg.onlyonced;
$arg but= onlyonced;
}
Either that doesn't work at all, because you get an "onlyonced not
found" error, or it works because onlyonced is a declared role. But
in the latter case I worry about namespace pollution.
It's clear that I don't entirely understand all of this yet (er, as much
as there is to understand... yet).
Luke
Re: enums and bitenums
On Thu, Dec 11, 2003 at 02:01:17PM -0800, Michael Lazzaro wrote:
: So C would be for casting, not coercion, right?
:
: Suppose you have a class Foo, such that:
:
: class Foo does (Bar, Baz) {
: ...
: }
:
: ... or however that looks. May I then presume that
:
: $foo.Bar.zap# ($foo.as(Bar)).zap)
:
: calls the method C of role C, with $foo as the invocant?
Seems like that would be the case.
Larry
Re: enums and bitenums
On Thu, Dec 11, 2003 at 04:18:19PM -0700, Luke Palmer wrote:
: Larry Wall writes:
: > Anyway, this all implies that use of a role as a method name defaults to
: > returning whether the type in question matches the subtype. That is,
: > when you say
: >
: > $foo.true
: >
: > it's asking whether the Boolean property fulfills the true constraint.
: > When you say
: >
: > $bar.red
:
: So are you saying that, eg.
:
: class Something does Color {...}
: my Something $flib;
:
: if $flib.red { print "Flib is red" }
: if $flib.true { print "Should be an error before now" }
:
: Since Something doesn't Boolean, true would be a "method not found"
: error?
Well, true is perhaps a bad example, since everything is boolean one
way or another. Built-in types inherit a true method that depends on the
actual value, not on a property.
: If that's the case, how do we attach out-of-band properties on objects
: that don't expect them, but only some of them (as was the original
: intent for properties, IIRC):
:
: my role onlyonced;
That might need to be "my property" to get everything defaulted for
a property kind of role. But maybe not.
: sub onlyonce($arg is rw) {
: die "onlyonce called twice on the same value" if $arg.onlyonced;
: $arg but= onlyonced;
: }
:
: Either that doesn't work at all, because you get an "onlyonced not
: found" error, or it works because onlyonced is a declared role.
I think it works because it's declared, and because you're using it
in a boolean context, so it's not really testing the value of the
property, but it's presence. The .onlyonced method merely tests
whether the object "does" onlyonced.
: But in the latter case I worry about namespace pollution.
Which namespace are you worried about polluting? It seems to me that
restricting the name to a lexical namespace and to the current object is
about as good as you can get. We're not polluting the class's namespace,
nor are we polluting the global namespace. (Though there are times where
that's the right thing to do.)
Or are you thinking that you might want to apply a property more than
once to the same object? (That would make about as much sense as
inheriting more than once directly from the same base class.)
Or are you worried that these have to be declared at all? I think we
need to declare them or we can't use them as bare identifiers. There
are no barewords in Perl 6, so they have to be something predeclared,
or otherwise syntactically distinguished. We could syntactically
distinguish them in the presence of C, but that doesn't let us
use them anywhere else, and it makes C into more of a macro than
an operator, which seems unclean. Letting them be bare identifiers
under the predeclared classname rule seems to be the most appropriate
way to do it, if indeed properties can be unified with roles (and
roles with classes). And I suspect they can be unified, and ought
to be unified. My goal isn't so much to make sticky notes as hard to
use as subtypes, but to make subtypes as easy to use as sticky notes.
I think it ought to be easy for any object to pretend to be some other
kind of object. Allomorphism is not just for untyped Perl scalars.
That being said, there has to be a little discipline to it, or we'll
find ourselves in property hell. I think roles provide a nice level
of discipline.
: It's clear that I don't entirely understand all of this yet (er, as much
: as there is to understand... yet).
Well, I don't entirely understand either. One thing I do understand
is that people get scared when I start thinking out loud. :-)
Larry
Re: enums and bitenums
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: > Or are you worried that these have to be declared at all? I think > we need to declare them or we can't use them as bare identifiers. > There are no barewords in Perl 6, so they have to be something > predeclared, or otherwise syntactically distinguished. We could > syntactically distinguish them in the presence of C, but that > doesn't let us use them anywhere else, and it makes C into more > of a macro than an operator, which seems unclean. Letting them be > bare identifiers under the predeclared classname rule seems to be > the most appropriate way to do it, if indeed properties can be > unified with roles (and roles with classes). And I suspect they can > be unified, and ought to be unified. My goal isn't so much to make > sticky notes as hard to use as subtypes, but to make subtypes as > easy to use as sticky notes. I think it ought to be easy for any > object to pretend to be some other kind of object. Allomorphism is > not just for untyped Perl scalars. > Well, I don't entirely understand either. One thing I do understand > is that people get scared when I start thinking out loud. :-) sounds like you are working on the grand unification. does string theory have any place here? and i rarely understand your thinking until it is set in concrete and then chopped up with a jackhammer into little itty bitty pieces by damian. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: enums and bitenums
On Thu, Dec 11, 2003 at 04:18:19PM -0700, Luke Palmer wrote:
: Larry Wall writes:
: > Anyway, this all implies that use of a role as a method name defaults to
: > returning whether the type in question matches the subtype. That is,
: > when you say
: >
: > $foo.true
: >
: > it's asking whether the Boolean property fulfills the true constraint.
: > When you say
: >
: > $bar.red
:
: So are you saying that, eg.
:
: class Something does Color {...}
: my Something $flib;
:
: if $flib.red { print "Flib is red" }
: if $flib.true { print "Should be an error before now" }
:
: Since Something doesn't Boolean, true would be a "method not found"
: error?
Didn't answer your question. No, because methods that happen to be
class names are special, in this worldview.
: If that's the case, how do we attach out-of-band properties on objects
: that don't expect them, but only some of them (as was the original
: intent for properties, IIRC):
:
: my role onlyonced;
: sub onlyonce($arg is rw) {
: die "onlyonce called twice on the same value" if $arg.onlyonced;
: $arg but= onlyonced;
: }
:
: Either that doesn't work at all, because you get an "onlyonced not
: found" error, or it works because onlyonced is a declared role. But
: in the latter case I worry about namespace pollution.
Okay, maybe I understand your worry now. Are you worried that
every object implicitly has boolean methods corresponding to every
class/role/property name in scope? I can see where that might
cause some heartburn.
Larry
roles (Was: enums and bitenums)
I'm invoking the principle that the only stupid question is the one not
asked:
Larry Wall wrote:
> if indeed properties can be unified with roles (and roles with
> classes).
Based on the source material pointed to as your inspiration for roles, I'm
a little confused as to how roles and classes could be unified. From what
I read in the source material, a key point of a role (well, they weren't
actually calling it a 'role' there, but I'm not recalling the term that
they did use) is that you get to bypass the "diamond inheritence" problem
by relegating member variables to classes, so that when you use multiple
roles to construct a class you don't have to worry about deciding which
version of the variable to access in any given method. Without that
restraint, exactly how does a role differ from a multiple inheritence
model?
---
Incidently, I think I've caught on to _one_ of the concepts in the
upcoming object-orientation proposal: linguistically, there's a triad of
"basic verbs" - namely "be", "do", and "have". If I'm following things
properly, one could think of an object's properties as things that it has,
its methods as things that it does, and its roles as things that it is.
So
my Dog $Spot has $spots;
would be a way to create an object inheriting from type Dog which has a
property called $.spots (is there a way to do @.spots?);
my Dog $Spot will rollover {...};
would be a way to create an object inheriting from type Dog which has a
method called rollover ("will" is used because "does" is essentially a
synonym for "will do", and "do" is a built-in method which often gets
called implicitly to represent the object's primary function); and
my Dog $Spot is pet;
would be a way to create an object inheriting from type Dog which has a
role called pet.
In a similar way, roles can specify things which must be included in order
for the role to be complete. Just like "is", "will", and "has" could be
thought of as ways of including roles, methods, and variables in an
object, "like", "must", and "needs" could be used respectively to specify
that the object must have the methods and variables in question added to
it to be considered complete. "like" probably needs some clarification,
in that saying that an object is "like" a role means that the object takes
all of that role's methods and variables as requirements (that is, it
requires methods with the same name and signature and properties with the
same name and type), in addition to whatever requirements said role
normally contributes.
Am I following?
=
Jonathan "Dataweaver" Lang
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
Re: roles (Was: enums and bitenums)
--- Jonathan Lang <[EMAIL PROTECTED]> wrote:
> Incidently, I think I've caught on to _one_ of the concepts in the
> upcoming object-orientation proposal: linguistically, there's a triad
> of "basic verbs" - namely "be", "do", and "have". If I'm following
> things properly, one could think of an object's properties as things
> that it has, its methods as things that it does, and its roles as
> things that it is.
Beautiful. This has a lot of potential, although some of it is
potential to twist young minds. It makes me want to add commas
where commas should not be.
my Dog $Spot is Pet, will { Sit() }, has @.fleas;
See what I mean? :op
But seriously, how much of that actually is valid?I doubt @.fleas will
fly (no pun intended, honest).
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
Re: roles (Was: enums and bitenums)
On Thu, 2003-12-11 at 18:15, Jonathan Lang wrote: > Based on the source material pointed to as your inspiration for roles, I'm > a little confused as to how roles and classes could be unified. From what > I read in the source material, a key point of a role (well, they weren't > actually calling it a 'role' there, but I'm not recalling the term that > they did use) is that you get to bypass the "diamond inheritence" problem > by relegating member variables to classes, so that when you use multiple > roles to construct a class you don't have to worry about deciding which > version of the variable to access in any given method. That's true, but that's incidental to the point of roles. It falls out from the important thing about roles. > Without that restraint, exactly how does a role differ from a multiple inheritence > model? Roles are a *more general* means of polymorphism and code reuse than inheritance. Inheritance is a *means* of performing a role, but it's not the only one. What's important about a role is that it marks the most important question (at least for polymorphic purposes): does this thing do what I'm about to ask it to do? It can do that role because of inheritance, but it can also do it because you've reimplemented all of the necessary methods, because you've aggregated an object that perform that role, or because you're delegating to an object that performs the role. If the only tool in your toolbox is isa(), you must either fake up some inheritance scheme or go without the three other allomorphic techniques. That's a shame. Roles exist because you can't fit all of the useful behavior in a system into a rigid class hierarchy -- some bits apply across classes -- without creating a mess. Again, inheritance is only one way a class can fulfill a role. It's not the only way and it's not necessarily the best way. See Class::Roles on the CPAN. -- c
Re: roles (Was: enums and bitenums)
Paul Hodges wrote:
> Jonathan Lang <[EMAIL PROTECTED]> wrote:
> > Incidently, I think I've caught on to _one_ of the concepts in the
> > upcoming object-orientation proposal: linguistically, there's a triad
> > of "basic verbs" - namely "be", "do", and "have". If I'm following
> > things properly, one could think of an object's properties as things
> > that it has, its methods as things that it does, and its roles as
> > things that it is.
>
> Beautiful. This has a lot of potential, although some of it is
> potential to twist young minds. It makes me want to add commas
> where commas should not be.
>
> my Dog $Spot is Pet, will { Sit() }, has @.fleas;
>
> See what I mean? :op
Technically, it would be "will do { Sit() }" or "does { Sit() }" or even
"does sit()"; but yes, I can see what you mean.
> But seriously, how much of that actually is valid?I doubt @.fleas will
> fly (no pun intended, honest).
I don't see why not; must every member of an aobject be a scalar? Can't
any of them be lists or hashes?
=
Jonathan "Dataweaver" Lang
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
