Juerd wrote:
Larry Wall skribis 2005-03-11 8:45 (-0800):
On Fri, Mar 11, 2005 at 03:58:13PM +0100, Thomas Sandlaß wrote:
: Int @i;
: Num @n = @i; # type error?
I think the naive user is going to expect that to work, and I also
suspect the naive user is right to expect it, because it makes sense.
This may be one of those areas where we can successfully hide the
high-falutin' theory from mere mortals simply because it maps onto
what they expect already.
It'd be great if this were a standard feature you can also use for your
own objects.
I fully agree with what Larry said about constant and copied parameter
types. There we can easily go with covariant subtyping. OTOH the idea
of a container providing a view of the values is a very high ideal. I think
it is worthwhile to implement in the standard library for ubiquitous
value types like Str, Num and Int. But I doubt that it can be achieved
such that the Array class does respect any (future) value type!
One idea that formally pushes the problem out of the Array class is to
require a role ArrayEntry from every entry. But that would need very
neat defaults to have a chance to be acceptable in the community---I hear
people say: "What? I need to implement that complicated role just to put
my Blahh into an Array?". OK, would could go with independend types when
the entry doesn't ArrayEntry, but then we might hear a slightly different
complain: "I can't mix my Blahhs with other objects in an array!".
So I'm at a loss here.
I believe $foo.Num in this case should return the Num-ified version of
$foo. And maybe the int method numbers have is redundant, and should
be spelled Int instead. Or, well, if this is the case, int should return
an int (not Int) for consistency.
Maybe +$foo even maps to $foo.Num, and ~$foo maps to $foo.Str and ?$foo
maps to $foo.Bool?
Hm, are charsets representable as classes/roles?
my Str::utf8 $bar = ...;
my Str::latin1 $foo = $bar;
In my mindset that would read as
my Str[utf8] $bar = ...;
my Str[latin1] $foo = $bar; # type error? Or dynamic compatibility test?
$bar = $foo could be allowed if the typechecker knew
that latin1 subtypes utf8. More interesting is actually
the typing of string constants:
$foo = "äöü"; # Str[latin1]
my Str[ASCII] $ascii = "äöü"; # type error?
Hmm, since "what is compile to you is runtime for the compiler"
it might by a normal store attempt that is then rejected by the object
and caught by the compiler---cool. Is there also an unchecked store
operation that can be used when the typechecker knows the assignment
is (type-)correct?
Regards,
--
TSa (Thomas Sandlaß)
