Re: Thoughts about the Lisp bindings project

[olafBuddenhagen]

Hi,

On Tue, Jun 03, 2008 at 02:01:12AM +0100, Flávio 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, OCaml, 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.

> Or, 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-