Re: [Algorithms] Complexity of new hardware

[Nicholas \Indy\ R. <ar...@gm...>]

On Sun, Apr 26, 2009 at 2:08 AM, Sebastian Sylvan
<seb...@gm...> wrote:
> They do actually. Haskell always infers the *most general* type for a
> function. Adding a type signature can specialize it giving you faster code
> (by avoiding the need for runtime dispatch of any polymorphic functions - if
> the compiler knows that the * always refers to integer multiplication, it
> can just emit the native honest-to-goodness int multiplication instruction
> directly).

That's in interesting property, I've never seriouslly used Haskell,
but in ML, even though the * operation can be of type 'a -> 'a the
compiler will specialiase it to int -> in the cases where the type
inference allows it to do such, with no dynamic dispatch required
unless there is the possibility of union/any types running around
(which I've found to be very rare).

> As an aside, the Haskell way is actually great for writing generic code (in
> C++ et al you have to do extra work to get generic code, in Haskell you have
> to do extra work to specialize it). Also, a little hand-wavey, polymorphism
> actually restricts the amounts of valid implementations for a given type

You'll find no argument from me about the merits of type inferrence.

> (e.g. a type of a -> a, has precisely one imlementation, id, whereas a type
> from Integer -> Integer has an infinite number of implementations),

I'm sorry, I don't follow. A function of type 'a -> 'a is a superset
of int -> int thus implementations must contain the later.

> As for Haskell, it is always completely statically, and strongly typed. It
> just happens to infer those types for you at compile time, saving you some
> typing (no pun intended).

I hate to waste time arguing symantics/vocab, but I had ment adding
"type annotations"

> I would suspect that the next gen of consoles will make provisions to run
> managed code more efficiently, and in particular mixing and matching between
> C/C++ for low level systems, and C# or similar for "everything else". E.g.
> on the Xbox 360 JIT:ed code has to run in user mode, which incurs a
> performance hit. It would certainly be nice if that wasn't the case (either
> if it didn't need to switch, or if the performance hit was smaller).

Perhaps, I still don't think that C# is well designed for game
development and this "something simular" doesn't exist yet and afaict
no one is working on it. If the language doesn't exist, it's difficult
to design the hardware to run it well.

Nicholas "Indy" Ray