I hit the MLton-wall! :)

[Anoq of the Sun]

"Stephen Weeks" wrote:
> We're generating assembly (.s files) that we assemble using gcc.  I would guess
> that the same way you're using gcc to crosscompile the .c files we can use to
> crosscompile the .s files.  Anyways, we can talk about it more once we release
> the new compiler.

Sounds great! :)

I'm also wondering - if you say that you generate multiple
files, is it then going to be "less-than-whole-program"
optimization?

But I guess generating native ASM should give a
performance boost in itself :)

> This is not so easy.  The problem is that MLton
> relies on having the whole program in order to make
> representation decisions.  For example, it might choose 
> to represent (int * char * bool) one way in one
> program and a different way in another.
> What you want is not impossible -- we would
> just need to decide on some standard "external"
> representation for all types, and then MLton could
> arrange to convert between the internal and external representations when
> crossing library boundaries.
>
> Other things are even more difficult (or pretty much
> impossible with MLton). Polymorphism and higher order
> functions are eliminated at a very early pass in
> MLton, and again require having the whole program.
> Exporting polymorphic or higher order functions
> is just not going to happen the way MLton is currently
> designed.

OK - polymorphic and higher order functions would
be nice to have of course, but for most things I can
think of right now, that one would want to put into a
separate library would probably be mostly monomorphic
functions which are either first order or at least "just"
curried... - and a curried function could be converted
to tuples and wrapped back as a curried function
on the client (caller) side...

For instance in the RenderMan bindings i made for
ML, only one function is polymorphic
and only the 4 functions for making textures take
a function as argument. And that's even "just" a filter
function - which is not even a function in a
RIB-file based RenderMan renderer in the first place -
it's usually just one out of a set of predefined
strings :)

I just pass a function + a string - to have both
options - but, say, if the compiler could just
"ignore" all polymorphic and higher order function
parameters then the RenderMan API in ML would even
work 100% correctly as it is now! :)


Cheers
-- 
http://www.HardcoreProcessing.com