Poly/ML February 2021

polyml@lists.polyml.org

4 participants
4 discussions

PackReal32
by cannam＠all-day-breakfast.com 27 Apr '21

27 Apr '21

Hello! I find I could do with the PackReal32{Big,Little} structures, 32-bit floats being often more amenable to serialisation and used in some storage formats. Would there be any appetite for adding these? Thanks, Chris

2 7

Updates in git master including major change to FFI
by David.Matthews＠prolingua.co.uk 11 Mar '21

11 Mar '21

Hi, I've just pushed a collection of changes to master that have been in the pipeline for quite a long time. Some of these are internal changes to the run-time system and some are extensions, such as the addition of IPv6 networking with INet6Sock and Net6HostDB structures. The major change, though, is with the foreign function interface. On X86 platforms libffi is no longer used and the version of it included in the libpolyml directory has been removed. Libffi is still used in the interpreted version but only if the library is installed on the system. Instead the foreign function interface is handled essentially as part of the compiler. The high-level interface in the Foreign structure remains unchanged but the buildCallN functions now actually compile interface functions. This results in foreign function calls being substantially faster than with libffi; at least 10 times faster for trivial calls on the X86/64. The cost is, of course, some extra work when buildCallN is called, meaning that it is essential that these functions are only used at the top level. The reason for the speed-up is that the interface has to place the arguments in the correct registers for the ABI and the rules for placing arguments can be quite complicated, particular on the X86/64 on Unix. Libffi computes the placement on every call whereas the compiler can do this once and build code that moves the arguments into the right registers and returns the result. For backwards compatibility buildClosureN functions have been retained but these are wrappers around new buildCallback functions. The buildCallback functions differ in two respects. Closures created with buildCallback are garbage-collected which means that if they are used to register callbacks with a C library it may be necessary to keep a reference in ML. There is a touchClosure function that should be called when the callback is no longer needed. For compatibility closures created with buildClosure are retained in a global list to avoid garbage collection. The other difference is that the buildCallback functions have a slightly different type from buildClosure and that reflects the underlying implementation. For example, val buildCallback1: 'a conversion * 'b conversion -> ('a -> 'b) -> ('a -> 'b) closure The first application builds the interface code that handle the conversion between the ML and C ABIs. The second application applies this to an ML function to build a closure value that can be passed to C. This second application builds a small additional piece of code that simply loads the address of the ML function into a register and jumps to the interface code. What this means is that while the first application should always be done at the top level it is possible to embed an application of this to a particular ML function inside ML code. There is still an overhead compared with creating a closure in ML and it is better if possible to do the application at the top level but the cost is significantly less than if the whole buildCallback function were called within a function. As always please give this a try and let me know if there are problems. Regards, David

4 22

the design of Poly/ML
by buday.gergely.istvan＠uni-mate.hu 17 Feb '21

17 Feb '21

Hi, is there an academic description of the design of Poly/ML, regarding compilation strategies, intermediate languages etc? Cheers - Gergely

1 0

Announcement: Giraffe Library
by phil.clayton＠veonix.com 17 Feb '21

17 Feb '21

[Apologies if you receive multiple copies this message] Dear Poly/ML users, I would like to announce the first public release of Giraffe Library, an SML interface to libraries that support GObject Introspection, such as GTK. The latest release, 1.0.0-alpha.11, provides GTK 3 and supporting libraries, enabling applications with GUIs to be written entirely in SML. Applications without GUIs may also find some features useful, for example, in GLib, sockets using UDP multicast and various checksums, which are not available in the current Basis Library. For more information, download, documentation and examples, please see: http://giraffelibrary.org/ Regards, Phil

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Poly/ML February 2021