kfl / mosml Goto Github PK

Dear mosml team,

I followed the instructions found in the install.txt and extracted the version downloaded from Git (here). But after extracting, my bin and lib folders seems to be empty.

What could be the reason?

Note: I couldn't extract using the command line option, which raised the following error. Hence I extracted using gui.

$ gzip -dc mosml-master.zip | tar xfv -
gzip: mosml-master.zip has more than one entry--rest ignored
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

I have downloaded the newest snapshot of MosML, but make world fails when trying to link camlrunm:

ld -o camlrunm prims.o interp.o expand.o misc.o stacks.o fix_code.o main.o fail.o signals.o freelist.o major_gc.o minor_gc.o memory.o alloc.o roots.o compare.o ints.o floats.o str.o io.o extern.o externcp.o intern.o interncp.o hash.o sys.o meta.o parsing.o lexing.o gc_ctrl.o mosml.o unix.o runtime.o md5sum.o callback.o dynlib.o -lm -ldl
ld: cannot find -ldl

The SML Basis library specifies Int64 and Word64 structures. These are really handy and it would be swell if MosML supported them.

Due to a change in GNU malloc, Moscow ML may crash on 64 bit architectures as well as on those 32 bit architectures that use glibc 2.7.

Originally reported by HOL developers

Compiling mmysql.c using mmysql's Makefile fails with this error:

mmysql.c: In function ‘dbresult_finalize’:
mmysql.c:79:28: error: lvalue required as left operand of assignment
     DBresult_val(dbresval) = NULL;
                            ^
mmysql.c:81:33: error: lvalue required as left operand of assignment
     DBresultindex_val(dbresval) = NULL;
                                 ^

This is the function in question:

mosml version: 2.10.1
libmysqlclient version: 5.7.21
Compiler: gcc 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
OS: Ubuntu 18.04.2

According to the documentation for OS.FileSys.tmpName, it should create a new temporary file:

This creates a new empty file with a unique name and returns the full pathname of the file. The named file will be readable and writable by the creating process, but, if the host operating systems supports it, not accessible by other users. This function can be used to create a temporary file that will not collide with other applications.

From: http://sml-family.org/Basis/os-file-sys.html#SIG:OS_FILE_SYS.tmpName:VAL

It seems like we are using tmpnam(3), which is deprecated, exactly because it doesn't actually create the file, but merely returns a suitable filename for a temporary file. This could lead to security issues.

Since August, SML/NJ uses mkstemp (at least on newer systems where it is supported) such that a file is actually created.

SML/NJ implementation: http://smlnj-gforge.cs.uchicago.edu/scm/viewvc.php/sml/trunk/runtime/c-libs/posix-os/tmpname.c?view=markup&root=smlnj

can i know how to install mosml on ubuntu?

jeremy@jasco:/mnt/local/mosml/src/test$ make
rm -f result
mosml -P full test.sml > result 2>&1
hangs, due to
jeremy@jasco:/mnt/local/mosml/src/test$ vi result
File "ovlsucc.sml", line 98, characters 52-54:
! fun maxi ar = Array.foldli f (0,Array.sub(ar,0)) ar
! ^^
! Type clash: expression of type
! 'a array
! cannot have type
! 'a array * int * int option
[closing file "ovlsucc.sml"]
[closing file "test.sml"]

I note that
Moscow ML version 2.10
Enter `quit();' to quit.

• Array.foldli ;

  val ('a, 'b) it = fn : (int * 'a * 'b -> 'b) -> 'b -> 'a array -> 'b
  but
  Moscow ML version 2.01 (January 2004)
  Enter `quit();' to quit.

• Array.foldli ;

  val ('a, 'b) it = fn :
  (int * 'a * 'b -> 'b) -> 'b -> 'a array * int * int option -> 'b

MosML elaborates the following code:

fun f x x = x;

as

> val ('a, 'b) f = fn : 'a -> 'b -> 'b

which does not conform to the Definition of SML'97. In particular, the code should simplify to

val rec f = fn vid1 => fn vid2 => case (vid1, vid2) of (x, x) => x;

which is in turn rejected by MosML with the following error message:

! Toplevel input:
! val rec f = fn vid1 => fn vid2 => case (vid1, vid2) of (x, x) => x;
!                                                        ^
! Illegal rebinding of x: the same value identifier is bound twice in a pattern

(Tested with version 2.10 on Arch Linux)

When you use %Zin the format string to Date.fmt you get random garbage:

- load"Date";
> val it = () : unit
- Date.fmt "%a %d %b %Y %Z" (Date.fromTimeLocal (Time.now()));
> val it = "Wed 09 Jun 2010 ???r" : string

(Collateral bug from issue originally reported by Michael Norrish)

I think it's pretty clear that the Basis library says this should be a signed infinity value.

- 3.0 / 0.0;
! Uncaught exception:
! Div

After doing a make install, the include/config.h #includes incorrect paths:

Lines 13-18:

 #if defined(msdos)
 #include "../config.dos/m.h"
 #include "../config.dos/s.h"
 #elif defined(WIN32)
 #include "../config.w32/m.h"
 #include "../config.w32/s.h"

The config.dos and config.w32 directories only exist in the src/ folder, so the relative path is incorrect after the installation.

Hi, I have successfully built mosml after git clone. But after installing with:

$ DESTDIR=/tmp/mosml-install make install

if I try to execute mosml in that directory:

$ /tmp/mosml-install/usr/local/bin/mosml
/tmp/mosml-install/usr/local/bin/mosml: 11: exec: /usr/local/bin/camlrunm: not found

it gives me an error saying that camlrunm is not found.

I guess the path to camlrunm is hard-coded into mosml because camlrunm is installed to the same directory $DESTDIR/usr/local/bin/ as mosml.

I've rebuilt mosml compiler with cd src; make world; cd compiler; make promote; make clean; make promote, on two different systems: ALT Linux/AMD64, Debian/mipsel32. md5sums of src/mosmlcmp were different, which is really surprising. I have also 64-bit SPARC machine, which, unfortunately can't compile camlrunm yet (but it looks like I can fix it).

Do you know why md5 sums were different?

Currently the TODO contains lots of issues, maybe (some of) these should be triaged and entered into github issues.

The code

load "Time";
Time.fmt ~1 (Time.now());

should raise the Size exception, but does not in Moscow ML. The simple fix is to change lines 37-38 of Time.sml to

fun fmt p r = Real.fmt (StringCvt.FIX (SOME p)) (r/1000000.0);

since Real.fmt raises Size on invalid precision specifications.

A better fix is

fun fmt p = if (p < 0)
      then raise Size
      else (fn r => Real.fmt (StringCvt.FIX (SOME p)) (r/1000000.0))

since it is consistent with how Real.fmt treats invalid format specifications.

By analogy with PolyML.Compiler.compilerVersionNumber in Poly/ML.

If one is writing code that you want to run on different systems, it is nice to know just what system one is running on when setting up things like compiles etc. I'd prefer not to have to use configure shell-scripts if the ML system itself could tell me what it was capable of from within the language.

The installer link on mosml.org, https://github.com/kfl/mosml/releases/download/ver-2.10.1/mosml-setup-2.10.1.exe, leads to a 404 page.

Possibly related to #44.

When attempting to do a make on Ubuntu x64, the compilation fails with the message:

../camlrunm ../mosmlcmp -stdlib ../mosmllib -P none  Types.sml
! File ../mosmllib/Misc.ui contains the signature of unit Misc
! instead of the signature of unit Misc

Output of uname -a: Linux phantasos 2.6.35-28-generic #50-Ubuntu SMP Fri Mar 18 18:42:20 UTC 2011 x86_64 GNU/Linux

Output of gcc -v:

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) 

Output of make and the Makefile.inc: https://gist.github.com/1051382

Currently, real is an eqtype which it shouldn't be, according to the SML Standard (see Appendix C). In particular, the following code should fail to elaborate:

1.0 = 1.0;
fn x => x = 1.0;

Further, the current equality on real does not work too well (as one would expect, I'd say):

Moscow ML version 2.10
Enter `quit();' to quit.
- 1.0000000000000001 = 1.0;
> val it = true : bool

- 1.0000000000000001;
> val it = 1.0 : real

Here's an example of a non-exhaustive pattern in Moscow ML:

- fun foo (x::xs) = xs;
! Toplevel input:
! fun foo (x::xs) = xs;
!     ^^^^^^^^^^^^^^^^
! Warning: pattern matching is not exhaustive

Here's an example of the same non-exhaustive pattern in OCaml:

# let foo (x::xs) = xs;;
Warning P: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
[]
val foo : 'a list -> 'a list = <fun>

It'd be quite nice if Moscow ML, similarily to this, gave an example of an unmatched pattern.

Trying to run make in the msocket directory yields the following output:

$ make
ld -shared -o libmsocket.so msocket.o
msocket.o: In function `msocket_newinetaddr':
msocket.c:(.text+0x823): undefined reference to `__stack_chk_fail_local'
msocket.o: In function `msocket_accept':
msocket.c:(.text+0xa21): undefined reference to `__stack_chk_fail_local'
msocket.o: In function `msocket_bind':
msocket.c:(.text+0xad8): undefined reference to `__stack_chk_fail_local'
msocket.o: In function `msocket_connect':
msocket.c:(.text+0xb88): undefined reference to `__stack_chk_fail_local'
msocket.o: In function `msocket_sendto':
msocket.c:(.text+0xe28): undefined reference to `__stack_chk_fail_local'
msocket.o:msocket.c:(.text+0xff8): more undefined references to `__stack_chk_fail_local' follow
ld: libmsocket.so: hidden symbol `__stack_chk_fail_local' isn't defined
ld: final link failed: Bad value
make: *** [libmsocket.so] Error 1

Some info:

$ uname -a
Linux philip-VirtualBox32bit 3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00:19:35 UTC 2013 i686 i686 i686 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 13.04
Release: 13.04
Codename: raring
$ gcc --version
gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
Copyright (C) 2012 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.

The code around

http://github.com/kfl/mosml/blob/master/src/runtime/str.c#L82

hardcodes the LC_TYPE possibilities and assume that a non-iso-8859-1 encoding is a non-iso charset. There are several subtle problems with this choice.

First of all, utf-8 might be used. Second, iso-8859-15 is also in use at several places. I hypothesize that the current solution will lead to subtle bugs.

The implementation of Date does not handle time zones correctly in all cases. Example:

- Date.fmt "%H:%M %Z" (Date.fromTimeUniv (Time.now()));
> val it = "15:20 CET" : string

I believe CET ought to be GMT or UTC.

If the system's default make is not GNU make(in *BSD systems), 'make' is different from '$(MAKE)' and does not work with GNU make's makefile.
Thanks.

After using the fix mentioned in the sibling issue, make world can proceed to this far more exciting error:

ld -o camlrunm prims.o interp.o expand.o misc.o stacks.o fix_code.o main.o fail.o signals.o freelist.o major_gc.o minor_gc.o memory.o alloc.o roots.o compare.o ints.o floats.o str.o io.o extern.o externcp.o intern.o interncp.o hash.o sys.o meta.o parsing.o lexing.o gc_ctrl.o mosml.o unix.o runtime.o md5sum.o callback.o dynlib.o -lm 
interp.o(.text+0x1c): In function `interprete':
: undefined reference to `__guard_local'
ld: final link failed: Bad value

I'm trying to build mosml on OSX. But there's no <malloc.h> file on my system.

There is a <malloc/malloc.h> and a <sys/malloc.h>.

If you go to http://mosml.org/mosmllib/ and click on the Misc link under all structures, it leads to http://mosml.org/mosmllib/Misc.html, which returns a 404

I wrote this code in MacOS X 10.9.5 using mosml 2.10 installed from pkg file.

$ rlwrap mosml
Moscow ML version 2.10
Enter `quit();' to quit.
- load "IntInf";
> val it = () : unit
- IntInf.fromInt 1 = IntInf.fromInt 1;
! Toplevel input:
! IntInf.fromInt 1 = IntInf.fromInt 1;
! ^^^^^^^^^^^^^^^^
! Type clash: expression of type
!   int/1
! cannot have equality type ''a
-

According to the basis library document
(http://sml-family.org/Basis/int-inf.html#section:0),
signature INT_INF includes INTEGER, and INTEGER has eqtype int.
So, I should write like "IntInf.fromInt 1 = IntInf.fromInt 1" using comparison operators.
Could you show me why IntInf is not eqtype, please?

Sorry for my poor english. Thank you.

It would be nice to have PackRealLittle as documented here: https://smlfamily.github.io/Basis/pack-float.html

Probably needs #62 to be implemented first.

PackReal32Little and PackReal64Little would also be useful, except that MosML does not have Real32.

make fails with the following:

/usr/bin/x86_64-linux-gnu-ld: expand.o: relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/x86_64-linux-gnu-ld: callback.o: relocation R_X86_64_32S against undefined symbol `first_atoms' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/x86_64-linux-gnu-ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
Makefile:37: recipe for target 'camlrunm' failed
make[1]: *** [camlrunm] Error 1
make[1]: Leaving directory '/home/athas/mosml/src/runtime'
Makefile:19: recipe for target 'world' failed
make: *** [world] Error 2

Things seem to work if I just jam CFLAGS=-fPIC into Makefile.inc. I don't know if there is a better way to handle this.

Moscow ML appears to be lacking the structure Text (and matching signature TEXT) required by the basis library standard. (Table 2.2 in "The Standard ML Basis Library")

The signature is also available here.

Make installers for Linux, OS-X and Windows and put them on the homepage.

The mosml installer (pkg) installs its files in a directory (/usr/local), which is used for Homebrew. This needs to be changed, so brew doctor doesn't complain about unexpected header files and to avoid possible problems with other software.

Please use /usr instead.

Trying to compile the following file:

test.sml:

val _ = print (Int.toString (foldl (op*) 1 [2,4,5]))

gives me:

$ mosmlc test.sml
File "test.sml", line 1, characters 38-40:
! val _ = print (Int.toString (foldl (op*) 1 [2,4,5]))
!                                       ^^
! Lexical error: unmatched comment bracket.

If I insert a space after the asterix, MosML will compile the file as well.

I understand that there's som ambiguity here, since *) looks an awful lot like the end of a comment, but I can see that mlton compiles the same file without any troubles.

Is this the desired behavior for MosML?

None of the man pages are installed by src/Makefile. Is that the intended behavior?

src/Makefile.inc defines MANDIR, but it is not used elsewhere.

When cross-compiling Moscow ML for Windows, mosmllex is left in two parts: header.exe and mosmllex. The old .w32 Makefile suggests that this is fixed by concatenating the two files into mosmllex.exe. Ideally, the cross_w32 Makefile directive should perform this concatenation.

The content of the Mantis bugtracker I set up for Moscow ML at: http://friislarsen.net/mosmlmantis should be transfered to the issue tracker at github.

Open question, should only open bugs be transferred, or should closed bugs be transferred as well for the sake of history?

When trying to install mosml (2.00, 2.01, or 2.10.1) macOS Big Sur 11.2.2 from sources, I get:

make world

cd config; /Applications/Xcode.app/Contents/Developer/usr/bin/make all

sh autoconf gcc

Checking the sizes of integers and pointers...

This architecture seems to be neither 32 bits nor 64 bits.

Caml Light won't run on this architecture.

make[1]: *** [runtime] Error 2

make: *** [world] Error 2

Moscow ML seems to be applying functions the Caml way, rather than what is called for in the Definition of Standard ML. The manual says to report this deviation as a bug. For me, it's a show-stopping bug.

Example source code:

structure S = struct
  fun shout_then_apply f = (print "Shouting.\n"; f)
  fun id x = x
  val _ = shout_then_apply id (print "Evaluating second argument.\n")
end

The standard says that the first print should be called when shout_then_apply is applied to id, which is before the second print is evaluated. But that's not what mosml does:

For comparison, here's output from MLton:

nr@homedog ©152/g/textbook> mosmlc -toplevel -o a mosmlbug.sml
nr@homedog ©152/g/textbook> ./a
Evaluating second argument.
Shouting.
nr@homedog ©152/g/textbook> mlton -output b mosmlbug.sml
nr@homedog ©152/g/textbook> ./b
Shouting.
Evaluating second argument.
nr@homedog ©152/g/textbook> 

Standard ML of New Jersey also gets the evaluation order right.

For me, this is a show-stopping bug---is there any chance of getting it fixed?

McAfee on my corporate windows test machine sees the download as Artemis!909EB37BCC9E

$ sudo add-apt-repository ppa:kflarsen/mosml
[sudo] password for athas: 
 Moscow ML is a light-weight implementation of Standard ML (SML), a strict functional language widely used in teaching and research. http://mosml.org

 More info: https://launchpad.net/~kflarsen/+archive/ubuntu/mosml
Press [ENTER] to continue or Ctrl-c to cancel adding it.

...

E: The repository 'http://ppa.launchpad.net/kflarsen/mosml/ubuntu bionic Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

$ sudo apt-get update
...
Err:18 http://ppa.launchpad.net/kflarsen/mosml/ubuntu bionic Release                                                                                                     
  404  Not Found [IP: 91.189.95.83 80]

I am using Ubuntu 18.04 LTS on x86-64.

Also, the light grey text on mosml.org is extremely hard to read on the white background.

Problem 1: For some reason, ../../config/m.h is not included:

~/Projects/mosml/src/dynlibs/msocket $ make
gcc -Dunix -O2 -fno-defer-pop -fPIC -I../../runtime -c -o msocket.o msocket.c
In file included from ../../runtime/mlvalues.h:5:0,
                 from msocket.c:32:
../../runtime/config.h:4:15: fatal fejl: m.h: Ingen sådan fil eller filkatalog
 #include "m.h"
               ^
oversættelse afsluttede.
make: *** [msocket.o] Fejl 1

Adding -I../../config to https://github.com/kfl/mosml/blob/Rel-2.10/src/dynlibs/msocket/Makefile#L10 fixes this temporarily, but you probably want to refer to this directory differently.

Problem 2: When I make install, it copies libmsocket.so wrongly into my library directory:

~/Projects/mosml/src/dynlibs/msocket $ make install
cp libmsocket.so /home/simon/mosml/lib/mosml

Now, the issue isn't that it ends up in a subdirectory in lib/ -- this, I'm sure, is just a preference -- but since I don't have a directory called mosml/, libmsocket.so ends up being called mosml!

~/mosml/lib $ file mosml
mosml: ELF 64-bit LSB  shared object, x86-64 [...]

https://github.com/kfl/mosml/blob/Rel-2.10/src/dynlibs/msocket/Makefile#L10 should probably be fixed so it at least ensures that it lands in that directory and not as the directory.

Debian/Ubuntu mosml packages put examples into /usr/share/doc/mosml/examples/examples with double examples in the path.

So far I've run into two issues.

The first is that autoconf gets stuck in an infinite loop when trying to determine the alignment constraints. The script works fine if I comment out the code for that and just add echo "#define ALIGNMENT" >> m.h.

The second comes while running make world. The build fails with:

make[2]: Entering directory '/home/cory/Downloads/kfl-mosml-96407bc/src/dynlibs/intinf'
gcc -Dunix -O3   -I../../runtime -I/usr/local/include -c -o intinf.o intinf.c
ld -shared -o libmgmp.so intinf.o -L/usr/local/lib -lgmp -lc
intinf.o:intinf.c:(.text+0x29): undefined reference to `adjust_gc_speed'
intinf.o:intinf.c:(.text+0x54): undefined reference to `adjust_gc_speed'
intinf.o:intinf.c:(.text+0xc3): undefined reference to `alloc_final'
intinf.o:intinf.c:(.text+0xec): undefined reference to `first_atoms'
intinf.o:intinf.c:(.text+0x154): undefined reference to `alloc_final'
intinf.o:intinf.c:(.text+0x1c4): undefined reference to `alloc_final'
intinf.o:intinf.c:(.text+0x20f): undefined reference to `first_atoms'
intinf.o:intinf.c:(.text+0x23e): undefined reference to `first_atoms'
intinf.o:intinf.c:(.text+0x278): undefined reference to `raiseprimitive0'
intinf.o:intinf.c:(.text+0x2ba): undefined reference to `first_atoms'
intinf.o:intinf.c:(.text+0x2ea): undefined reference to `first_atoms'
intinf.o:intinf.c:(.text+0x32a): undefined reference to `first_atoms'
intinf.o:intinf.c:(.text+0x36a): undefined reference to `first_atoms'
intinf.o:intinf.c:(.text+0x3aa): undefined reference to `first_atoms'
intinf.o:intinf.c:(.text+0x3ea): more undefined references to `first_atoms' follow
intinf.o:intinf.c:(.text+0x5ed): undefined reference to `failwith'
intinf.o:intinf.c:(.text+0x5f5): undefined reference to `first_atoms'
intinf.o:intinf.c:(.text+0x662): undefined reference to `copy_string'
intinf.o:intinf.c:(.text+0x6b9): undefined reference to `first_atoms'
intinf.o:intinf.c:(.text+0x3b): undefined reference to `stat_resize'
intinf.o:intinf.c:(.text+0x61): undefined reference to `stat_alloc'
/usr/lib/libc.a(t-d001045.o):fake:(.text+0x2): undefined reference to `_imp__free'
/usr/lib/libc.a(t-d001334.o):fake:(.text+0x2): undefined reference to `_imp__malloc'
Makefile:34: recipe for target 'libmgmp.so' failed

I'd just use the provided Windows binaries, but I'm using mosmllex which doesn't seem to be provided in the Windows bindist.

The type `syserror` is declared to be an equality type in the Basis. In Moscow ML it is not.

Missing functions:
val errorName : syserror → string
val syserror : string → syserror option

Missing substructure: IO.

Originally reported by Henning Niss

After build and install of mosml from the sources and performing the test, it fails with:

bash-3.2$ cd ${HOME}/src/test
bash-3.2$ make clean
rm -f result
bash-3.2$ make test
make: *** No rule to make target `test'. Stop.
bash-3.2$ make
rm -f result
mosml -P full test.sml > result 2>&1
mosml -P full < ovlfail.sml >> result 2>&1
mosml -P full < constfai.sml >> result 2>&1
mosml -P full < testcon.sml >> result 2>&1
mosml -P full < testty.sml >> result 2>&1
mosml -P full < typerr.sml >> result 2>&1
mosml -P full < recfail.sml >> result 2>&1
bash-3.2$ !di
diff result result.ok
1c1
< Moscow ML version 2.10

Moscow ML version 2.01a (January 2004)
327,330c327,330
< > val it = "WRONG" : string
< > val it = "WRONG" : string
< > val it = "WRONG" : string
< > val it = "WRONG" : string

val it = "OK" : string
val it = "OK" : string
val it = "OK" : string
val it = "OK" : string
336,338c336,338
< > val it = "WRONG" : string
< > val it = "WRONG" : string
< > val it = "WRONG" : string

val it = "OK" : string
val it = "OK" : string
val it = "OK" : string
340c340
< > val it = "WRONG" : string

val it = "OK" : string
356c356
< > val it = "WRONG" : string

val it = "OK" : string
365,366c365,366
< > val it = "WRONG" : string
< > val it = "WRONG" : string

val it = "OK" : string
val it = "OK" : string
500c500
< User: 0.021 System: 0.000 GC: 0.000 Real: 0.021

User: 0.390 System: 0.000 GC: 0.000 Real: 0.390
503c503
< User: 0.033 System: 0.000 GC: 0.000 Real: 0.033

User: 0.400 System: 0.000 GC: 0.000 Real: 0.391
518c518
< > val test3 = false : bool

val test3 = true : bool
945c945
< Moscow ML version 2.10

Moscow ML version 2.01a (January 2004)
1079c1079
< Moscow ML version 2.10

Moscow ML version 2.01a (January 2004)
1081,1086c1081,1104
< - > val fail1 = ~1073741825 : int
< - > val fail2 = 1073741824 : int
< - > val fail3 = ~1073741825 : int
< - > val fail4 = 1073741824 : int
< - > val fail5 = 0wx80000000 : word
< - > val fail6 = 0wx80000000 : word

• ! Toplevel input:
  ! val fail1 = ~1073741825;
  ! ^^^^^^^^^^^
  ! Lexical error: integer constant is too large.
• ! Toplevel input:
  ! val fail2 = 1073741824;
  ! ^^^^^^^^^^
  ! Lexical error: integer constant is too large.
• ! Toplevel input:
  ! val fail3 = ~0x40000001;
  ! ^^^^^^^^^^^
  ! Lexical error: integer constant is too large.
• ! Toplevel input:
  ! val fail4 = 0x40000000;
  ! ^^^^^^^^^^
  ! Lexical error: integer constant is too large.
• ! Toplevel input:
  ! val fail5 = 0w2147483648;
  ! ^^^^^^^^^^^^
  ! Lexical error: word constant is too large.
• ! Toplevel input:
  ! val fail6 = 0wx80000000;
  ! ^^^^^^^^^^^
  ! Lexical error: word constant is too large.
  1120c1138
  < Moscow ML version 2.10

Moscow ML version 2.01a (January 2004)
1267c1285
< Moscow ML version 2.10

Moscow ML version 2.01a (January 2004)
1317c1335
< Moscow ML version 2.10

Moscow ML version 2.01a (January 2004)
1463c1481
< Moscow ML version 2.10

Moscow ML version 2.01a (January 2004)
bash-3.2$

While compiling one of the example programs, I get a syntax error:

    $ mosmlc ./examples/modules/array.sml
    File "./examples/modules/array.sml", line 7, characters 0-9:
    ! signature  Array  =
    ! ^^^^^^^^^
    ! Syntax error.

This also happens with this simple program:

    structure MyList =
      struct
        fun each _ [] = ()
          | each f (x :: xs) = (f x; each f xs)
      end;

    val _ = MyList.each print ["Hello, world!\n"];

    $ ./bin/mosmlc example.sml
    File "example.sml", line 7, characters 0-3:
    ! val _ = MyList.each print ["Hello, world!\n"];
    ! ^^^
    ! Syntax error.

Both files run properly with the interpreter, mosml. This is running at tag ver-2.10.1 on Linux 4.1.4, armv6l.

Real.fromString may raise Overflow, if presented with too large or too small a value.

Example:

 load "Real";
 val a = Real.fromString "1e-400";
 val b = Real.fromString "1e400";

As far as I can tell, the specification says, that in these cases it should return zero (if too small in magnitude) or infinity (if too large in magnitude).

In https://mosml.org/mosmllib/, the links for the "MySQL" and "Graphics" structures are broken.

• https://mosml.org/mosmllib/MySQL.html should be https://mosml.org/mosmllib/Mysql.html instead.
• There is no HTML page for the Graphics structure.

Related: #52