Re: Usage in commercial software

IIRC, before I refactored a significant portion of the runtime system
when porting MLton to 64-bit, libmlton.a was built in a way that if
the (optimized) user program did not use IntInf operations, then the
resulting executable would not have any GMP symbols.  Essentially, all
of the IntInf_* functions (which call GMP functions) were compiled in
a separate compilation unit that was archived into libmlton.a.  If no
IntInf_* functions were required to resolve symbols from the user
program, then the compilation unit could be dropped during linking,
and there would be no residual dependency on GMP.  This is exactly the
way things currently work for large portions of the Basis Library; for
example, you should see no residual dependency on networking functions
(e.g., socket, connect) if the user program does not use any Socket
operations, because all of the networking functions are compiled in
separate compilation units that are archived into libmlton.a.

When refactoring things for the 64-bit port, I found it convenient to
fold the IntInf_* functions in with the rest of the garbage collector
code.  But, I don't believe that is essential.  It shouldn't take much
effort to compile the IntInf_* functions (runtime/gc/int-inf.c) in
their own compilation unit, separate from the rest of the garbage
collector code.  This would eliminate the dependency on GMP for any
program that didn't make use of IntInf.

Of course, while the user program may not make direct use of IntInf,
it may make indirect use of IntInf if it uses other Basis Library
functionality that depends upon IntInf (or LargeInt).  For example,
the Time.time type is represented by a LargeInt.int (number of
nanoseconds).  It might be possible to tweak the Basis Library
implementation to use IntInf less, but it would probably be difficult
to eliminate IntInf entirely.  As Vesa notes, you would have a
bootstrap problem with a Basis Library implementation that did not
provide IntInf, since the compiler uses IntInf extensively to
represent int/word constants.

Instead, I would suggest providing an alternative implementation of
the IntInf_* primitives (basis-library/primitive/prim-int-inf.sml) in
SML.  Then use a command line flag "-int-inf-impl {gmp,sml}" (similar
in spirit to our "-default-type" flag) which would (among other
effects) define an MLB path variable (again, similar to what is done
with the "-default-type" flag) that would be used to select an
appropriate implementation of the IntInf_* primitives.  It would
clearly be less performant than the GMP implementation, but it would
probably suffice for many applications where IntInf was used, but not
used extensively.


On Thu, Jun 12, 2014 at 10:46 AM, Vesa Karvonen <[email protected]> wrote:
> Yes, this is the approach I was suggesting earlier.  Basically to
> implement a compiler switch (or some other means) to tell the compiler
> not to support IntInf (requiring GnuMP).  IIRC, MLton uses IntInf
> internally to implement constant folding so fully removing
> dependencies to external MP arithmetic libraries would likely require
> a bit more work (if you wish to distribute the MLton compiler itself),
> but would be doable as well.
>
> - Vesa Karvonen
>
> On Thu, Jun 12, 2014 at 4:58 PM, Adam Chlipala <[email protected]> wrote:
> [...]
>> Even better would be to allow MLton to compile code with no dependencies
>> on any MP library.  My guess is most MLton-compiled programs don't need
>> MP integers, and yet we must carry this one nonstandard linking
>> dependency around everywhere.
>>
>> ------------------------------------------------------------------------------
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> _______________________________________________
>> MLton-user mailing list
>> [email protected]; [email protected]
>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> MLton-user mailing list
> [email protected]; [email protected]
> https://lists.sourceforge.net/lists/listinfo/mlton-user

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems