The flat-array.sml benchmark was added to demonstrate the DeepFlatten SSA2 optimization.

However, the C and LLVM codegens, at sufficiently high optimization levels, are able to eliminate the arithmetic computation from the benchmark:

CPU: Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz
RAM: 8GB
OS: Ubuntu 12.04.4 LTS (GNU/Linux 3.2.0-67-generic x86_64)
MLton: g0c2c0cd
GCC: 4.6.3
LLVM: 3.4.1

MLton0 -- mlton -codegen amd64 
MLton1 -- mlton -codegen amd64 -drop-pass deepFlatten
MLton2 -- mlton -codegen llvm -llvm-llc-opt -O1 -llvm-opt-opt -O1 
MLton3 -- mlton -codegen llvm -llvm-llc-opt -O1 -llvm-opt-opt -O1 -drop-pass deepFlatten
MLton4 -- mlton -codegen llvm -llvm-llc-opt -O1 -llvm-opt-opt -mem2reg -llvm-opt-opt -O1 
MLton5 -- mlton -codegen llvm -llvm-llc-opt -O1 -llvm-opt-opt -mem2reg -llvm-opt-opt -O1 -drop-pass deepFlatten
MLton6 -- mlton -codegen llvm -llvm-llc-opt -O2 -llvm-opt-opt -O2 
MLton7 -- mlton -codegen llvm -llvm-llc-opt -O2 -llvm-opt-opt -O2 -drop-pass deepFlatten
MLton8 -- mlton -codegen llvm -llvm-llc-opt -O2 -llvm-opt-opt -mem2reg -llvm-opt-opt -O2 
MLton9 -- mlton -codegen llvm -llvm-llc-opt -O2 -llvm-opt-opt -mem2reg -llvm-opt-opt -O2 -drop-pass deepFlatten
MLton10 -- mlton -codegen c -cc-opt -O1 
MLton11 -- mlton -codegen c -cc-opt -O1 -drop-pass deepFlatten
MLton12 -- mlton -codegen c -cc-opt -O2 
MLton13 -- mlton -codegen c -cc-opt -O2 -drop-pass deepFlatten
run time ratio
benchmark  MLton0 MLton1 MLton2 MLton3 MLton4 MLton5 MLton6 MLton7 MLton8 MLton9 MLton10 MLton11 MLton12 MLton13
flat-array   1.00   1.52   1.52   1.64   0.00   0.00   1.00   1.53   0.00   0.00    1.98    2.01    0.00    0.00
size
benchmark   MLton0  MLton1  MLton2  MLton3  MLton4  MLton5  MLton6  MLton7  MLton8  MLton9 MLton10 MLton11 MLton12 MLton13
flat-array 115,692 115,772 118,252 118,460 114,524 114,588 117,836 118,012 114,556 114,620 114,668 114,668 114,140 114,060
compile time
benchmark  MLton0 MLton1 MLton2 MLton3 MLton4 MLton5 MLton6 MLton7 MLton8 MLton9 MLton10 MLton11 MLton12 MLton13
flat-array   2.23   2.17   2.30   2.24   2.28   2.26   2.31   2.26   2.29   2.24    2.33    2.26    2.35    2.29
run time
benchmark  MLton0 MLton1 MLton2 MLton3 MLton4 MLton5 MLton6 MLton7 MLton8 MLton9 MLton10 MLton11 MLton12 MLton13
flat-array  34.93  53.12  53.10  57.36   0.00   0.02  34.84  53.48   0.00   0.02   69.33   70.36    0.00    0.02

Note that the LLVM and C codegens are able to optimize the computation whether or not the DeepFlatten SSA2 optimization is performed.

Presumably, the LLVM and C compilers are able to observe that the sum value is unused and the Vector.foldl loop must terminate.

While it would be simple to "fix" the benchmark by adding a dependency on the sum value (e.g., val _ = if 1105694191 <> sum then raise Fail "bug" else ()), it would be desirable to first capture this optimization via an SSA optimization.

In Word.c, there is a check for round-to-zero integer division behavior. This is no longer necessary with C99, since C99's integer division now matches that of INTEGER in the basis.

The giant architecture check with the error can be eliminated, along with the comment.

I have tried that, but need a mlton for windows :( can someone tell me where to donwload it?

I also tried compile mlton with sml/nj, but it failure:

..\lib\mlton\basic\sources.cm:98.1-98.16 Error: exported structure not defined:
Posix
Makefile:130: recipe for target `smlnj-mlton' failed
make[1]: *** [smlnj-mlton] Error 1
make[1]: Leaving directory `/c/Users/sw/Desktop/mlton-master/mlton'
Makefile:226: recipe for target `smlnj-mlton' failed
make: *** [smlnj-mlton] Error 2

The numeric part of the basis build seems designed with the idea in mind that IntInf should be a perfectly reasonable default integer type. However, that means that vectors are subscripted by integers, and the goal of #60 is to make integers out of vectors. I wanted to discuss how to proceed.

I think the thing to do is to factor out the SeqIndex.int parts of the SEQUENCE signature into a PrimSequence functor and PRIM_SEQUENCE signature, and then add primitive arrays and vectors to the build sequence right after num0.sml. There's the additional problem that we don't have maxLen, geu, or gtu around already at this point; as I currently see it that may require some duplicated code.

While thinking about implementing this I noticed that a lot of sequence operations are defined in terms of slice operations (sub and unsafeSub were the two that surprised me) - is the optimizer able to factor out the apparent cost of pushing those operations through Slice?

In the file

datatype foo = A | B | C | D
datatype bar = X of foo | Y of foo

fun f (X (A | B | C)) = "A"
  | f (Y _) = "B"

I currently get the error message

$ mlton -default-ann 'allowOrPats true' type/foo.sml
Warning: type/foo.sml 4.1.
  Function is not exhaustive.
    missing pattern: (X C)
    in: f (X (A | B | C)) = "A" | f (Y _) = "B"

when it is in fact the X D pattern that's missing.

MLton exposes the equality status of VectorSlice.slice, CharVectorSlice.slice, and Word8VectorSlice.slice.

fun ''a eq (x: ''a, y: ''a) : bool = x = y

val _ : Int.int VectorSlice.slice * Int.int VectorSlice.slice -> bool = eq

val _ : CharVectorSlice.slice * CharVectorSlice.slice -> bool = eq
val _ : Word8VectorSlice.slice * Word8VectorSlice.slice -> bool = eq

For portability with other SML implementations (and conformance with the Basis Library specification), the equality status of polymorphic and monomorphic slices should not be exposed.

The current version string extracted from Git metadata for development builds uses the initial 7 digits of the SHA1 hashes doesn't respect version order (either with respect to public releases or to other development builds).

See discussion at

• https://sourceforge.net/p/mlton/mailman/message/34497064/
• https://sourceforge.net/p/mlton/mailman/message/34503176/
• https://sourceforge.net/p/mlton/mailman/message/34503788/

The regression/real.sml test generally raises an uncaught Fail exception on a test failure, which leads to an unhelpfully large diff when run by the bin/regression script.

MLton exposes the type equality of monomorphic and polymorphic Word8.word arrays and vectors:

fun 'a id (x: 'a) : 'a = x

val _ : Word8Array.array -> Word8.word Array.array = id
val _ : Word8ArraySlice.slice -> Word8.word ArraySlice.slice = id
val _ : Word8Vector.vector -> Word8.word Vector.vector = id
val _ : Word8VectorSlice.slice -> Word8.word VectorSlice.slice = id

For portability with other SML implementations, the type equality of monomorphic and polymorphic Word8.word arrays and vectors should not be exposed.

MLton exposes the type equality of monomorphic and polymorphic Char.char vectors:

fun 'a id (x: 'a) : 'a = x

val _ : CharVector.vector -> Char.char Vector.vector = id
val _ : CharVectorSlice.slice -> Char.char VectorSlice.slice = id

For portability with other SML implementations, the type equality of monomorphic and polymorphic Char.char vectors should not be exposed.

How viable would it be to port MLTon to platforms with an existing GC and runtime system? I am primarily interested in running efficiently compiled SML code on CLR/.NET, and perhaps JavaScript, with some sort of FFI to those platforms.

I understand that MLTon can generate fairly portable C and now LLVM also, so for ex. Emscripten might make just port it to the browser. However looking at, say Gambit-C experiment here:

http://feeley.github.io/gambit-in-the-browser/

It seems that the run-time penalty for "emulated" GC is about 20x. And it probably gets much worse for applications that want to do a lot of FFI back and forth.

Overall, does this sound like developing a backend to a "managed" platform would work, or is the idea totally bogus? Slowdown on the order of 2-10x is perhaps OK. Currently on CLR we use F# which has terrible slowdowns on highly abstract code anyway.

I'm trying to build SML on Stilts. It seems to use the deprecated MLton.Socket structure by calling fdToSock. I know this is deprecated, but why do I get "Undefined structure" when the lib file is present? I have no problem using structures like MLton.Cont.

Also, if I were to use the standard Socket structure, is there something that implements the function of fdToSock? Thanks!

The Asciidoctor project (http://asciidoctor.org) is a new AsciiDoc processor implemented in Ruby. It is significantly faster than the original AsciiDoc processor, supports some extensions (e.g., inter-document cross references), and is used to render AsciiDoc files on GitHub.

When trying to compile a program using '-stop g' or '-stop o', suffixes passed to '-output' are removed.

For example,

mlton -stop g -output my-test.suffix my-test.suffix.sml

emits my-test.0.s my-test.1.c, but it should be emitting my-test.suffix.0.s my-test.suffix.1.c, which it does if I drop the output flag.

mlton -stop g my-test.suffix.sml

=> my-test.suffix.0.s my-test.suffix.1.c

Preserving the suffix is also behavior that the regression test suite depends on: there are several tests of the form <test>.<#>.sml. Because the suffix is dropped in the output, some test programs are overwritten on top of others. You can see this if you run the regression tests like this:

./bin/regression -cross self && ./bin/regression -run-only self

I find out a seemingly different behavior when including a SML and a MLB in the MLBasis. This difference does surprise me a lot. Is it an expected design and has special consideration? I put up source code below.

------------- a1.mlb ------------------------------
t.sml (* define type t )
local
t.sml ( redefine the type t )
a.sml ( define structure A )
in
structure A
end
x.sig ( define signature X )
y.sml ( define structure Y:X = A *)

------------- a2.mlb ------------------------------
t.mlb (* define type t )
local
t.mlb ( redefine the type t )
a.sml ( define structure A )
in
structure A
end
x.sig ( define signature X )
y.sml ( define structure Y:X = A *)

------------- t.mlb ------------------------------
t.sml

When elaborating a1.mlb, an type error is raised.

Error: y.sml 1.15.
Variable type in structure disagrees with signature.
variable: foo
structure: [??? ?.T.t] -> _
signature: ['a typ] -> _
compilation aborted: parseAndElaborate reported errors

But when elaborating a2.mlb, it type checks!! However, I only simply wrap t.sml in t.mlb, and include t.mlb instead in a2.mlb. So it surprises me that the semantic of including a sml and a mlb is different in this case.

Following are content of other source parts.
------------- t.sml ------------------------------
structure T =
struct
datatype 'a t = T of 'a
end

datatype typ = datatype T.t

------------- a.sml ------------------------------
structure A =
struct
fun foo (x: 'a typ) = case x of T x => x
end

------------- x.sig ------------------------------
signature X =
sig
val foo : 'a typ -> 'a
end

------------- y.sml ------------------------------
structure Y : X = A

patch:

--- mlton-20100608~/bin/platform        2010-06-11 13:35:30.000000000 +0000
+++ mlton-20100608/bin/platform 2013-04-18 02:37:26.666395665 +0000
@@ -112,6 +112,9 @@
 powerpc64)
        HOST_ARCH=powerpc64
 ;;
+ppc64)
+        HOST_ARCH=powerpc64
+;;
 powerpc)
         HOST_ARCH=powerpc
 ;;

The Real{32,64}_gdtoa C functions (which support REAL.{fmt,toDecimal,toString} functions) return a (pointer to a) C string, which is then copied to an ML string; this C string is reused by the gdtoa library for successive calls (with some some behind the scenes free/reallocation for very long conversions). However, if a signal arrives between the return from Real{32,64}_gdtoa and the end of the copying from the C string to the ML string and the signal handler directly or indirectly (e.g., by switching ML threads) calls Real{32,64}_gdtoa, then the C string can be reused, causing the first conversion to get characters from the second conversion (at best; at worst, the gdtoa library may have freed the original C string if the second conversion required a larger buffer).

More discussion at: https://sourceforge.net/p/mlton/mailman/message/33677504/

There are a number of number theoretic functions implemented by GMP that would be beneficial to implement and expose as MLton.IntInf.* functions. In particular, lcm (least common multiple) would be useful to implement.

Compile the IntInf_* functions (which call GMP functions) in the runtime system as a separate compilation unit to be archived into libmlton.a. When a compiled program is statically linked to libmlton.a, then if no IntInf_* functions are required to resolve symbols from the compiled program, then the compilation unit could be dropped during linking, and there would be no residual dependency on GMP.

There are two motivations for this enhancement:

• To eliminate the dependency on the LGPL GnuMP library in executables that might be commercially distributed. (IANAL, but there appears to be no legal barrier to commercially distributing MLton compiled executables that depend upon GnuMP, though the license apparently requires that LGPLed components can be "replaced" by the end user, which may be a technical hassle (but not a technical impossibility).)
• To eliminate the dependency on the GnuMP library for executables that might be deployed on platforms without GnuMP or where compiling GnuMP is onerous (e.g., MinGW).

Executables produced by MLton are not quite deterministic, due to the embedding of a random magic constant. This magic constant is meant to protect against using MLton.World.load (or @MLton load-world _world_) with a world saved by a different executable.

MLton follows the Definition and the Basis Library with regards to the definition of string constants. In particular, a string constant must be comprised of zero or more printable characters (character codes 33 through 126), space characters, or escapes. Thus, access to any characters with codes > 126 requires using escape sequences, which is awkward, error prone, and unreadable.

It would be good to extend the "allowExtendedLiterals" annotation to allow string constants to include characters with codes >= 128 directly, which would admit UTF-8 in string constants.

This change would involve modifying bin/platform.

Due to the inconsistency in the static semantics (rule 26) and dynamic semantics (rule 126) in The Definition, MLton rejects rebinding of constructors with val rec declarations, as in:

val rec SOME = fn () => ()

$ mlton z.sml 
Error: z.sml 1.9.
  Constructor can not be redefined by val rec: SOME.
Error: z.sml 1.9.
  Constructor must be used with argument in pattern: SOME.
compilation aborted: parseAndElaborate reported errors

MLton should also reject rebinding of constructors with fun declarations, as in:

fun SOME () = ()

Reported by Florian Weimer.

Cannot compile on OS X 10.10. Using SMLNJ to compile mlton (make smlnj-mlton), but get this error:

Standard ML of New Jersey v110.76 [built: Sun Aug 24 10:45:00 2014]
- [autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[autoloading done]
val it = () : unit
[autoloading]
[library $smlnj/cm/cm.cm is stable]
[library $smlnj/internal/cm-sig-lib.cm is stable]
[library $/pgraph.cm is stable]
[library $smlnj/internal/srcpath-lib.cm is stable]
[autoloading done]
val it = () : unit
val it = () : unit
val it = () : unit
front-end/ml.grm.sml:1859.25-1859.42 Error: unbound structure: General in path General.Subscript
front-end/ml.grm.sml:1859.25-1859.42 Error: variable found where constructor is required: General.Subscript
front-end/ml.grm.sml:1869.19-1869.60 Error: operator and operand don't agree [tycon mismatch]
  operator domain: 'Z list * ('Z -> 'Y)
  operand:         int -> (term,action) pairlist * action
  in expression:
    List.map actionRowLookUp
make: *** [smlnj-mlton] Error 1

Hey guys,

trying to just get started hacking a bit and can't figure out how to include multiple files in the same binary build.

Is there an example in the documentation anywhere where two or more files are combined in a meaningful way?

All I found was this (http://mlton.org/MLBasisExamples) which seems more for writing libraries.

Many thanks!

MLton currently is not capable of using multiple CPU cores. However, MultiMLton is. I suggest that MultiMLton be merged into the mainline MLton repo.

This will also give MLton a big advantage over the (multicore-incapable) OCaml.

The expression CPointer_equal(NULL, NULL) is not optimized to true. This should be a simple addition to the allConsts function of mlton/atoms/prim.fun.

See discussion at https://sourceforge.net/p/mlton/mailman/message/34493424/.

To make MLton easier for users, it would be nice if build and run-time instructions were included on the README displayed when viewing the repository. Thanks!

Hi,

Are there any plans to have toplevel similar to ocaml/sml-nj in mlton?

Bikal.

Resolving issue #59 would eliminate the dependency on GMP for compiled programs that do not use structure IntInf. However, there may be programs that use structure IntInf in a non-performance critical way or that indirectly use structure IntInf (e.g., by using structure Time, where time values are implemented using IntInf.int), but would like to avoid the dependency on GMP.

It should be possible to provide an alternative implementation of the IntInf_* primitives in SML. Then use a command line flag -int-inf-impl {gmp,sml} (similar in spirit to the -default-type type flag) which would (among other effects) define an MLB path variable (again, similar to what is done with the -default-type type flag) that would be used to select an appropriate implementation of the IntInf_* primitives for use in the rest of the Basis Library.

It would clearly be less performant than the GMP implementation, but it would probably suffice for many applications where structure IntInf was used, but not used extensively.

Compiling the FFI sample as described in http://mlton.org/CallingFromSMLToC gives the following compile error,

ffi-import.c
ffi-import.c:4:1: error: unknown type name ‘Int32’
 Int32 FFI_INT = 13;

I am using the following command to compile,
mlton -default-ann 'allowFFI true' import.sml ffi-import.c

Is there something that I am missing?

If I am building a 32-bit mlton on a machine that has >6GB of physical ram, then the default ram-slop of 0.7 seems to cause mlton to allocate more than 4GB of heap and fail. This is because there is no address-space heap cap.

I think there should be some way the heap allocator should detect address space exhaustion or at least cap the max ram selection at init time.

The following program when compiled and run with no command-line options prints "That's bad". The constant "three" exists at runtime as a pointer (the Big representation) but the numeric operations then provide checks that return it to the correct Small representation.

structure I = MLton.IntInf
val bigthree = Vector.fromList (List.map I.BigWord.fromInt [0,3])
val three = valOf (I.fromRep (I.Big bigthree))
val () = if three = three + 1 - 1
         then print "That's good\n"
         else print "That's bad\n"

The solution is probably to add a check at

(The existence of fromRep and toRep are a little bit annoying for a good resolution of #59 and #60, incidentally, and the easy solution might be for MLton.IntInf.rep and MLton.IntInf.fromRep to raise Domain in the non-GMP implementation.)

I was trying out the opengl libraries in mltonlib/org/mlton/mike/opengl/unstable
but most executables segfault
under current master 22f61a4

The executables run fine with the MLton 20130715 release,
so it seemed like it might be a compiler regression...
I could bisect it if that would help & its not already something known

otherwise if it is actually a problem with mltonlib
let me know and i'll post it in the appropriate place

(gdb) bt
#0 returnAddressToFrameIndex (ra=16)

at /home/ratmice/git/mlton/install/usr/lib/mlton/include/amd64-main.h:35

#1 0x000000000042040f in GC_switchToThread ()
#2 0x00000000004022c3 in MLton_callFromC () at hello.1.c:702
#3 0x000000000040286d in glutDisplayFuncArgument () at hello.1.c:220
#4 0x00007ffff7d9e114 in fghcbDisplayWindow () from /lib64/libglut.so.3
#5 0x00007ffff7da1a39 in fgEnumWindows () from /lib64/libglut.so.3
#6 0x00007ffff7d9e72d in glutMainLoopEvent () from /lib64/libglut.so.3
#7 0x00007ffff7d9ef20 in glutMainLoop () from /lib64/libglut.so.3
#8 0x0000000000407867 in L_176 ()
#9 0x0000000000000001 in ?? ()
#10 0x0000000000402140 in fwrite@plt ()
#11 0x0000000000000000 in ?? ()

#82 introduced the _import attributes pure, impure, and runtime to reduce the overhead of calling the typical _import-ed function: an impure function that does not enter the MLton runtime. The behavior of an unattributed _import is to treat it as impure.

This has one small regression with respect to _import-ed functions that call _export-ed functions. An _import-ed function that re-enters SML indirectly invokes runtime services (e.g., garbage collection); therefore, after the return from SML and the return from C, the global GC state must be reloaded (frontier, stack top, ...).

We should introduce a reentrant _import attribute for such functions. Functionally, it will behave identically to the runtime attribute, but whereas runtime should be a private undocumented attribute for compiler developers, the reentrant attribute should be a public documented attribute for users. Subsequently, the two attributes may diverge (e.g., a runtime _import should almost certainly require a reference to the global GC state, and we may statically check that such an argument is passed, whereas a reentrant _import should never require a reference to the global GC state).

Commit 2fdba82 breaks the MinGW build.

With #50 fixed, MLton will generate a deterministic executable (for a given compiler, input program, and compile-time options). However, due to embedding the build date and build node into the version banner, a self-compile is not deterministic. Some platforms value reproducible builds (e.g., https://wiki.debian.org/ReproducibleBuilds).

On Arch Linux:

This was actually two errors, it was not able to find -lgdtoa, but I was able to solve it by creating a new symbolic link from /usr/local/lib/libgdtoa.so to the gdtoa shared library.
ln --verbose -lmlton, I get:

attempt to open /usr/x86_64-unknown-linux-gnu/lib64/libmlton.so failed
attempt to open /usr/x86_64-unknown-linux-gnu/lib64/libmlton.a failed
attempt to open /usr/x86_64-unknown-linux-gnu/lib/libmlton.so failed
attempt to open /usr/x86_64-unknown-linux-gnu/lib/libmlton.a failed
attempt to open /usr/lib/libmlton.so failed
attempt to open /usr/lib/libmlton.a failed
attempt to open /usr/local/lib/libmlton.so failed
attempt to open /usr/local/lib/libmlton.a failed
ld: cannot find -lmlton

I was able to solve the missing gdtoa missing lib with a symbolic link: ln -s /usr/lib/libdouble-conversion.so /usr/lib/libgdtoa.so, so I expect an equally simple fix for mlton. However when I tried: ln -s /usr/lib/mlton/static-library /usr/lib/libmlton.so, I got the error: /usr/lib/libmlton.so: file not recognized: File format not recognized So maybe there should be another file somewhere that I should link, but I'm not sure which.

Currently the C, x86, and amd64 codegens all implement REAL.*+ and REAL.*- as a multiplication followed by an addition/subtraction. The forthcoming LLVM codegen implement REAL.*+ using the @llvm.fma intrinsic, which conforms to (and compiles to) C99's fma{f,} function.

I'm unable to build 728e2a5 on my system and lack the proper knowledge to resolve my own issue. To help you help me, I've included some output that seems relevant.

sw_vers

ProductName:    Mac OS X
ProductVersion: 10.11
BuildVersion:   15A284

gcc -v

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.0 (clang-700.0.72)
Target: x86_64-apple-darwin15.0.0
Thread model: posix

make -v

GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-apple-darwin11.3.0

sml (installed via Homebrew)

Standard ML of New Jersey v110.78 [built: Wed Sep 23 17:33:30 2015]

brew info smlnj

smlnj: stable 110.78 (bottled)
Standard ML of New Jersey
http://www.smlnj.org/
/usr/local/Cellar/smlnj/110.78 (6581 files, 86M) *
  Poured from bottle
From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/smlnj.rb

make smlnj-mlton

...
defunctorize/defunctorize.fun:332.13-352.22 Error: unresolved flex record
   (can't tell what fields there are besides #lay)
make[1]: *** [smlnj-mlton] Error 1
make: *** [smlnj-mlton] Error 2

N.B. The ... above includes 10x mlton: Command not found.

Does anybody out there have any tips? Thanks for your time!

Current version of CiteSeer breaks old links.

After resolving #88, should document the new _import attributes in the guide.

On Fri, 11 Apr 2014, John Reppy wrote:

I've been working on a new version of the SML3d library (based on the programmable
core profile) and there is a feature that would greatly reduce the size of the C/ML
interface. For a C function like

void glDrawElements (GLenum, GLsizei, GLenum, void *);

I generate multiple wrappers where the fourth parameter type is specialized to
various different array and vector types:

val glDrawElements = _import "glDrawElements" stdcall : (glenum * glsizei * glenum * MLton.Pointer.t) -> unit;
val glDrawElementsArrub = _import "glDrawElements" stdcall : (glenum * glsizei * glenum * Word8.word array) -> unit;
val glDrawElementsArrui = _import "glDrawElements" stdcall : (glenum * glsizei * glenum * Word32.word array) -> unit;
val glDrawElementsArrus = _import "glDrawElements" stdcall : (glenum * glsizei * glenum * Word16.word array) -> unit;
val glDrawElementsVecub = _import "glDrawElements" stdcall : (glenum * glsizei * glenum * Word8.word vector) -> unit;
val glDrawElementsVecui = _import "glDrawElements" stdcall : (glenum * glsizei * glenum * Word32.word vector) -> unit;
val glDrawElementsVecus = _import "glDrawElements" stdcall : (glenum * glsizei * glenum * Word16.word vector) -> unit;

What I would like are functions in Unsafe.Vector and Unsafe.Array to cast vector and array types to pointers.

val toPtr : 'a Vector.vector -> MLton.Pointer.t
val toPtr : 'a Array.array -> MLtonPointer.t

For completeness, it would be good to have these on the monomorphic vector and array types too.

The source file

signature S =
sig
  datatype 'a item =
      Unit of 'a
    | Paren of 'a seq
  withtype 'a seq = 'a item list
end

yields an internal compiler error (during elaboration):

[matthew@shadow zzz]$ mlton -stop tc -default-ann 'allowSigWithtype true' z.sml 
Interface.Type.substitute

On OS X 10.9.4 using SML/NJ (110.77), a make smlnj-mlton results in the following error:

front-end/ml.grm.sml:1859.25-1859.42 Error: unbound structure: General in path General.Subscript
front-end/ml.grm.sml:1859.25-1859.42 Error: variable found where constructor is required: General.Subscript
front-end/ml.grm.sml:1869.19-1869.60 Error: operator and operand don't agree [tycon mismatch]
  operator domain: 'Z list * ('Z -> 'Y)
  operand:         int -> (term,action) pairlist * action
  in expression:
    List.map actionRowLookUp

Don't have access to another Unix machine to try this out on, might give Cygwin a whirl.

With the SourceForge outage taking out mlton.org, the web-based wiki is inaccessible. It would be nice to have at least mlton.github.io set up during this time, pointing to the asciidoc files in the repository. mlton.org could also be reworked to use github for serving the wiki.

There's a bug in the smlnj lib in splay sets, mlton/sml/smlnj-lib/Util/splay-set-fn.sml:

fun all p EMPTY = false
  | all p (SET{root,...}) = let
      fun all' SplayNil = false
        | all' (SplayObj{value=v,left=l,right=r}) = all' l andalso p v andalso all' r
      in
        all' (!root)
      end

The base case should be true. I submitted a bug report to smlnj, but I'm wondering how this change can make it into mlton. Could I submit a patch file?

Looks like a fix like
http://www.mpfr.org/mpfr-3.1.0/patch08
is needed.

DEBUG: In file included from gc.c:44:0:
DEBUG: gc/int-inf.c: At top level:
DEBUG: gc/int-inf.c:180:43: error: unknown type name '__gmp_const'
DEBUG:                                            __gmp_const __mpz_struct *lhsspace,
DEBUG:                                            ^
DEBUG: gc/int-inf.c:181:43: error: unknown type name '__gmp_const'
DEBUG:                                            __gmp_const __mpz_struct *rhsspace)) {
DEBUG:                                            ^
DEBUG: gc/int-inf.c: At top level:
DEBUG: gc/int-inf.c:257:34: error: unknown type name '__gmp_const'
DEBUG:                                   __gmp_const __mpz_struct *argspace)) {
DEBUG:                                   ^

Steps to reproduce:

• Unpack mlton-20130715
• cd mlton-20130715
• gmake

Please contact me if any additional info is required.

gcc -std=gnu99   -fno-common  -pedantic -Wall -Wextra -Wformat=2 -Wswitch-default -Wswitch-enum -Wuninitialized -Winit-self -Wstrict-aliasing=2 -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-field-initializers -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -fvisibility=hidden -m64 -I/usr/local/include -I. -Iplatform -Wdisabled-optimization -O2 -fomit-frame-pointer  -c -o platform/openbsd.o platform/openbsd.c
In file included from ./cenv.h:45,
                 from ./platform.h:13,
                 from platform/openbsd.c:1:
/usr/include/signal.h:72: warning: redundant redeclaration of '__errno'
/usr/include/errno.h:54: warning: previous declaration of '__errno' was here
In file included from ./platform/openbsd.h:4,
                 from ./cenv.h:92,
                 from ./platform.h:13,
                 from platform/openbsd.c:1:
/usr/include/unistd.h:368: warning: redundant redeclaration of 'lseek'
/usr/include/sys/types.h:216: warning: previous declaration of 'lseek' was here
/usr/include/unistd.h:404: warning: redundant redeclaration of 'ftruncate'
/usr/include/sys/types.h:217: warning: previous declaration of 'ftruncate' was here
/usr/include/unistd.h:423: warning: redundant redeclaration of 'mkstemp'
/usr/include/stdlib.h:212: warning: previous declaration of 'mkstemp' was here
/usr/include/unistd.h:424: warning: redundant redeclaration of 'mktemp'
/usr/include/stdlib.h:180: warning: previous declaration of 'mktemp' was here
/usr/include/unistd.h:426: warning: redundant redeclaration of 'setkey'
/usr/include/stdlib.h:197: warning: previous declaration of 'setkey' was here
/usr/include/unistd.h:431: warning: redundant redeclaration of 'truncate'
/usr/include/sys/types.h:218: warning: previous declaration of 'truncate' was here
/usr/include/unistd.h:511: warning: redundant redeclaration of 'mkdtemp'
/usr/include/stdlib.h:252: warning: previous declaration of 'mkdtemp' was here
/usr/include/unistd.h:512: warning: redundant redeclaration of 'mkstemps'
/usr/include/stdlib.h:294: warning: previous declaration of 'mkstemps' was here
platform/openbsd.c: In function 'catcher':
platform/openbsd.c:14: error: 'ucontext_t' has no member named 'sc_eip'
Makefile:357: recipe for target 'platform/openbsd.o' failed
gmake[3]: *** [platform/openbsd.o] Error 1
gmake[3]: Leaving directory '/home/a/Projects/mlton-20130715/runtime'
Makefile:196: recipe for target 'runtime' failed
gmake[2]: *** [runtime] Error 2
gmake[2]: Leaving directory '/home/a/Projects/mlton-20130715'
Makefile:61: recipe for target 'all-no-docs' failed
gmake[1]: *** [all-no-docs] Error 2
gmake[1]: Leaving directory '/home/a/Projects/mlton-20130715'
Makefile:57: recipe for target 'all' failed
gmake: *** [all] Error 2