I would love to see a repository of dll bindings appear for my favourite OS/ST combinations.
If such a repository were to be created and maintained for specific OSes it would be a Good Idea (tm) to make them Smalltalk vendor neutral, so all of the ST communities can help maintain such a repository.
To accomplish this we would need a portabale representation for the declaration of external functions, for example an extention to SIF.
There are already a couple of CS projects for portable program representation, they should be extended with a portable representation of dll bindings:
The easy part of this project is to define declarations of the 'outside':
- dll search path(s)
- dll name(s)
- function names
- argument types
I expect the hard part to be to represent the 'inside' in a way that doesn't incur overhead on some/all platforms: - where does a method representing a foreign function show up? This has to be the same place in all dialects, so we can write portable ST programs using the foreign functions.
- how is type coercion done in a vendor neutral way.
- how is memory management done in a dialect neutral way?
- 'pinning ' memory regions/objects so they don't move.
- importing/exporting objects from/to memory regions not managed by the VM.
Reinout Heeck, ...
Dave Simmons www.smallscript.org says: Based on my experience and work on hi-performance FFI for SmallScript, I think this goal is very difficult to implement without providing some common optional typing infrastructure and related annotation syntax changes to the Smalltalk language. At a minimum it begins with the <primitive:...> format.
- The various dialects already have have their FFI language extentions cast in stone, so any external representation has to be translated to these extended syntaxes at file-in time. I'm not sure these language extentions need to be reflected in the external representation though. For example the SIF representation of a class definition looks like a standard message send. I guess we could define FFI extentions for SIF that look like message sends without using '<primitive: ...>' or '<C: ...>' syntax in the portable external representation. The downshot of this approach would be that we will need to define some magic words in the extended SIF representation that look like globals, IOW we will need to consider global name clashes. --RH