Re: Open and pipe
On Mon, May 02, 2005 at 10:51:57PM -0400, Uri Guttman wrote:
: LW == Larry Wall [EMAIL PROTECTED] writes:
:
: LW multi sub opensocket (
: LW Str +$mode = 'rw',
: LW Str +$encoding = 'auto',
: LW Str [EMAIL PROTECTED]) returns IO;
:
: and how will that support async (non-blocking) connects? or listen
: sockets? i assume this is sorta the replacement for IO::Socket which is
: a pure key/value api (except for the shortcut single arg host:port
: which is nice to also support).
Well, we could go that way, and just say that
multi sub openfoo ([EMAIL PROTECTED]) {...}
gets all of its parameters, named or otherwise, from the slurpy array
just like Perl 5. But then MMD has little to work with. So you're
probably right, and there need to be more named arguments. I was
mostly just trying to keep [EMAIL PROTECTED] out there at the end so that
openpipe could have multiple arguments, but we could just do that
with a single [...] parameter in any event, which could by default
be a positional parameter at the front, but also be moved to
the end as a named parameter if it has too much endweight.
Larry
Re: Open and pipe
On Mon, May 02, 2005 at 03:53:42PM -0700, Larry Wall wrote: : On Tue, May 03, 2005 at 12:32:58AM +0200, Juerd wrote: : : How about : : : : open ::= File::open : : URI::open : : Sys::Pipe::open : : : : And put the other aliases in the module that CGI.pm-:standard-ishly : : pollutes the main namespace? : : I'm not too worried about polluting the main namespace, now that : it's equivalent to Perl 5's third class keywords. I think that Perl 6 : should end up with *more* names in the global namespace than Perl 5 had, : as long as we don't end up with as many inconsistent names as PHP. On the other hand, I *do* think these should live in their own packages and be aliased into the global namespace. Perhaps generic open could just search a path for handlers as in the original RFC: use open :pathURI File; But in general I wouldn't mind seeing things like: $handle = open URI: $uri; $handle = Pipe.open([$prog, @args], :rw); Larry
Re: subtype declarations
On Mon, May 02, 2005 at 03:04:57AM -0600, Luke Palmer wrote:
: S12 says:
:
: subtype Str_not2b of Str where /^[isnt|arent|amnot|aint]$/;
:
: My brain parses this as:
:
: subtype Str_not2b[Str where /.../];
:
: Or:
:
: subtype Str_not2b[Str] where /.../;
:
: Neither of which really reflect how it is really parsed.
It's closer to the former, but perhaps more like
subtype Str_not2b[returns = :(Str where /.../)];
: It looks like
: `subtype` has a special syntax. I find this to be free of special
: syntax and clearer to boot:
:
: type Str_not2b ::= Str where /^[isnt|arent|amnot|aint]$/;
I don't. That type keyword is just a strange way to write the
:: sigil.
: Why don't we just ditch the `subtype` keyword?
Because by similar arguments we should also disallow
sub foo ($x, $y, $z) {...}
class Dog is Mammal {...}
in favor of
foo ::= sub ($x, $y, $z) {...}
::Dog ::= class is Mammal {...}
I'd rather have most declarative keywords out front, and reserve ::=
for bindings that require unusual calculations on the RHS. Though as
Thomas pointed out, you can still write
::Str_not2b ::= Str where /^[isnt|arent|amnot|aint]$/;
if you really want to.
Larry
Re: Code classes
On Mon, May 02, 2005 at 05:42:47PM -0700, Larry Wall wrote: : We're still discussing it on @Larry, but I think we can make that work. Well, now I think .foo() won't work, since .foo should be reserved for a sub ref attribute to be consistent. But I think all we have to do is find some other character to use for self calls instead of ''. There are a number of candidates, and I can convince myself that there are good arguments for most of them, so now I just have to pick the one with the weakest arguments against it. :-) Larry
Re: Code classes
Larry Wall wrote: On Mon, May 02, 2005 at 05:42:47PM -0700, Larry Wall wrote: : We're still discussing it on @Larry, but I think we can make that work. Sorry if I don't know, but where or what is @Larry? I guess some IRC? Well, now I think .foo() won't work, since .foo should be reserved for a sub ref attribute to be consistent. But I think all we have to do is find some other character to use for self calls instead of ''. There are a number of candidates, and I can convince myself that there are good arguments for most of them, so now I just have to pick the one with the weakest arguments against it. :-) I'm not carping about the syntax but about the in my eyes unfortunate binding of the topic variable to one of the invocants. My chart should give the idea of the split between these two worlds. The invocants are OOish or typeish while the parameters are procedural. Has that binding been re-painted as well? BTW, what does $.foo outside of class scope mean? $.foo == $_.foo? How are parameters passed? $.foo( $arg, blahh )? -- TSa (Thomas Sandlaß)
Re: Code classes
Thomas Sandla writes:
Larry Wall wrote:
On Mon, May 02, 2005 at 05:42:47PM -0700, Larry Wall wrote:
: We're still discussing it on @Larry, but I think we can make that work.
Sorry if I don't know, but where or what is @Larry?
Ahh, you came in too late. I don't remember who coined it, but @Larry
is the array of Larrys, that is, the design team.
I guess some IRC?
No #Larry {yet, :-}.
Well, now I think .foo() won't work, since .foo should be reserved
for a sub ref attribute to be consistent. But I think all we have
to do is find some other character to use for self calls instead of ''.
There are a number of candidates, and I can convince myself that there
are good arguments for most of them, so now I just have to pick the one
with the weakest arguments against it. :-)
I'm not carping about the syntax but about the in my eyes unfortunate
binding of the topic variable to one of the invocants.
I agree with you there. $Larry has said that he wants `when` to work
at the top level in methods, which is the main reasoning for the topic
binding. Indeed, that might cause people to use .method to mean call
on self, and then get shot in the foot when they reorganize things, but
I think it would be easy enough just to teach them not to. If they do,
then they're the ones with the gun.
BTW, what does $.foo outside of class scope mean?
It means:
BEGIN { die Can't use \$.foo outside of class scope; }
:-)
Luke
Type system questions.
With the recent discussion on type sigils, and the fact that Pugs
is moving toward the OO core, I'd like to inquire how the following
statements evaluate (or not):
# Compile time type arithmetic?
::Dual ::= ::Str | ::Num;
$*Dual ::= ::Str | ::Num;
# Run time type arithmetic?
my ::dual := ::Str | ::Num;
# Type Instantiation?
sub apply (fun::a returns ::b, ::a $arg) returns ::b {
fun($arg);
}
# Does Role live in the same namespace as Types/Classes/Modules/Packages?
my ::role = role { ... };
# Can class take type parameters like Roles cna?
class Pet[Type $petfood] {
method feed (::($petfood) $food) {...}
}
# Single colon as tuple composer?
my $Triple ::= :(Bool, Int, Str);
my $TripleTuple ::= :($Triple, $Triple);
my pair_with_int ::= - Type ::t { :(::t, Int) };
Thanks,
/Autrijus/
pgpL98kTyC7rl.pgp
Description: PGP signature
Re: LABELS: block
Larry Wall skribis 2005-05-02 19:02 (-0700): In any event, none of the proposals that bury the label is going to be acceptable. As a vital visual element of control flow, the label has to be out front where it can be seen. Something that putting quotes around them accomplishes... (I'd still like the bareword-ish labels to go away) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Open and pipe
Juerd writes:
: I don't think the command should default to $_
: Why?!
Because $_ is primarily for the use of inner loops, not outer loops,
and open tends to be in the outer loop rather than the inner loop.
As someone who tries to write clean code, I agree that the outer loop
should use a full name for the loop variable.
But as someone who writes oneliners every day, I disagree that any such
decision of how I should code should be made by the language designers.
$_ exists at many levels, and I frankly don't see a big problem with
for @files {
open;
say uc for =$_;
close;
}
Wait, so you want open to both open the filename in $_ /and/ set $_ to
the opened filehandle? Also, I don't buy your argument, since you can
do:
for @files {
say uc for =io($_);
}
Which the oneliner side of you should find awful nice.
Luke
Re: Open and pipe
Luke Palmer skribis 2005-05-03 1:34 (-0600):
for @files { open; say uc for =$_; close; }
Wait, so you want open to both open the filename in $_ /and/ set $_ to
the opened filehandle?
You are right. The example code makes no sense at all.
say uc for =io($_);
I didn't know io was blessed already.
Which the oneliner side of you should find awful nice.
It does indeed!
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Code classes
Luke Palmer wrote:
Ahh, you came in too late. I don't remember who coined it, but @Larry
is the array of Larrys, that is, the design team.
Aha. What does [EMAIL PROTECTED] evaluate to? How do the elements of
@Larry communicate?
I agree with you there. $Larry has said that he wants `when` to work
at the top level in methods, which is the main reasoning for the topic
binding. Indeed, that might cause people to use .method to mean call
on self, and then get shot in the foot when they reorganize things, but
I think it would be easy enough just to teach them not to. If they do,
then they're the ones with the gun.
If 'when' were the single exception then setting $_ = $?SELF (note: copy
not binding) there when in method code should be doable for the compiler.
BTW, what does $.foo outside of class scope mean?
It means:
BEGIN { die Can't use \$.foo outside of class scope; }
That contradicts $Larry's statement: By the way, this probably goes along
with a policy of allowing $.foo, @.foo, and %.foo outside of the class as well.
These would not refer to the actual attribute, but would call $self.foo()
underneath (except in the class that actually defines the attribute).
OK, he has got a 'probably' there. Would it be the one character saver
$.foo == $_.foo outside class scope, $.foo == $?SELF.foo in methods
of derived (or even unrelated?) classes and direct access to the instance
variable in the class scope that has the corresponding 'has $.foo' declaration?
Regards,
--
TSa (Thomas Sandla)
Re: Code classes
On Tue, 2005-05-03 at 05:33, Thomas Sandlaß wrote:
Luke Palmer wrote:
BTW, what does $.foo outside of class scope mean?
It means:
BEGIN { die Can't use \$.foo outside of class scope; }
That contradicts $Larry's statement: By the way, this probably goes along
with a policy of allowing $.foo, @.foo, and %.foo outside of the class as
well.
These would not refer to the actual attribute, but would call $self.foo()
underneath (except in the class that actually defines the attribute).
OK, he has got a 'probably' there. Would it be the one character saver
$.foo == $_.foo outside class scope, $.foo == $?SELF.foo in methods
of derived (or even unrelated?) classes and direct access to the instance
variable in the class scope that has the corresponding 'has $.foo'
declaration?
If it's ever $_, then you have the problem where the code:
given $someobj {
when $.foo {...}
}
gets wrapped in a method later in the project:
class X {
method y {
given $someobj {
when $.foo {...}
}
}
}
Now you have two options: either it's ALWAYS $?SELF.foo because it's
inside a method (and thus, this code is now wrong), or it's only
$?SELF.foo if X or any ancestor has a $.foo, otherwise it's $_.foo.
I like the idea that $.foo ALWAYS means the $.foo in the current class.
Anything else gets very ugly later on.
On a side note about auto-accessors, if I say:
class X {
has $.foo;
}
class Y is X {
has %.foo;
}
What happens to the accessors for X.foo?
If there's no current plan, my suggestion would be that every
auto-accessor has an alias of the form TYPE_NAME. That is, these hold
true:
has $foo; # Gets .Any_foo
has int $foo; # Gets .int_foo
has @foo; # Gets .Array_foo
has @foo is MyArray; # Gets .MyArray_foo
has $foo does X; # Hmmm... probably just .Any_foo
These should be automatically overridden by explicit method declarations
in this OR an ancestor class (to avoid mysterious bugs when you forget
that your $.foo is going to override your Any_foo method that has
nothing to do with an accessor), but should override inherited
auto-accessors... which of course means having to keep track of why a
method was created in the metaclass, but I don't think that's too hard.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Code classes
On Tue, May 03, 2005 at 07:59:19AM -0400, Aaron Sherman wrote:
: I like the idea that $.foo ALWAYS means the $.foo in the current class.
: Anything else gets very ugly later on.
Well, since I'm not going with for self, I'm probably not going with
the $.foo meaning anything outside of the class either.
: On a side note about auto-accessors, if I say:
:
: class X {
: has $.foo;
: }
: class Y is X {
: has %.foo;
: }
:
: What happens to the accessors for X.foo?
Overridden just like any such method.
Larry
Re: Open and pipe
On Tue, May 03, 2005 at 11:22:06AM +0200, Juerd wrote: : I didn't know io was blessed already. It pretty much is, just not the subsequent overloading of and . We'll use == and == instead. Larry
Re: Code classes
On Tue, 2005-05-03 at 08:07, Larry Wall wrote:
On Tue, May 03, 2005 at 07:59:19AM -0400, Aaron Sherman wrote:
: On a side note about auto-accessors, if I say:
:
: class X {
: has $.foo;
: }
: class Y is X {
: has %.foo;
: }
:
: What happens to the accessors for X.foo?
Overridden just like any such method.
Are has declarations ordered as they appear?
That is, does:
has $.foo;
has %.foo;
give me an accessor for %.foo or for whatever one happened to be
declared last?
NOTE: Either way, I think the above should at least issue a warning that
you're overriding the definition of the auto-accessor declared within
the same class definition, and the same should probably happen with
composition sources (though not inheritance). This is implied in S12
when it says that roles auto-detect conflicting methods, but should
explicitly refer to attributes as well.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Type system questions.
On Tue, May 03, 2005 at 05:06:15PM +0800, Autrijus Tang wrote:
: With the recent discussion on type sigils, and the fact that Pugs
: is moving toward the OO core, I'd like to inquire how the following
: statements evaluate (or not):
:
: # Compile time type arithmetic?
: ::Dual ::= ::Str | ::Num;
Yes, but I think that is the same as
our ::Dual ::= ::Str | ::Num;
which sets Dual in the current package, not in *.
Also, the :: is of course optional on the existing types.
: $*Dual ::= ::Str | ::Num;
Probably works, assuming types autoenreference in scalar context so that
$*Single ::= Str;
is equivalent to
$*Single ::= \Str;
: # Run time type arithmetic?
: my ::dual := ::Str | ::Num;
Yes.
: # Type Instantiation?
: sub apply (fun::a returns ::b, ::a $arg) returns ::b {
: fun($arg);
: }
The first parameter would be fun:(::a) these days, but yes.
(Stylistically, I'd leave the off the call.)
: # Does Role live in the same namespace as Types/Classes/Modules/Packages?
: my ::role = role { ... };
Yes, though in this case that namespace is a subset of the lexical
namespace.
: # Can class take type parameters like Roles cna?
: class Pet[Type $petfood] {
: method feed (::($petfood) $food) {...}
: }
Don't think so. I'd like to keep generics/parametric types associated
with roles if possible, so that we know exactly when they are composed
into a class. If that means we have to write a few classes that do
nothing but wrap around a role, I think it's probably worth it.
: # Single colon as tuple composer?
: my $Triple::= :(Bool, Int, Str);
: my $TripleTuple ::= :($Triple, $Triple);
: my pair_with_int ::= - Type ::t { :(::t, Int) };
I think of it as the signature composer. Does Haskell call them
tuples? That word tends to mean any immutable list in other circles,
though I suppose :(4, 2, foo) could be construed as a type whose
values are constrained to single values. But it makes :(int $x)
terribly ambiguous if it's an evaluative context. (Which is why
we wanted :() in the first place, to avoid such evaluation.)
Larry
Re: Code classes
On Tue, May 03, 2005 at 08:29:22AM -0400, Aaron Sherman wrote:
: On Tue, 2005-05-03 at 08:07, Larry Wall wrote:
: On Tue, May 03, 2005 at 07:59:19AM -0400, Aaron Sherman wrote:
:
: : On a side note about auto-accessors, if I say:
: :
: : class X {
: : has $.foo;
: : }
: : class Y is X {
: : has %.foo;
: : }
: :
: : What happens to the accessors for X.foo?
:
: Overridden just like any such method.
:
: Are has declarations ordered as they appear?
:
: That is, does:
:
: has $.foo;
: has %.foo;
:
: give me an accessor for %.foo or for whatever one happened to be
: declared last?
Neither--I'd think that'd be a fatal compile-time error.
: NOTE: Either way, I think the above should at least issue a warning that
: you're overriding the definition of the auto-accessor declared within
: the same class definition, and the same should probably happen with
: composition sources (though not inheritance). This is implied in S12
: when it says that roles auto-detect conflicting methods, but should
: explicitly refer to attributes as well.
Probably.
Larry
Re: surprising consequences
On Mon, Apr 25, 2005 at 02:37:40PM -0500, Rod Adams wrote:
: Something that crossed my mind while writing this: Does
:
:for { say } == @a;
:
: Work?
Nope. The brackets where a term is expected would be misconstrued
as an argument to the for. Maybe we need an @= for a placeholder:
for @= { say } == @;
Or maybe we could just make () serve that purpose:
for () { say } == @;
Larry
Re: use junction
On Mon, Apr 25, 2005 at 08:33:06PM +0200, Juerd wrote:
: I think it would be great to be able to use a junction with use:
:
: use strict warnings;
:
: A disjunction could mean any of the listed modules suffices. This comes
: in handy when you code something that will work with any of three XML
: parsers. Although because ordering matters, the // operator is perhaps
: better.
:
: But use strict warnigs; looks great and I wonder if it can work.
Well, there's a bit of a syntactic problem with anywhere a term
might be expected after a term, since it will assume you want to
start a foo. For another example
sub foo (IntStr block) {...}
is probably not going to parse right. Maybe that's a good place for
sub foo (:(IntStr) block) {...}
Alternately, we install a small heuristic and document it in the fine print.
By and large, we've managed to avoid such heuristics in Perl 6, but maybe
this is a good spot for an evil heuristic.
The use ambiguity might easily be resolved by saying that use
always parses using indirect object syntax, which would distinguish
use strict warnings;
from
use strict: warnings;
(Note: such a colon could possibly be used to distinguish Perl 6 from
Perl 5 in Main too, at least if the first use needs a colon.)
I don't know of any easy fix for the type var ambiguity though.
However, all that being said, please note that
use strict warnings: @args;
is unlikely to be useful unless the two modules have a similar
interface. It'd be much more useful to be able to logically cascade
use statements as a whole.
Larry
Re: use junction
Larry Wall skribis 2005-05-03 6:22 (-0700):
sub foo (IntStr block) {...}
sub foo (:(IntStr) block) {...}
Alternately, we install a small heuristic and document it in the fine print.
I personally would not mind requiring whitespace around in those
cases.
If parens are used for the grouping, then why is the colon required?
The use ambiguity might easily be resolved by saying that use
always parses using indirect object syntax, which would distinguish
use strict warnings;
from
use strict: warnings;
I thought whitespace after the sigil was no longer allowed? That
certainly fits in the sigil-is-part-of-the-name-thing.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Type system questions.
On Tue, May 03, 2005 at 05:32:44AM -0700, Larry Wall wrote:
: # Type Instantiation?
: sub apply (fun::a returns ::b, ::a $arg) returns ::b {
: fun($arg);
: }
The first parameter would be fun:(::a) these days, but yes.
(Stylistically, I'd leave the off the call.)
So, the returns trait is not part of a function's long name, but
it can still be matched against (and instantiated)?
Hrm, is it specific to the returns trait, or we can match against
any traits at all?
sub foo ($thingy does Pet[::food]) { ... }
Also, S12 talks about is context:
method wag ([EMAIL PROTECTED] is context(Lazy)) { $:tail.wag([EMAIL
PROTECTED]) }
What is the type of Lazy here? Also, is context a role or a class?
If it is a class, how does it parameterize over Lazy ?
: # Single colon as tuple composer?
: my $Triple ::= :(Bool, Int, Str);
: my $TripleTuple ::= :($Triple, $Triple);
: my pair_with_int ::= - Type ::t { :(::t, Int) };
I think of it as the signature composer. Does Haskell call them
tuples? That word tends to mean any immutable list in other circles,
though I suppose :(4, 2, foo) could be construed as a type whose
values are constrained to single values.
Err, sorry, I meant tuple type composer. In haskell:
-- Value -- -- Type --
(True, 1, Hello) :: (Bool, Int, Str)
This was because I couldn't think of other operators other than ,
to operate on types inside :(). Come to think of it, there are lots
of other things possible:
my $SomeType ::= :((rand 0.5) ?? Bool :: Int);
Also, is it correct that (4, 2) can be typed as both a :(Eager) list and a
:(Any, Any) tuple? Is it generally the case that we can freely typecast
unbounded list of values from (and to) bounded ones?
But it makes :(int $x) terribly ambiguous if it's an evaluative
context. (Which is why we wanted :() in the first place, to avoid
such evaluation.)
Evaluative context?
However, I'm a bit confused now. Does a :(...) expression stand for a
type, a variable binding, or both?
:($x) # variable binding or deref $x into a type?
:(Int) # a type?
:(Int $x) # bind a type into $x?
If all three are allowed, then :($x) itself is ambiguous... What would
these mean, then?
:(:(Int $x) | :(Str $y));
:((Int $x) | (Str $y));
Thanks,
/Autrijus/
pgp2JYIwPjwkS.pgp
Description: PGP signature
Re: use junction
Juerd wrote: I personally would not mind requiring whitespace around in those cases. Same here. Actually the whitespace after makes the destinction, or not? If parens are used for the grouping, then why is the colon required? Because it escapes into type-space like ::() escapes into name-space :) -- TSa (Thomas Sandlaß)
Re: Code classes
On May 3, 2005, at 00:04 , Luke Palmer wrote: I agree with you there. $Larry has said that he wants `when` to work Shouldn't that be @Larry[0]? Cheers, David smime.p7s Description: S/MIME cryptographic signature
Re: Code classes
On Tue, May 03, 2005 at 09:00:49AM -0700, David Wheeler wrote: : On May 3, 2005, at 00:04 , Luke Palmer wrote: : : I agree with you there. $Larry has said that he wants `when` to work : : Shouldn't that be @Larry[0]? That depends on whether you think the rest of them are pushy or shiftless. :-) Larry
Re: Type system questions.
Autrijus Tang wrote:
On Tue, May 03, 2005 at 05:32:44AM -0700, Larry Wall wrote:
: # Type Instantiation?
: sub apply (fun::a returns ::b, ::a $arg) returns ::b {
: fun($arg);
: }
The first parameter would be fun:(::a) these days, but yes.
(Stylistically, I'd leave the off the call.)
I am still advocating for :() beeing the type sublanguage.
But I'm not sure if @Larry are already that far ;)
Why not fun:( ::a returns ::b )?
So, the returns trait is not part of a function's long name, but
it can still be matched against (and instantiated)?
The long name of a function consists of three parts:
1) the invocant type list
2) the parameter type list
3) the return type list
like code:( Int, Dog : Str returns Bool ). Actually the ?+*
markers should be in there, too. Nesting should work as well,
but might not need the colon?
Hrm, is it specific to the returns trait, or we can match against
any traits at all?
Well, I think everything that is part of the type language/system
should go into :(). That IMHO includes does, where and ranges.
This was because I couldn't think of other operators other than ,
to operate on types inside :(). Come to think of it, there are lots
of other things possible:
my $SomeType ::= :((rand 0.5) ?? Bool :: Int);
I guess this drives the typechecker to the brink of madness---or beyond.
OTOH, junctive types in the sense of glb and lub would be fine in my mind!
Also, is it correct that (4, 2) can be typed as both a :(Eager) list and a
:(Any, Any) tuple? Is it generally the case that we can freely typecast
unbounded list of values from (and to) bounded ones?
Uho, big can of (type)worms! First of all we might run into the
co-/contra-variance
issue of parametric types. Secondly it should work only one way. The other way
round would be a type error unless tuple and list are equal types. The usual
type
theoretic definition of subtyping on tuples is to demand that the subtype
relation
holds pairwise. But note that type theory doesn't really handle imperative
features
very well.
But it makes :(int $x) terribly ambiguous if it's an evaluative
context. (Which is why we wanted :() in the first place, to avoid
such evaluation.)
Ups, I would hope we only have type variables inside of :() expressions,
that is ones prefixed with the :: type sigil. And I would like to see a
constraint language. So that e.g. the classical feed the animal method
type can be specified generically:
subtype eat:( ::a does Animal : does Food of ::a ) of Method;
invocant: parameter
I'm not sure if that syntax is supported, though.
Such a method should be callable on all objects that
1) do the Animal role
2) for which a class exists that does the corresponding Food role
Or more concrete:
class Cow does Animal {...}
class Grass does Food of Cow {...}
class Meat does Food of ::Tiger {...}
sub foo ( Cow $elsa, Grass $green, Meat $raw )
{
$elsa.eat( $green ); # OK
$elsa.eat( $raw );# error
$_.eat( $raw ); # works if $_.does( Tiger )
}
The above errors might be detectable at compile time,
but not these:
sub bar ( Animal $elsa, Food $green, Food $raw )
{
$elsa.eat( $green );
$elsa.eat( $raw );
}
not to mention something vague like
sub baz ( $x, $y )
{
$x.eat( $y );
.eat; # topic eats itself? Sorry, couldn't resist.
}
Also note that bar is not necessarily a subtype of foo because it
depends on Food[Cow] and Food[Tiger] beeing subtypes of Food, while
Cow is a subtype of Animal.
But it might be only me striving for CBP (Constraint Bounded Polymorphism).
YMMV :)
--
TSa (Thomas Sandlaß)
Perl 6 Summary for 2004-04-26 through 2005-05-03
Perl 6 Summary for 2004-04-26 through 2005-05-03 All~ Welcome to another weeks summary. This week I shall endeavor not to accidentally delete my summary or destroy the world. So here we go with p6c. Perl 6 Compilers implicit $_ on for loops Kiran Kumar found a bug in pugs involving for loops which use $_ but don't iterate over it. Aaron Sherman and Luke Palmer confirmed the bug. No word as to its final status, but given the rate of development of pugs... http://xrl.us/fyof Pugs Darcs trouble Glenn Ehrlich noticed that pugs's darcs repository wasn't getting updated. Sam Vilain explained that occasionally a daemon needed to be kicked. http://xrl.us/fyog Memory Game v0.2 BÁRTHÁZI András announced the release of the latest version of Memory. He also put out a call for 85x75 pixel photos for the next version. http://xrl.us/fyoh Haddock for Pugs Stuart Cook decided that the easiest way for him to understand Pugs internals was to provide better documentation. To that end he started working with haddock to automatically generate cross linked documentation for pugs. He even met with some success. http://xrl.us/fyoi /haskell.org/haddock/ in http: is export trait Garrett Rooney wondered why the is export trait appeared to do nothing in Pugs. Stevan Little explained that it was just a place holder which, while it parses, does nothing semantically yet. http://xrl.us/fyoj Pugs 6.2.2 Autrijus proudly announced the release of Pugs 6.2.2. It features a great many changes. High on that list is a great number of speed ups and thread safe, dead lock free internal storage. http://xrl.us/fyok Pugs on Cygwin Rob Kinyon noticed that Pugs was having trouble on Cygwin. He has made some headway rectifying the situation, although work remains. http://xrl.us/fyom Pugs TODO model Stevan has put some more thought into the TODO model for Pugs. His latest suggestion, annotating todo tests with a flag indicating why they are not passing, seems a little less hackish then the last one and received general support. http://xrl.us/fyon Parrot hiding inside Pugs Autrijus wanted to embed the newly released PGE. PGE is written in PIR which runs on Parrot. So, Autrijus decided to embed Parrot into Pugs. He also posted an interesting link to JHC as a possible bootstrap solution. http://xrl.us/fyoo /repetae.net/john/computer/jhc/jhc.html in http: new PGE released Maybe I should have mentioned this first... Patrick R. Michaud released a new version of the Parrot Grammar Engine. It is written entirely in PIR and generates PIR code. It has many features but not enough tests... cough hint /cough http://xrl.us/fyop Parrot Monthly Release? Jared Rhine wondered the monthly releases included April. Chip announced that April's release would be slushier then most, but would start on the fourth. http://xrl.us/fyoq http://xrl.us/fyor t/op/debuginfo.t failure François Perrad noticed a failure in with debuginfo. Leo pointed out that it was an issue of flushing output handles. Francois provided a patch (well actually two). Warnock applies to the second. http://xrl.us/fyos ParTcl Happy? Will Coleda thought that ParTcl's GC bugs were finally fixed. Leo burst his bubble. Apparently these GC bugs can disappear and reappear according to sun spot activity. http://xrl.us/fyot segfault in load_bytecode Nick Glencross submitted a patch fixing a segfault in load_bytecode. Jens pointed out that it should use real_exception instead of internal_exception. chromatic offered to write the test. No official committed message though... http://xrl.us/fyou large PackFile tinker Leo implemented a change in the interpreter PackFile structure which has been under discussion for a long time. Unfortunately, it has the potential to break a lot of JIT stuff. Tests and fixes would be greatly appreciated. http://xrl.us/fyov PMC inheritance issue Nicholas Clark was having some trouble with his Perl5 PMCs. Later he posted a mea culpa email, but Leo provided some useful pointers anyway. http://xrl.us/fyow RT cleanup Bernhard Schmalhofer cleaned out an old ticket from RT. http://xrl.us/fyox RFC assign Px, Py Some time ago, Leo requested comments on the semantics of assign. Brent 'Dax' Royal-Gordon tried to de-Warnock the thread with his support. He also suggested a clone operator. http://xrl.us/fyoy NULL in real_exception Nicholas Clark was getting bitten by a NULL pointer deref in real_exception. Leo pointed him toward the correct approach. http://xrl.us/fyoz unary operator overhaul Having finished overhauling the infix operators, Leo set to work
