Steve Fink wrote:
> There are many possible goals for any typing-related stuff we do. I'd
> say the top three are:
>
> - compile-time warnings
> - definitely unsafe operations
> - probably unsafe operations
> - runtime storage optimization
> - runtime time optimization
Yes. The last two aren't language issues though.
> We probably ought to agree on the goals of any typing first.
And the constraints -- expressiveness and backwards compatibility
being the biggest IMHO.
> I was thinking much less radically -- no global analysis, just local
> inference that throws up its hands when calling unseen functions.
It will get very tired arms then...
> then mitigating the drawbacks by explicit type declarations.
Explicit types are controversial and I'd hate to see them mandated
into the language. (And I have a funny feeling that explicit types
will spread like "const" through any program that starts using them.
Yuck.)
Perl is closer to the "binding values to symbols" model, not the
C "storing values in locations" model. IMHO it makes more sense to
adopt an ML-like type system than a C-like type system. Mutations
make the job harder, but I think it's still possible.
> too constraining to require seeing all of the source. I don't agree that
> you can't do useful stuff without global analysis, but I can't prove it
> yet.
That's the beauty of the entire existing Perl code base -- every
program presents its complete source code to the interpreter. Once
bytecode and native function calls arrive it will be a lot harder
to get dataflow analysis implemented. (Especially since Perl 6 is
supposed to have a very stable extension API.)
> Just to confirm: so with capabilities, it would be something like
>
> preincrement: (T such that T is incrementable) -> T
> and addable(T) implies incrementable(T)
>
> as opposed to
>
> preincrement: number -> number
> | preincrement: string -> string
Yes. When the compiler sees a capability mis-match, it can generate
a conversion op to acquire the capability.
Type strictness levels can be implemented by what sorts of
conversions are allowed. For example, integers may not have
the concatentation capability -- but they can be converted to
strings which do. A pragma controlling type conversion would let
people choose an appropriate level of enjoyment.
> It seems to me that capabilities vs (polymorphic) type hierarchies is
> one decision, and static typing is another, but static typing would
> interact with inference regardless of whether you use capabilities or
> not. Am I missing something?
Static typing is a mutability issue -- do we limit the types of
values we bind to a symbol? Perl doesn't restrict that and we don't
need to restrict it to provide type safety. Static typing uses
information provided by inference, not the other way around.
For example, assume "my Dog $spot;" is statically typed to be a Dog
ref. It's not initialized though so it's value is undef. Undef has no
capabilities.
> SML uses type inference, but allows you to tell it the type of a
> function if you need to.
Explicit typing is useful, if only to restrict polymorphism. I just
don't want to see such a weak inference system that it essentially
forces people to use explicit typing. If we go further and force people
to use static typing then the resulting language isn't Perl.
> When you say static typing, do you mean that my $x : integer means that
> you are guaranteed to be able to store $x in 32 bits? Or do you mean
> that all type checking is done at compile time (as opposed to dynamic or
> runtime typing)?
Here are the definitions I've learned:
explicit -- user provides explicit types of symbols
implicit -- system deduces the types of symbols
static ---- symbols once bound to a type can't be bound to another
dynamic --- symbols can be bound to any type at any time
strong ---- values have well-defined types and violations are caught
weak ------ values don't have well-defined types
Perl has an explicit, static, strong type system for scalars, arrays, hashes
and subroutines. Within the set of scalar types, it has an implicit, dynamic,
weak type system.
For comparison, C has explicit, static, strong. ML has implicit, static,
strong. Smalltalk has implicit, dynamic, strong.
- Ken
