[MLton] Number theory and MLton C FFI

[Stephen Weeks]

> So, I can tell the PolynomialOverFiniteField functor to use a
> special vector type, which is like your example and expects some
> form of tuple elements like FiniteFieldOfComplex or
> QuotientFieldOfEuclideanDomain ?

Exactly.  So, your application of the functor would look like

PolynomialOverFiniteField 
	(structure FiniteField = Mersenne
	 structure Vector = MersenneVector)
 
and the functor would express via a sharing constraint that the vector
elements are the same as the finite field.

> I need to think about this, but it does sound like it might solve my
> problem. =) So I would have PolynomialOverFiniteFieldWithCustomVector
> which is the real implementation and PolynomialOverFiniteField just
> passes a vector to it for default behaviour?

Yep.

> The problem I see is that code doesn't 'automatically' benefit from
> the vector flattening. It has to target it.

True.  With appropriate abstraction and code structuring, this should
simply be a matter of using "FlatVector" vs "Vector" when you want to
apply the optimization.

> Any code which doesn't do it will be incompatible with code that
> does.

True.  But this seems good to me.  That is, if you represent the same
mathematical object in two different ways, you want the type system to
keep you from mixing them up.  You may need to spend some effort in
your system to arrange that you only construct a certain mathematical
object once via some composition of functors, rather than in two or
more different ways.  I'm not sure whether or not that is a big deal.

> If I could somehow automatically predicate functors off the
> parameters I could solve this transparently.
...
> Also, future constructions might accept an arbitrary field, and
> internally build a polynomial over it, they wouldn't know that they
> should provide a special vector to the polynomial functor.

You could put the Vector module as a substructure of your basic
FiniteField elements, so that every module/type "knows" how to
represent vectors of itself.  Then, the functor for generating complex
numbers over a field would express in its result that vectors of
complex's are flat.

> Also, I'm probably mistaken, but I feel that an MLton array of pairs
> like this will already be 'flat' and this special adaptor just makes
> one version appear different mlton to coerce it to work with the
> FFI.

This is not necessarily true.  In fact, in MLton 20040227, all arrays
of tuples are represented boxed.  In our upcoming release, some will
be represented flat, but it is up to the vagaries of the optimizer.
So, if you want to force it to be flat, you have to do it yourself.

> Another question, how would I initialize a vector from C?
> They're supposed to be constant --- what happens if I blithely
> overwrite the contents?

If you are going to modify from the C side, it would be better to use
an array.  Modifying a vector is unsafe and could lead to incorrect
optimization.

> > The only way I see to do this is to step outside the language, and to
> > produce different "linking" code (i.e. functor applications and
> > structure definitions) depending on what's available via C libraries.
> > The SML type system should be quite helpful here.
> 
> So, the MLton compiler peeks inside a library to see if there already is a
> method with the right name? (assuming there's some sort of name mangling
> involving the parameters to a functor...)
> 
> That would be perfect!
> Does this already exist?
> How would I go about doing that?

I think I didn't communicate my intention here.  I will try again.
Prior to compiling your SML program, based on which C libraries are
available, you (or your scripts) should create an SML file that
applies the appropriate functors or defines the appropriate structures
as wrappers around C libraries.  No magical support from MLton/SML,
just you telling it what to do.