Having faced the task of interfacing a homebrew language to a
variety of APIs, I feel there should be an easier way. It seems
wrappers for Python, Ruby, Scheme... are maintained for
frameworks like Qt, WxWidgets, Gtk, OpenOffice's UNO,
COM, .NET CLR etc. ect. ect., and this seems nuts.
Python seems to have wrappers for just about everything
and I'd really like to be able to plug in my own language
instead of Python and use those, but there is no easy way
of doing so; I can't sort out the interface without getting
entangled in Python internals I don't really want to know.
I think the idea has been proposed by others and such
projects may already exist, but I can't find any.
What I'd like to see, and contribute to if I can, would
be something like this:
At the core, a C++ (templatized or straight) interface for
dynamic dispatch, with object creation and event-handling
and, if feasible, a mechanism for implementing interfaces.
Also, some notion of threads.
To wrap a language, you would:
- specialise the interface by supplying template parameters
for string representation, memory model, levels of features
required etc.
- adapt the language runtime to use the interface
- compile the language runtime into a library
- create a scripting plugin using the library
and/or
create a boot module for running with app frameworks
with boot scripts for the the frameworks you want to use
How to wrap a framework or library would depend on
its nature. For application frameworks such as wxWidgets,
you would want
- to create an executable that runs wxWidgets applications
written in a particular language, using its boot module with
the relevant boot script, and
- to enable existing wxWidgets applications to use scripting
plugins in general.
For component systems like COM, you would write a
wrapper that could be loaded through the interface. For
stuff like UNO, both would apply: you might want to use
scripting plugins in OpenOffice, and you'd want to use its
features from outside.
Wrapping a framework would involve some work, as well as
maintaining the wrappers as frameworks evolve, so the
crucial point is: what would be required to reach the critcial
mass where pythoners, rubyers, schemers etc. would see
their benefit in going through a common interface rather than
writing individual wrappers?
Personally, I don't quite have the C++ guts to design a
framework but I know COM and wxWidgets well enough
that I might create wrappers for these, or assist in doing so,
once the framework is defined. My motivation for doing this
would depend on the framework being specified in a manner
to suit my own PILS language, but I don't think its requrements
are far off from those of Python, Ruby etc.
An important thing is, there should be a well-defined notion
of object ownership.
(In wxWidgets, objects like window sizers, menus, image lists
are sometimes owned by a window, sometimes not, which is
a pain for language binders and should be dealt with by the
binding framework.)
These are just some thoughts.
Perhaps the project already exists and noone uses it.
Perhaps it doesn't exist and noone really wants it.
Perhaps it exists and you all use it and I didn't find it because
I'm plain stupid.
Perhaps it's impossible to get an agreement on the interface
among adherents of various languages and frameworks.
Perhaps it should be limited to certain classes of languages,
to avoid the bulk of supporting any kind of language you'd
imagine. Perhaps such a limited framework would be
uninteresting.
Perhaps it is not technically feasible to create a unified event
handling interface for the various frameworks/languages.
Perhaps everybody is eventually going for the CLR.
(I hope not...)
Perhaps this is the wrong NG??? Perhaps I should be
out there, singing in the rain, instead of writing this? But
the wet weather gives me this urge to blow steam and
I just can't resist. Sorry.
|
