🚀 go-pugleaf

Matt Kennel wrote:
> 
> Patrick Logan (patrick_d_logan@ccm.hf.intel.com) wrote:
> : Consider the Stalin system for Scheme from U. Toronto.
> 
> : This is approaching more of what I would consider the *best* of both
> : worlds: getting the performance and security of a statically
> : typed language without ever having to explicitly name a type.
> 
> Then how do you get the security if you don't name a type?

	 s := concat(t, u);
	 s := s + n;

If concat() is defined only on Strings, and "+" only on numbers,
the type inferencer will know that there is an inconsistency.

> The point is that when you give variable declarations you are
> providing extra information to the computer about what
> the program should be doing, and constraining what it might do
> given any inputs.
> 
> I agree that 100% manifest type declarations isn't desirable.

Whatever static typing there is should be based either on Java-like 
interfaces or type-inferencing.

Using a class as a type constraint is sub-optimal.  All that should
matter is whether the object supports the required interface with
the required semantics.  Class constraints are overly restrictive.
Who cares what class it is, as long as it works correctly?

Interface-based constraints and type inferencing are the way to go--when 
static type constraints are needed at all.

If you need static typing for performance reasons, you should write
the few functions that really affect performance in C or assembly
and link to them as external/foreign functions.  Use the right tool
for the job.  C is the best C, and FORTRAN is the best FORTRAN (partly 
because of the resources put into C-compiler and FORTRAN compiler code 
optimization, partly because most CPUs are optimized for those two
languages, and partly because those languages were designed for 
low level system programming and scientific number crunching, respectively).

--Alan