[MLton-devel] Re: MLton citation?

[Dan Grossman]

Matthew Fluet wrote:

> @misc( 
> MLton,
> key = "MLton",
> title = "{MLton}, a whole program optimizing compiler for {Standard ML}",
> note = "{\tt http://www.mlton.org/}"
> )


looks good -- thanks.


> A minor note, depending on how accurate you want to be.  MLton certainly
> does not box any primitive types (int, float, char, word).  So, an ML 
> 'a vector instantiated at int will "look" (for the most part) like a C
> int[].  Likewise, monomorphisation reveals a lot more opportunity to
> flatten record/tuple aggregates.  But, currently, an ML 'a vector
> instantiated with int * int will "look" like a C (void*)[] with pointers
> to int * int's.  Better, obviously, would be to inline the tuples into
> the vector and avoid the extra dereference.  I believe that Steve is
> planning on implementing this sometime later this year.


Interesting.  I'm not really going into this level of detail.  Below 
I've pasted the couple of relevant paragraphs from my current draft. 
The real point is "Cyclone distinguishes boxed types from unboxed types. 
  If you want the implementation to do it, there are several well-known 
options.  Go read about some of them."

--Dan

============
Higher level languages generally do not restrict the types that a type
variable can represent.  For example, a polymorphic function can be
instantiated at any type, including records and floating-point types.
Simpler implementations add a level of indirection for all records and
floating-point numbers to avoid code duplication.  Sophisticated
analyses and compiler intermediate languages can avoid some
unnecessary levels of
indirection~\cite{greg-phd,tarditi-phd,xavier-unbox-popl,xavier-unbox-tic,church-cil}.
In the extreme, ML's lack of polymorphic recursion allows
whole-program compilers to \emph{monomorphize} the code, essentially
duplicating polymorphic functions for each type at which they are
instantiated~\cite{mlton,mlj}.  The amount of generated code appears
tolerable in practice.  As Section~\ref{sec:tyvars-evaluate} mentions,
C++~\cite{cplusplus} defines template instantiation in terms of code
duplication, making template functions closer to advanced macros than
to parametric polymorphism.

An example of a simple compromise is the
current OCaml implementation~\cite{ocaml}: Records and arrays of
floating-point numbers do not add a level of indirection for the
numbers.  Polymorphic code for accessing an array (in Cyclone terms,
something of type \texttt{$\A$[]}), must check at run-time whether the
array holds floating-point numbers or not, so run-time type
information is necessary.
===============





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel