On Mon, Jul 09, 2001 at 08:54:49PM -0700, Steve Fink wrote:
> User-defined types?
Haven't even thought about them yet.
> > I'm pondering this being okay:
> >
> > my Num $dec = 4.0;
> > my Int $int = $dec; # Num -> Int okay since 4.0 truncates to 4
> > # with no(?) information lost
> >
> > but I think it will complicate my Grand Plan which I'm not ready to
> > reveal.
>
> Compile-time or run-time?
It would have to be a run-time type check if we allowed Num to cast to
Int. Similar to allowing Strings to cast to Ints and Nums. Is that
run-time nature that worries me, might get in the way of implied
types.
> my Num $x = 3.0;
> $x++;
> my Int $y = $x;
>
> Could be compile-time, if you do constant folding first.
Alot of how much checking we can do at compile-time depends on how
long we have to compile, and thus optimize. If you precompile your
Perl 6 program, then we have all the time in the world. If you're
compiling on the fly (ie. how we do it now) then you can't spend so
much time doing constant folding.
Dunno yet.
> So Int is a subset of Num, and '4' and '4.0' are considered to be
> exactly equivalent.
Yes, that's my thinking. I'm going to have to play with it and see
how annoying it is if Nums don't auto-cast to Ints.
> > but we like to mix types up in hashes. One way we can allow this is
> > to have a generic type, Value (or perhaps Scalar) that every type will
> > cast into. Hash keys would be implicitly of type Value.
> >
> > my Value %hash = (foo => 1, bar => 2, baz => 'yarrow');
> >
> > but that's pretty much the same as switching off strong typing. So
> > obviously hashes have to have per-key types. I will leave the syntax
> > of that as an exercise for the reader. It would have to make it easy
> > to declare lists of keys as being a single type. If we come up with
> > something nice here, it can probably be backported onto arrays.
>
> It's only switching off strong types for that variable, so it's a
> valuable thing to do.
Its switching off types for pretty much all hashes, since hashes very
often have mixed type values (think objects and structs). We've
definately got to have per-key hash types.
> my qt(String => DontEvenThinkAboutIt) %tree = (id => 1);
> $tree{parent} = \%tree;
>
> (or if you think you can tackle that)
>
> $tree{parent_with_distance} = [ 0, \%tree ];
>
> a map from strings to numbers and lists of two elements, where the first
> element is a number and the second is a reference to a map from strings
> to numbers and lists of two elements...
I don't follow.
> How is a regex different from any other function that makes sense with
> multiple types?
Most functions don't change a variable in place. s/// does. substr()
is also a problem. .= another.
my $foo = 42; # Int type implied
my String $bar = read_line($some_file);
$foo .= $bar;
That expands out to
$foo = $foo . $bar;
$foo . $bar is fine, since Ints can auto-cast to Strings. The result
is a new string which is reassigned to $foo. If that string looks
like an integer, its okay. Otherwise its a run-time type violation.
Not having auto-casts would solve this problem, but then it would make
life suck in so many other ways.
> my Int $foo = 42;
> my Num $bar = 4.2;
> my Int $foo2 = increment($foo);
> my Num $bar2 = increment($bar);
> my Sub $sub2 = increment(sub { 42 });
>
> sub increment {
> my $x = shift;
> if (ref $x eq 'CODE') {
> return sub { 1 + $x->(); }
> } else...
> }
I'm going to presume for the moment that functions must have declared
types, otherwise they simply take and return Values. I haven't really
thought about making function signatures implicit yet.
> sub escape_cgi_param { return quotemeta(shift()) }
>
> my Int $id = escape_cgi_param(...);
> my String $name = escape_cgi_param(...);
The latter is fine. The former might be a run-time type violation if
escape_cgi_param returns something that doesn't look like an integer.
> But it needs to resolve the type of an arbitrarily nasty expression
> anyway, doesn't it?
>
> my $foo = (time % 2) ? "one" : 3; # $foo is a String
I don't know how far we can do with this. Again, it depends alot on
how much time we have to compile.
> Or consider
Yep, these are all nasty possiblities. mjd suggested I go through
some real-world code and see how much of it I can make implicit, what
problems are encountered, if there are any restrictions I might have
to make, etc... I'm going to do that a bit and come back. Functions
will be tough.
> (you wrote your ramblings, I wrote mine. I spent much time thinking in
> circles about this stuff during the RFC phase and didn't really come up
> with much. So now I'm seeing what I come up with without thinking. :-) )
Yeah, not thinking can sometimes reap interesting ideas. :)
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
<GuRuThuG> make a channel called #Perl, and infest it with joking and
fun.... it doesnt make alot of sense.
