Resolve build command

[LdBeth]

Do I need to configure anything?

~/git-repos/MLPolyR|master λ> ./mlpolyrc Tests/alloc.mlpr 
Assembler messages:
Fatal error: invalid listing option `r'
~/Downloads/sml-nj-110.87/bin/sml: command `as -arch ppc -o Tests/alloc.o Tests/alloc.s' failed

Originally posted by @ice1000 in https://github.com/LdBeth/mlpolyr/issues/1#issuecomment-489469027

[ice1000]

Please take a look at #3

[ice1000]

... and please take a look at #4

[LdBeth]

SO, The sad thing is it emits PPC instruction, which obviously can't directly assemble on x86_64.

[ice1000]

Is it possible to disable code generation but enable type-checking (which may need you to look into the code deeply) with some cli options?

[LdBeth]

Yes, the interface is fairly clean, so I think it's viable to do so.

[LdBeth]

So command switch -S produce only asm file without assembly and linking, which can be used as a work around if you only what to do type/syntax checking

example file: test.mlpr

let fun sum a b = a + b
in 0
end

$ /mlpolyrc -S test.mlpr

exit 0, success, produce asm file test.s

and with file test2.mlpr

let fun sum a b = a + [] 
in 0
end

which is obviously wrong, mlpolyrc gives

test2.mlpr:1.24-1.26 Error: type mismatch: tycon mismatch: [...] vs. int [clash between ['A] from test2.mlpr:1.24-1.26 and int from test2.mlpr:1.20-1.26]
Elaborate

[ice1000]

tql

[ice1000]

Does MLPolyR has something like version (which I didn't find with grep -rnE version *) and help?

[LdBeth]

No, although the author leaves quiet a few information in comments. for e.g., the register allocation uses graph-coloring scheme, and the compile referenced "Modern Compiler Implementation in ML"

BTW seems MLPolyR has no type annotation and all the types are inferred.

[ice1000]

Yes, MLPolyR does not support type annotation because there isn't dependent type.

[ice1000]

Since it compiles to an untyped lambda calculus, is it possible to transpile that into Chez scheme?

[LdBeth]

There's already an ANF-interpreter/lambda-interpreter included, and neither of them are used by the compiler, so I assure they're for debug purpose and can be utilized for an interpreter within SML