Thoughts about the Lisp bindings project

Hi,

Tue, Jun 03, 2008 at 02:01:12AM +0100, F Cruz wrote:

You are right, it may create redundancy but, wouldn't it be nice to
define new interfaces without leaving lisp and then using them to
create new servers only with lisp code? I'm not even talking about
re-defining the already used interfaces in Lisp, but creating new
ones.

No, it wouldn't. We don't want to create a closed world for Lisp
translators. We want to be able to combine translators (and other
programs using hurdish interfaces) written in different languages.

Any interface introduced by a Lisp translator would also have to be made
available as a .def for use in C (and other languages); and any existing
interface would have to be made aavailable in Lisp You would have to
duplicate all interfaces.

And what about Python, Perl, Ruby, Caml, Haskell, Lua, ? Should
every one of them introduce new interface definitions?

Really, using common interface definition files for all languages is the
only sane option.

, you could even (possible with more work) replace some core servers
with ones written in lisp

Well, the core servers used by default must keep dependencies and
resource usage to a minimum; thus I have serious doubts about
implementing them in Lisp (or other languages).

But if you want to create your own variant of "auth" for instance, I
don't see any objections to doing it in Lisp. Indeed I think that some
of the existing, non-essential servers very well could be (re)written in
other languages.

But that only makes it all the more important to allow seamlessly
combining servers in different languages.

Using MIG generated stubs means less work but keeps you dependent on
stubs generated on the C language. Using native stubs, well, you don't
have to deal with MIG, which, sincerely, is not the best thing in the
world :)

I'm not convinced that dealing with MiG is something we urgently need to
avoid

I have no strong opinion on this, though. I leave the decision up to you
(and your mentor).

(And in fact also for other approaches like binding to existing
libraries -- you now say that you want to do it this way as if was
the most normal thing in the world, but never explain your
motivation for that change Don't leave us groping in the dark!
:-) )

Well, when I sent my proposal, the initial goal was to develop two
library bindings: one for libtrivfs and another for libnetfs. But,
Neal Walfield expressed some disappointment that the Lisp bindings
would not bind at a deeper level (namely, at the interface level) and
then Pierre Thierry and I discussed about investigating these
different approaches.

Why I'll bind these libraries like libports? Well libports is
currently used in libtrivfs and libnetfs and is needed to manage ports
and listening to incoming messages. Also, I think it will be generally
useful to have a Lisp library to libports.

That's rather superficial I was hoping for a more in-depth
discussion, to be honest.

-antrik-