I think Mlton uses the same precision for C int and ML int so there won't be the issue of an overflow exception when passing values from C to ML. That's easier to do with a full program compiler than the incremental compilation of Poly/ML.
David
On 10/10/2016 15:40, Kostirya wrote:
I think it should "to turn these conversions back to use FixedInt.int and raise an exception". It's important to preserve full compatibility with MLton, SML/NY, SML# ...
MLton: val plus = _import "plus": (int * int) -> int; val r = 0 + plus(1, 2) val _ = print ( (Int.toString(r) ^ "\n" ) )
New Poly/ML: val plus = buildCall2 ((getSymbol mylib "plus"), (cInt, cInt), cInt) val r = 0 + plus(1, 2) val _ = print ( (LargeInt.toString(r) ^ "\n" ) )
The difference in SML code has already appeared in:
MLton: val _ = print ( (Int.toString(r) ^ "\n" ) ) PolyML: val _ = print ( (LargeInt.toString(r) ^ "\n" ) )
2016-10-10 16:02 GMT+03:00 David Matthews <David.Matthews at prolingua.co.uk>:
I noticed this and thought I'd committed a fix but it seems not. The issue is that the C "int" type may have, depending on the platform, one more bit of precision than FixedInt.int in Poly/ML.
Now that the default int in Poly/ML is FixedInt.int that raises a question about how to deal with the various conversions (e.g. cInt) that could return a value that would overflow. Currently, c(U)Int8 and 16 have type "int conversion" and the rest, c(U)Int32/64 and c(U)Int have type "LargeInt.int conversion". While this ensures that there will never be an overflow when converting C values to ML it does mean there's a mismatch between C "int" and ML "int". I'm wondering whether to turn these conversions back to use FixedInt.int and raise an exception when a value will not fit and perhaps introduce new conversions (e.g. cIntLarge) to handle the full range of values.
Does anyone have any comments? David
On 10/10/2016 13:18, Kostirya wrote:
Hello. I updated Poly/ML from git (commit aa7bea141f227ea5d7feaa849763ad53fb4147d3) and found that mlsource/extra/CInterface/Examples/NewForeignTest.sml is broken:
env LD_LIBRARY_PATH=. poly --script NewForeignTest.sml
(4, 4) (5, 5) (12345, ...) NewForeignTest.sml:133: error: Type error in function application. Function: buildClosure1 : (int -> unit) * int conversion * unit conversion -> (int -> unit) closure Argument: (fn i => print (Int.toString i), cInt, cVoid) : (int -> unit) * LargeInt.int conversion * unit conversion Reason: Can't unify int (*In Basis*) with LargeInt.int (*In Basis*) (Different type constructors) Found near buildClosure1 (fn i => print (... ...), cInt, cVoid)
Is LargeInt.int a default int type for FFI now?
Nick.
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
For the MLton FFI, there are ML structures that implement INTEGER/WORD for each of the platform-dependent signed/unsigned C types. The ML int can be set by the compiler option -default-type (to Int32, Int64 or IntInf) so may not match the platform's C int type.
With Poly/ML conversions, LargeInt variants seem reasonable.
To maximize portability across compilers and platforms, I think a C interface would want to use LargeInt.int for numeric parameters on the ML side.
Phil
On 10/10/2016 18:45, David Matthews wrote:
I think Mlton uses the same precision for C int and ML int so there won't be the issue of an overflow exception when passing values from C to ML. That's easier to do with a full program compiler than the incremental compilation of Poly/ML.
David
On 10/10/2016 15:40, Kostirya wrote:
I think it should "to turn these conversions back to use FixedInt.int and raise an exception". It's important to preserve full compatibility with MLton, SML/NY, SML# ...
MLton: val plus = _import "plus": (int * int) -> int; val r = 0 + plus(1, 2) val _ = print ( (Int.toString(r) ^ "\n" ) )
New Poly/ML: val plus = buildCall2 ((getSymbol mylib "plus"), (cInt, cInt), cInt) val r = 0 + plus(1, 2) val _ = print ( (LargeInt.toString(r) ^ "\n" ) )
The difference in SML code has already appeared in:
MLton: val _ = print ( (Int.toString(r) ^ "\n" ) ) PolyML: val _ = print ( (LargeInt.toString(r) ^ "\n" ) )
2016-10-10 16:02 GMT+03:00 David Matthews <David.Matthews at prolingua.co.uk>:
I noticed this and thought I'd committed a fix but it seems not. The issue is that the C "int" type may have, depending on the platform, one more bit of precision than FixedInt.int in Poly/ML.
Now that the default int in Poly/ML is FixedInt.int that raises a question about how to deal with the various conversions (e.g. cInt) that could return a value that would overflow. Currently, c(U)Int8 and 16 have type "int conversion" and the rest, c(U)Int32/64 and c(U)Int have type "LargeInt.int conversion". While this ensures that there will never be an overflow when converting C values to ML it does mean there's a mismatch between C "int" and ML "int". I'm wondering whether to turn these conversions back to use FixedInt.int and raise an exception when a value will not fit and perhaps introduce new conversions (e.g. cIntLarge) to handle the full range of values.
Does anyone have any comments? David
On 10/10/2016 13:18, Kostirya wrote:
Hello. I updated Poly/ML from git (commit aa7bea141f227ea5d7feaa849763ad53fb4147d3) and found that mlsource/extra/CInterface/Examples/NewForeignTest.sml is broken:
env LD_LIBRARY_PATH=. poly --script NewForeignTest.sml
(4, 4) (5, 5) (12345, ...) NewForeignTest.sml:133: error: Type error in function application. Function: buildClosure1 : (int -> unit) * int conversion * unit conversion -> (int -> unit) closure Argument: (fn i => print (Int.toString i), cInt, cVoid) : (int -> unit) * LargeInt.int conversion * unit conversion Reason: Can't unify int (*In Basis*) with LargeInt.int (*In Basis*) (Different type constructors) Found near buildClosure1 (fn i => print (... ...), cInt, cVoid)
Is LargeInt.int a default int type for FFI now?
Nick.
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
I've changed the Foreign structure and signature so the cInt/cInt32 etc conversions that previously converted to LargeInt.int now convert to int. That does mean that there are going to be C values that will raise Overflow when passed to ML. I've added cIntLarge etc that convert to LargeInt.int. These, of course, will handle any value from C.
David
On 13/10/2016 07:44, Phil Clayton wrote:
For the MLton FFI, there are ML structures that implement INTEGER/WORD for each of the platform-dependent signed/unsigned C types. The ML int can be set by the compiler option -default-type (to Int32, Int64 or IntInf) so may not match the platform's C int type.
With Poly/ML conversions, LargeInt variants seem reasonable.
To maximize portability across compilers and platforms, I think a C interface would want to use LargeInt.int for numeric parameters on the ML side.
Phil
On 10/10/2016 18:45, David Matthews wrote:
I think Mlton uses the same precision for C int and ML int so there won't be the issue of an overflow exception when passing values from C to ML. That's easier to do with a full program compiler than the incremental compilation of Poly/ML.
David
On 10/10/2016 15:40, Kostirya wrote:
I think it should "to turn these conversions back to use FixedInt.int and raise an exception". It's important to preserve full compatibility with MLton, SML/NY, SML# ...
MLton: val plus = _import "plus": (int * int) -> int; val r = 0 + plus(1, 2) val _ = print ( (Int.toString(r) ^ "\n" ) )
New Poly/ML: val plus = buildCall2 ((getSymbol mylib "plus"), (cInt, cInt), cInt) val r = 0 + plus(1, 2) val _ = print ( (LargeInt.toString(r) ^ "\n" ) )
The difference in SML code has already appeared in:
MLton: val _ = print ( (Int.toString(r) ^ "\n" ) ) PolyML: val _ = print ( (LargeInt.toString(r) ^ "\n" ) )
2016-10-10 16:02 GMT+03:00 David Matthews <David.Matthews at prolingua.co.uk>:
I noticed this and thought I'd committed a fix but it seems not. The issue is that the C "int" type may have, depending on the platform, one more bit of precision than FixedInt.int in Poly/ML.
Now that the default int in Poly/ML is FixedInt.int that raises a question about how to deal with the various conversions (e.g. cInt) that could return a value that would overflow. Currently, c(U)Int8 and 16 have type "int conversion" and the rest, c(U)Int32/64 and c(U)Int have type "LargeInt.int conversion". While this ensures that there will never be an overflow when converting C values to ML it does mean there's a mismatch between C "int" and ML "int". I'm wondering whether to turn these conversions back to use FixedInt.int and raise an exception when a value will not fit and perhaps introduce new conversions (e.g. cIntLarge) to handle the full range of values.
Does anyone have any comments? David
On 10/10/2016 13:18, Kostirya wrote:
Hello. I updated Poly/ML from git (commit aa7bea141f227ea5d7feaa849763ad53fb4147d3) and found that mlsource/extra/CInterface/Examples/NewForeignTest.sml is broken:
env LD_LIBRARY_PATH=. poly --script NewForeignTest.sml
(4, 4) (5, 5) (12345, ...) NewForeignTest.sml:133: error: Type error in function application. Function: buildClosure1 : (int -> unit) * int conversion * unit conversion -> (int -> unit) closure Argument: (fn i => print (Int.toString i), cInt, cVoid) : (int -> unit) * LargeInt.int conversion * unit conversion Reason: Can't unify int (*In Basis*) with LargeInt.int (*In Basis*) (Different type constructors) Found near buildClosure1 (fn i => print (... ...), cInt, cVoid)
Is LargeInt.int a default int type for FFI now?
Nick.
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
-
David.Matthews＠prolingua.co.uk -
phil.clayton＠lineone.net