Hi David:

Thanks for the reply & review. That's a fair point regarding FFI and Int16. I 
do think Real32 could be useful, and I'm willing to take a look at a potential 
implementation when I get time (it's a bit hectic right now :-().

As for Word16, if you find something you dislike in the code while considering 
adding it into Poly, I'm happy to adjust it :-).

— 
Domagoj

> On 19 Oct 2018, at 15:10, David Matthews <david.matth...@prolingua.co.uk> 
> wrote:
> 
> Hi,
> Thank you for your comments and the patch.  Apologies for the delay in 
> replying; I wanted to give it some thought.
> 
> I'm not convinced that adding Int16 etc would help that much with FFI calls.  
> Currently the code checks that the values are in range when the foreign 
> function is called.  Using an appropriate fixed precision integer type would 
> essentially move the range checks elsewhere.  There might be some other uses 
> for Int16 etc.  I'll consider adding your Word16 code.
> 
> Real32 (i.e. float) might be useful on X86/64 because it could be implemented 
> using tagging rather than needing real numbers to be stored in heap cells.  
> Currently the need to allocate memory to hold a "real" is a significant 
> overhead.
> 
> Regards,
> David
> 
> On 13/10/2018 14:31, Domagoj Stolfa wrote:
>> Hi all:
>> I've only been using Poly for a few days and haven't done too much SML 
>> before a project I'm working on now -- but I've noticed a couple of things 
>> that seemed a little tedious while implementing some modules as a part of 
>> that project. I may have missed something, and if that's the case please do 
>> point it out to me. However, in case what I've observed is in fact the 
>> current state of the world, I've written a small proposal and a patch to 
>> eliminate these little annoyances (suggested to me by DGASAU on freenode).
>> In essence, I've been building an FFI in the past few days and noticed an 
>> absence of a number of things. Namely, there seems to be a lack of support 
>> for standard C types such as uint16_t, int16_t, int8_t, int64_t and float 
>> (not sure about int64_t). This can make building FFIs a bit of a hassle 
>> sometimes, as it requires explicit checks of what value the integer/word in 
>> SML might contain before deciding to try and write it.
>> An example of such a workaround would be:
>>         if (#NOFFS a) > 0w65535 orelse (#NENOFFS a) > 0w65535
>>         then raise RunCall.Conversion "Invalid Word16 constant"
>>         else (...)
>> where #NOFFS a and #NENOFFS a are otherwise manipulated as Word32.words.
>> Moreover, this seems to sometimes cause people developing software or 
>> extracting executable specifications from proof assistants such as Isabelle 
>> that depend on things like Word16 to discard or impose a limitation on SML 
>> used with PolyML as it simply does not support these types out of the box 
>> [1, 2]
>> Would it make sense to support these types in PolyML, namely through 
>> Word16.word, Int16.int, Int8.int and Int64.int, where Word16 would be of 
>> WORD signature, while Int16, Int8 and Int64 would be of INTEGER signature.
>> I've attached a sample patch for supporting Word16, very heavily based on 
>> David Matthews' work on Word8 in order to demonstrate what a very crude 
>> implementation of the proposal would look like.
>> Is this a real problem, and if so, is implementing these things a sensible 
>> way forward?
>> Thanks!
>> [1]: http://rohandrape.net/?t=smlsc3&e=README
>> [2]: https://www.isa-afp.org/browser_info/current/AFP/Native_Word/outline.pdf
>> _______________________________________________
>> polyml mailing list
>> polyml@inf.ed.ac.uk
>> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
> _______________________________________________
> polyml mailing list
> polyml@inf.ed.ac.uk
> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml

_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml

Reply via email to