🚀 go-pugleaf

In article <3209@stl.stc.co.uk> "Tom Thomson" <tom@stl.stc.co.uk> writes:
>(v) Type systems in functional languages are far too simple-minded; can't
> handle polymorphism unless it's parametric polymorphism with all 
> parameters resolvable at compile time. (If only the functional people,
> the OO people, and the type-theory people would talk to each other; again
>Haskell has made a step forwards, but it's a smal one ).

What exactly did you have in mind: we have considered extensions to
the Haskell type system but these are very much experimental (usually
it's the type theory that's an issue).  Are you in favour of
full-blown dynamic type-checking?  With/without type-inference?  What
do you require that OO type-systems give you, but FP systems don't?

>(vi) Performance remains an issue  - - although single-processor versions
> of some Ffunc.lang. compilers now produce decent code, no-one really
>knows how to parallelize this stuff effectively (I hope some-one
>connected with GRIP will explain why this is no longer true!) and a new
>OS will have to fit parallel machines. At least with C you know you're
>serial - parallelism is built by designers, not by compilers.

We've taken LML (and some Haskell) programs and run them directly on
GRIP.  The same compiler is used for both Suns and GRIP (with some
extra support for the parallel system) so all the tricks used to get
fast sequential systems are picked up for free.  Currently we're
placing sparks by hand (we need information on what the best
placements are before we can do this automatically), but we hope to
devise good automatic annotation schemes.  For the right programs, we
already get good speedups (linear speedup compared with a Sun3), but
there is still a lot of work to be done to generalise our results.
Simon can probably comment further.

Kevin





-- 
This Signature Intentionally Left Blank.	E-mail: kh@cs.glasgow.ac.uk