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