sub foo ($x) returns ref($x)
Suppose we have a function that takes an argument and returns something
with the same type as that argument. One previous suggestion is this:
sub identity ((::a) $x) returns ::a { return(...) }
This is fine if both invariants in the "the meaning of 'returns'" thread
are observed, since the inner &return will check that (...).does(::a),
and the outer context will demand ::a.does(ref($x)).
However, this relies on the fact that we unify argument types first,
then use the bounded type variables to handle returns types. Under that
scheme, It is less clear how to talk about how the types of two arguments
must relate. For example, assuming argument types are unified in a single
phase, the example below does nothing useful:
sub equitype ((::a) $x, (::a) $y) { ... }
It won't not help even if we replace the implicit "does" with "of":
sub equitype ($x of (::a), $y of (::a)) { ... }
The reason, in Luke Palmer's words:
"The trouble with this is that it doesn't provide any type safety.
In the case of a type conflict, "a" just degenerates to the Any type."
(cf. pugs/docs/notes/recursive_polymorphism_and_type)
This fact, coupled with the unappealing (::a) syntax, leads me to look
for a more Perlish representation. Adopting an idea from Odersky's
"Nested Types" paper, we can let terms occur at type variant position,
by introducing a "ref" form for types:
sub equitype ($x, $y of ref($x)) { ... }
sub subtype ($x, $y does ref($x)) { ... }
sub identity ($x) returns ref($x) { ... }
This reads like Perl, and can be guarded with trivial compile time
and runtime checks. We can also use type selectors to check
that &pick can always return Int from an Array[of => Int]:
sub pick (@x) returns ref(@x).of { ... }
The only problem I can find is that the possible confusion between the
ref() operator and the unboxed basic type "ref". Another thought is to
simply use ::() as a special "ref" form:
sub pick (@x) returns ::(@x).of { ... }
But that can confuse with the symbolic dereference syntax. All in all
I'm more happy with ref(), but better suggestions welcome.
Thanks,
/Autrijus/
pgptLqlFfMjT8.pgp
Description: PGP signature
&say's return value
What do &print and &say return? "fail" would be great on errors. On success, they return "1" now, which doesn't look very useful. How about returning the printed string? Unless called in void context, of course. (This introduces a potential semipredicate problem when looking at the return value of a printed "0" or "" while not using "fatal", but the code can use a defined guard.) -- Gaal Yahas <[EMAIL PROTECTED]> http://gaal.livejournal.com/
$arrayref.ref?
Hi,
http://use.perl.org/~autrijus/journal/25337:
> deref is now 0-level; $x = 3; $y = \$x; $y++. # now an exception
my $arrayref = [1,2,3];
say $arrayref.ref;# Ref or Array?
say $arrayref.isa("Ref"); # true or false?
say $arrayref.isa("Array"); # false or true?
say +$arrayref; # 3 or error?
say $arrayref + 1;# 4 or error?
--Ingo
--
Linux, the choice of a GNU | Black holes result when God divides the
generation on a dual AMD | universe by zero.
Athlon!|
Binding scalars to aggregates
Hi, my @array = ; my $arrayref := @array; push $arrayref, "c"; say [EMAIL PROTECTED]; # a b c d, no problem $arrayref = []; say [EMAIL PROTECTED]; # d e f, still no problem $arrayref = 42;# !!! 42 is not a Ref of Array Should the last line be treated as $arrayref = (42,); which, as the LHS is in scalar context, would auto-referize to $arrayref = [42]; which would work? Or should that be an error? (FWIW, I favour option 2.) --Ingo -- Linux, the choice of a GNU | Row, row, row your bits, gently down the generation on a dual AMD | stream... Athlon!|
Binding hashes to arrays?
Hi, is binding hashes to arrays (or arrays to hashes) legal? If not, please ignore the following questions :) my @array = ; my %hash := @array; say %hash; # b push @array, ; say %hash; # f? %hash = "Y"; say [EMAIL PROTECTED]; # ??? # (or X => "Y"?) appended to the end of @array? It seems to me supporting this is hard to get right... --Ingo -- Linux, the choice of a GNU | Mr. Cole's Axiom: The sum of the generation on a dual AMD | intelligence on the planet is a constant; Athlon!| the population is growing.
Re: $arrayref.ref?
On Sat, Jul 30, 2005 at 02:14:52PM +0200, Ingo Blechschmidt wrote:
: Hi,
:
: http://use.perl.org/~autrijus/journal/25337:
: > deref is now 0-level; $x = 3; $y = \$x; $y++. # now an exception
:
: my $arrayref = [1,2,3];
:
: say $arrayref.ref;# Ref or Array?
Array.
: say $arrayref.isa("Ref"); # true or false?
False, though tied($arrayref).isa("Ref") is probably true.
: say $arrayref.isa("Array"); # false or true?
True.
: say +$arrayref; # 3 or error?
: say $arrayref + 1;# 4 or error?
Both work.
To the first approximation, refs to scalar "non-object" values must be
explicitly derefed. But refs to non-scalar containers are considered
objects so they will happily autoderef one level. It's possible we
may find a way to relax the former constraint, but if so, it would
go back to one-level deref, not all levels.
Larry
Re: Binding scalars to aggregates
On Sat, Jul 30, 2005 at 02:33:15PM +0200, Ingo Blechschmidt wrote: : Hi, : : my @array = ; : my $arrayref := @array; : : push $arrayref, "c"; : say [EMAIL PROTECTED]; # a b c d, no problem : : $arrayref = []; : say [EMAIL PROTECTED]; # d e f, still no problem : : $arrayref = 42;# !!! 42 is not a Ref of Array : : Should the last line be treated as : $arrayref = (42,); : which, as the LHS is in scalar context, would auto-referize to : $arrayref = [42]; : which would work? : : Or should that be an error? : : (FWIW, I favour option 2.) Why shouldn't it do option 3, which is to work like in Perl 5? It should only be an error if $arrayref is declared with a type inconsistent with 42. Assignment goes to the container, not the current contents of that container. Larry
Re: Binding scalars to aggregates
Except that you've rebound the container. Hmm, maybe the original binding is an error. Larry
Re: Binding hashes to arrays?
On Sat, Jul 30, 2005 at 02:59:02PM +0200, Ingo Blechschmidt wrote: : Hi, : : is binding hashes to arrays (or arrays to hashes) legal? If not, please : ignore the following questions :) : : my @array = ; : my %hash := @array; : : say %hash; # b : push @array, ; : say %hash; # f? : %hash = "Y"; : say [EMAIL PROTECTED]; # ??? : # (or X => "Y"?) appended to the end of @array? : : It seems to me supporting this is hard to get right... As with the scalar binding I'm inclined to disallow it for now. Our theme this year: "Be strict now--we can always relax it later." Of course, I shall probably violate that myself when I get around to answering Autrijus on return type checking... Larry
Re: Binding scalars to aggregates
Hi, Larry Wall wrote: > On Sat, Jul 30, 2005 at 02:33:15PM +0200, Ingo Blechschmidt wrote: > : my @array = ; > : my $arrayref := @array; [...] > : $arrayref = 42;# !!! 42 is not a Ref of Array > : > : Should the last line be treated as > : $arrayref = (42,); > : which, as the LHS is in scalar context, would auto-referize to > : $arrayref = [42]; > : which would work? > : > : Or should that be an error? > : > : (FWIW, I favour option 2.) > > Why shouldn't it do option 3, which is to work like in Perl 5? > It should only be an error if $arrayref is declared with a type > inconsistent with 42. Assignment goes to the container, not the > current contents of that container. hm, I thought binding would make $arrayref and @array point to the same container? I.e.: my $a = 42; my $b; # $a --> Container1 --> 42 # $b --> Container2 --> undef $b := $a; # $a --> Container1 --> 42 # $b --> Container1 --> 42 (note: Container*1*) $a = 23; # $a --> Container1 --> 23 # $b --> Container1 --> 23 # But plain assignment does, of course, not change containers: my $c; # $c --> Container3 --> undef $c = $a; # $c --> Container3 --> 23 $a = 19; # $a --> Container1 --> 19 # $b --> Container1 --> 19 # $c --> Container3 --> 23 I.e. assignment goes to the container, but doesn't change it, and binding changes the container. --Ingo -- Linux, the choice of a GNU | Elliptic paraboloids for sale. generation on a dual AMD | Athlon!|
Re: Binding scalars to aggregates
Hi,
Larry Wall wrote:
> Except that you've rebound the container. Hmm, maybe the original
> binding is an error.
what about:
sub foo (Array $arrayref) {...}
my @array = ;
foo @array;
The binding used by the parameter binding code does not use the
standard := operator then, right? (As it'd have to $arrayref :=
@array.)
--Ingo
--
Linux, the choice of a GNU | We are Pentium of Borg. Division is futile.
generation on a dual AMD | You will be approximated.
Athlon!|
Re: $arrayref.ref?
On 7/30/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 30, 2005 at 02:14:52PM +0200, Ingo Blechschmidt wrote:
> : say $arrayref.isa("Ref"); # true or false?
>
> False, though tied($arrayref).isa("Ref") is probably true.
In that case, how do you check if something is a ref? `if (tied($foo))`?
Aankhen
Re: &say's return value
On Sat, 2005-07-30 at 14:56 +0300, Gaal Yahas wrote: > (This introduces a potential semipredicate problem when looking at the > return value of a printed "0" or "" while not using "fatal", but the > code can use a defined guard.) I don't know if returning the printed string is the right approach, but would returning '$string but true' avoid the semipredicate problem? -- c
Re: &say's return value
On Sat, Jul 30, 2005 at 09:25:12AM -0700, chromatic wrote: : On Sat, 2005-07-30 at 14:56 +0300, Gaal Yahas wrote: : : > (This introduces a potential semipredicate problem when looking at the : > return value of a printed "0" or "" while not using "fatal", but the : > code can use a defined guard.) : : I don't know if returning the printed string is the right approach, but : would returning '$string but true' avoid the semipredicate problem? I don't see any reason to return the string at all. It's almost never wanted, and you can always use .= or monkey but. Larry
Re: Binding scalars to aggregates
On Sat, Jul 30, 2005 at 05:17:29PM +0200, Ingo Blechschmidt wrote:
: Hi,
:
: Larry Wall wrote:
: > Except that you've rebound the container. Hmm, maybe the original
: > binding is an error.
:
: what about:
:
: sub foo (Array $arrayref) {...}
:
: my @array = ;
: foo @array;
:
: The binding used by the parameter binding code does not use the
: standard := operator then, right? (As it'd have to $arrayref :=
: @array.)
Right, so I guess what really happens is ref autogeneration in that
case, and there's no difference between
$x = @array;
$x := @array;
Hey, who said anything about consistency? :-)
Larry
Re: &say's return value
On Sat, Jul 30, 2005 at 09:36:13AM -0700, Larry Wall wrote: > I don't see any reason to return the string at all. It's almost never > wanted, and you can always use .= or monkey but. So: fail on failure bool::true on success? Pugs currently returns bool::true. Is there a way to tag a sub as failable? Should there be one? -- Gaal Yahas <[EMAIL PROTECTED]> http://gaal.livejournal.com/
module init hooks and pragmas
What gets called for me when someone "use"s my module? What gets called when someone "no"s it? L stipulates a standard syntax for import lists, and that's probably a good thing, but then how do you pass other compile-time requests to code that's being used? Perhaps in light of L, we can make "use" and "no" activate TURNON and TURNOFF blocks? -- Gaal Yahas <[EMAIL PROTECTED]> http://gaal.livejournal.com/
Re: Binding scalars to aggregates
On Sat, Jul 30, 2005 at 09:40:11AM -0700, Larry Wall wrote: > Right, so I guess what really happens is ref autogeneration in that > case, and there's no difference between > > $x = @array; > $x := @array; > > Hey, who said anything about consistency? :-) Hm, not exactly. This form: $x = [EMAIL PROTECTED]; Triggers STORE for a tied $x, and allows for assignments to $x afterwards. This form: $x := [EMAIL PROTECTED]; Destroys $x's current tie, and binds it to a read-only container (as \ produces rvalues), so future assignments will not work. I'll post a separate semi-formal analysis of containers to perl6-compiler. Thanks, /Autrijus/ pgpLWVpMaTwF6.pgp Description: PGP signature
Re: Messing with the type heirarchy
On 7/27/05, Larry Wall <[EMAIL PROTECTED]> wrote: > On Wed, Jul 27, 2005 at 11:00:20AM +, Luke Palmer wrote: >> Everything that is a Num is a Complex right? > > Not according to Liskov. Num is behaving more like a constrained > subtype of Complex as soon as you admit that "isa" is about both > implementation and interface. By the interface definition it's > slightly truer to say that Complex is a Num because it extends Num's > interface. But this is one of the standard OO paradoxes, and we're > hoping roles are the way out of it. Well, everything that is a Num is a Complex in a value-typed world, which Num and Complex are in. I don't like reference types much (though I do admit they are necessary in a language like Perl), and I'm not sure how this fits there anymore. Anyway, that's beside the point, since a supertyping need is still there for referential types. Luke
