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-
