Robot Languages - Another Part
I've forgotten what part I'm up to, ... See Robot Languages and Robot Languages - The Real Problem and also Chris Borge 3D-Printed a Small Lathe for Under $100 and Not an Engineer Wiring His CNC Mill.
The moment Alice appeared, she was appealed to by all three to settle the question, and they repeated their arguments to her, though, as they all spoke at once, she found it very hard indeed to make out exactly what they said.The executioner's argument was, that you couldn't cut off a head unless there was a body to cut it off from: that he had never had to do such a thing before, and he wasn't going to begin at his time of life.
The Queen's argument was, that if something wasn't done about it in less than no time she'd have everybody executed, all round. (It was this last remark that had made the whole party look so grave and anxious.)
`She's in prison,' the Queen said to the executioner: `fetch her here.' And the executioner went off like an arrow.
Illustration from Project Gutenberg's The Tenniel Illustrations for Carroll's Alice in Wonderland by Sir John Tenniel.
See Using Pipewire to Make A Music Synthesizer. A decade ago I spent a few months using Moscow ML for system programming. See Writing Assembler using Standard ML Functors. The idea I had was that you could use Standard ML functors to compose abstract assembler and it seemed to me that a Standard ML system could actually compose its own run-time system using high-level modules that plugged together to assemble machine code which did whatever low-level stuff was necessary on that particular hardware/operating system. The idea was to use the well-defined, well-understood syntax and semantics of Standard ML to formally specify the underlying representation on whatever actual hardware the system runs. ML is good for that sort of thing: see https://prooftoys.org/ian-grant/hm/.
So I used the Moscow ML facilities for dynamic linking of object libraries described in section 14 of the Moscow ML Owner's Manual to interface to the GNU libffi "Foreign Function Interface". At the time I had no idea that Matthias Blume had written a 2001 ENTCS note No-Longer-Foreign: Teaching an ML compiler to speak C “natively” and that this is what the MLton people had based their Foreign Function interface on. The idea, originally in SML/NJ, was to parse the C source files for the library, and generate the necessary binding code automatically from the function declarations in that C file. See http://mlton.org/MLNLFFIGen.
It turns out this approach, or something like it, was what the GObject Introspection project was all about. See https://docs.gtk.org/girepository. The idea is that annotated C source code implementing libraries like GTK, Cairo etc. would be scanned and documentation and a formal description of the API would be extracted so that when someone came to implement a language binding to that library, they could automatically generate the binding code. This would make it easier to track changes in the libraries: in most cases one could simply re-scan the formal descriptions and regenerate the necessary glue code to provide access to the new/changed function from the host language. This mechanism was not designed, rather it "grew", according to one of the authors in this thread: Basic documentation on gobject introspection API, principally through the experience of implementing the language bindings for Python, Gnome JavaScript and Perl. It turns out that implementing a language binding is very hard, because you have to actually try doing it before you understand what the problems are: see Steps to get started creating a new language binding?
Emmanuele Bassi did a livestream about this in 2022:
Subscribe to Emmanuele Bassi.
Well, I have already done that. I wrote a C language parser using Moscow ML and started collecting all I could from the GTK libraries, but I never had the resources to continue working on it. But it turns out that about four years ago (2021, so five years after my failed attempt) Phil Clayton wrote a set of GObject Introspection bindings for MLton and Poly/ML called The Giraffe Library which uses a code generator to metaprogram the bindings:
The Giraffe Code Generator generates an SML interface to libraries using the GObject Introspection metadata (GIR or TYPELIB files) provided by the libraries. The Giraffe Library source release files are generated using the GIR files only. Originally, the TYPELIB files were used and support is retained for generating code from them but only for comparison, to validate the code generated from GIR files.
But this story is not over yet, because the GObject introspection bindings are one of the main reasons that the Debian project cannot cross-compile. Neither can T2/sde, because the actual data about the C compiler semantics is not available in a formal specification. In short, you can only find out how long, say, a long int is by compiling a C program and running it! See Nir Lichtman's 12-minute Linux Distribution Video.
See my April 2014 blog post What is Wrong With Unix?
See Dylan Jones Interviewing Van Morrison on His New Album.
Subscribe to Van Morrison.
Comments
Post a Comment