James Mastros writes:
> >In the case of ..., give it type error semantics. That is, any
> >expression involving ... gets type "...". Except instead of reporting
> >at the end of the statement, just suppress the errors and move on.
>
> Huh? Um, no, your ideas as to what happens don't give the desired
> semantics for ..., and don't make other desired semantics fall out
> naturally.
>
> The basic semantic for ... is that use of it gives an error at runtime,
> when the code has been hit. Unless a pragmata changes things, it
> should not be possible to trigger an error from use of ... without the
> code being actually run.
People were talking about what type "..." should be. So at static type
analysis time (if we even do that; I think we do, otherwise we wouldn't
have static type declarations), you give "..." type error semantics, but
then don't die until you actually run the "...".
my int $foo = ...; # ...
my int $bar = 34; # int
$bar += $foo; # ...
That's the correct solution to the type analysis problems. I wasn't
trying to address anything else.
The problem was that people were trying to derive it/make it a role/give
it some type that could go anywhere. I'm just saying it should be a
special case. That special case is already used when there's a type
error, except that the type error dies after the current statement
finishes processing.
Luke
