[MLton-user] NLFFI incompatibility with SML/NJ?

[Vesa Karvonen]

Just a quick note (don't have time to write to longer reply although
I'd like to).  I've lately started using NLFFI.  It seems to me that
there is a certain deficiency in the way operations on C objects are
organized in NLFFI and the problem you are describing is also a result
of that deficiency.  The problem is that you can't write ML code that
would be invariant with respect to changes in the C types.  For example,
if you need to Get or Set a value, then you need to explicitly mention
the name of the underlying C type in your code, e.g. C.Get.slong.  I
believe, but haven't tried it, that the problem could be fixed by
making the operations on C objects generic, type-indexed functions.
Instead of a family of values on a type

  C.Get.slong
  C.Set.slong
  C.Cvt.c_slong
  C.Cvt.ml_slong
  C.S.slong
  C.T.slong

there would be just a single type-index (or perhaps a couple of them
for light/heavy versions)

  C.slong

and a number of generic, type-indexed operations (for example)

  C.get
  C.set
  C.toC
  C.toML
  C.size
  C.alloc

The type of C.ulong would be something like

  (slong, (* possibly other types..., *) MLRep.Long.Signed.int) t

IOW, it needs to be parameterized with all the types associated with
different operations on slong objects/values.  The value C.long
would basically be a record containing all of the C.*.slong values.
The generic operations then simply select the appropriate field from
the type-index record.

I believe that this kind of type-indexed skin could be built on
top of the NLFFI lib (without modifying it).  With a little help
from mlnlffigen (which would then need to be extended to generate
type-indices) one could then significantly more easily write ML
code that is invariant with respect to the types of C objects.

-Vesa Karvonen

Quoting Adam Chlipala <adamc at hcoop.net>:

> I've had great success using the NLFFI with both MLton and SML/NJ in the 
> development of an OpenSSL binding.  However, there's one nagging 
> difference that I've found in the typing of the automatically-generated 
> signatures, forcing me to create my own tiny "compatibility" signature 
> that has different implementations for the different compilers.
> 
> The example I've come across so far has to do with the return type of, 
> for instance, C.Get.uchar'.  In SML/NJ, the right WORD structure to use to
> manipulate these values is Word32.  In MLton, it seems to be 
> MLRep.Char.Unsigned.
> 
> Have I missed a common alias for these structures that works in both 
> MLton and SML/NJ?