Why no standard foreign language interface?
Robert Posey
Why doesn't LISP have a standard foreign language interface?
Muddy
Tim Bradshaw
> Dear Gentle Persons,
> Why doesn't LISP have a standard foreign language interface?
Why doesn't C?
Robert Posey
Don't know, however the higher level a language is, the more it needs one.
It must have been suggested, I just wanted to know if anyone knew why. It
would makes LISP or C more portable.
Muddy
Erik Naggum
| Why doesn't LISP have a standard foreign language interface?
because the standards committees failed to reach consensus on the many
differing proposals and techniques before them. and that's a good thing,
considering that since the standard was approved, none of the then
current foreign function interfaces have survived, C has become the de
facto least common denominator, meaning that C's calling conventions and
types are now regarded as fundamental (they aren't and never have been),
and any standard would have had to be abandoned, anyway.
but why this clamoring for the _standard_ to solve everything for you?
do you know any other language where the language standard has it all?
(even Java and C++ fail this test on a huge number of counts.)
#:Erik
Barry Margolin
Robert Posey <mu...@raytheon.com> wrote:
>Dear Gentle Persons,
>
>Why doesn't LISP have a standard foreign language interface?
Because at the time the Common Lisp standard was being written, there
wasn't much concensus among vendors about how the FFI should work, so there
was nothing to standardize on.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Robert Posey
Erik Naggum wrote:
>
> * Robert Posey <mu...@raytheon.com>
> | Why doesn't LISP have a standard foreign language interface?
>
>
> but why this clamoring for the _standard_ to solve everything for you?
> do you know any other language where the language standard has it all?
> (even Java and C++ fail this test on a huge number of counts.)
Because if the standard has a standard interface, I could move the LISP code
to a new machine without change. In addition, commonly needed low level
language
routines could be reused as well. The existence of a standard interface
wouldn't
prevent you from writing your own if needed, but it would provide one you
could count on being there.
Muddy
>
> #:Erik
Thomas A. Russ
> Why doesn't LISP have a standard foreign language interface?
Many people have wanted one for years.
I suspect that there are at least a few technical hurdles that make
things a bit difficult.
(1) Some platforms have specialized data types that are important to
represent, so at the least a standard FFI would have to allow
extensions. On the Mac, there are records that are used to pass data to
OS calls that don't exist in the same way under Windows or Unix.
(2) Some OS's need other support. Calls to low-level primitives in ROM
is one example.
(3) The call out to the foreign function is only one part of the
problem. (I think the easier part). Some vendor's FFIs also
provide a way for C code to access and manipulate Lisp objects as well.
Since Lisp object implementation isn't standardized, it could be
difficult to develop a standard for manipulating Lisp objects. Perhaps
it wouldn't be too hard to develop an API for things like slot accesses
and boxing floats, bignums and fixnums.
That said, it is still something that should be considered.
--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
Erik Naggum
| Because if the standard has a standard interface, I could move the LISP
| code to a new machine without change.
no, you couldn't. think again. whether you can move your code without
change depends vastly more on the code to which you interface than the
code that describes the interface.
| In addition, commonly needed low level language routines could be reused
| as well.
pardon me, but this is wishful thinking bordering on nonsense. have you
ever tried to port _any_ code between disparate machines and operating
systems? have you seen how much work it takes to make C code export a
portable interface?
what you need is a tool that can take C (or whatever) source code and
automatically produce the foreign function interface glue code that your
Common Lisp implementation needs. why even _think_ about such a silly
thing as writing all the foreign function interface definitions by hand?
this cry for a standard foreign function interface stuff is just plain
stupid. it detracts from the real answer in a really big way, because
people can be sooo content to sit on their fat asses and whimper about
the standard being mean and cheap and not giving them what they sorely
"need", while the real solution is waiting very patiently for somebody to
just stop staring at the stupid non-solutions and whining and whimpering,
and just freaking _do_ it.
believe me, once you can figure out the braindamaged syntax of all these
stupid infix languages with a plethora of static types and other junk
enough to do the necessary steps of (1) writing wrapper code in that same
language or in C that is more friendly to a Common Lisp interface, and
(2) knowing enough to write foreign function interface code in Common
Lisp, producing output that fits one of umpteen different foreign
function interface definition "languages" for various Common Lisp
implementations is _really_ trivial.
#:Erik
Fernando D. Mato Mira
> believe me, once you can figure out the braindamaged syntax of all these
> stupid infix languages with a plethora of static types and other junk
> enough to do the necessary steps of (1) writing wrapper code in that same
> language or in C that is more friendly to a Common Lisp interface, and
> (2) knowing enough to write foreign function interface code in Common
> Lisp, producing output that fits one of umpteen different foreign
> function interface definition "languages" for various Common Lisp
> implementations is _really_ trivial.
Automatic FFI generation from C++ header files is far from trivial.
For C, you can easily write a FFIGEN `backend' adapted to your CL
implementation.
That's true.
[FFIGEN is lcc with a backend that translates header files to s-expr form.
That's the input to your backend.
Confused enough? ;) ]
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
Barry Margolin
>* Robert Posey <mu...@raytheon.com>
>| Because if the standard has a standard interface, I could move the LISP
>| code to a new machine without change.
>
> no, you couldn't. think again. whether you can move your code without
> change depends vastly more on the code to which you interface than the
> code that describes the interface.
>
>| In addition, commonly needed low level language routines could be reused
>| as well.
>
> pardon me, but this is wishful thinking bordering on nonsense. have you
> ever tried to port _any_ code between disparate machines and operating
> systems? have you seen how much work it takes to make C code export a
> portable interface?
I'm guessing that he's assuming a common operating system, but disparate
Lisp implementations. E.g. he wants to port code between Harlequin, CMUCL,
and Franz, all on Unix. So he's interfacing to the same foreign APIs, and
just wants a single FFI syntax to describe it.
Chris Double
> So he's interfacing to the same foreign APIs, and just wants a
> single FFI syntax to describe it.
Paul Meurer has a common FFI layer in his SQL/ODBC library that works
with LispWorks and Allegro (among others). If the original poster
wants such an API they may want to take a look at that. It is
available as a contribution in the cl-http distribution.
Chris.
William Deakin
> Automatic FFI generation from C++ header files is far from trivial.
Also, what about linking between different compilers. Shouldn't the questionbe
posted to comp.lang `Why no standard ffi interfaces between different computer
languages? Or for that matter between different compilers using the same computer
language?' ;)
-- will
Fernando D. Mato Mira
> Also, what about linking between different compilers. Shouldn't the questionbe
> posted to comp.lang `Why no standard ffi interfaces between different computer
> languages? Or for that matter between different compilers using the same computer
> language?' ;)
Have you been reading the Norwegian edition of "Evil Geniouses For Lispers" ? ;)
Erik Naggum
| Automatic FFI generation from C++ header files is far from trivial.
it may help to read what I write if you want to pose counter-arguments to
it instead of counter-arguments to something I didn't say.
C++ sucks. to interface to C++, you need wrapper code in C++ that makes
it possible to interface Common Lisp to the wrapper code. this code may
well be strictly C-compatible, as in `extern "C"'.
| For C, you can easily write a FFIGEN `backend' adapted to your CL
| implementation. That's true.
so what prohibits you from being smart and utilizing this fact when
dealing with the utter braindamage of C++? my answer: nothing. it's
better to waste time in wrapper code than on stupid programmer tricks.
#:Erik
Fernando D. Mato Mira
> * "Fernando D. Mato Mira" <mato...@iname.com>
> | Automatic FFI generation from C++ header files is far from trivial.
>
> it may help to read what I write if you want to pose counter-arguments to
> it instead of counter-arguments to something I didn't say.
OK. Let's see [I looked carefully at your wording before posting]:
Erik said:
"believe me, once you can figure out the braindamaged syntax of all these
stupid infix languages with a plethora of static types and other junk
enough to do the necessary steps of (1) writing wrapper code in that same
language or in C that is more friendly to a Common Lisp interface, and
(2) knowing enough to write foreign function interface code in Common
Lisp, producing output that fits one of umpteen different foreign
function interface definition "languages" for various Common Lisp
implementations is _really_ trivial."
"Once you figure out how to do (1) and (2) it's trivial"
OK, I figure out I have to write or use a C++ parser to write the wrapper code
automatically, and producing the Lisp FFI code. I've that that for MzScheme.
It was
trivial because Lars Thomas Hansen had already bothered to adapt lcc.
Given that's so trivial, Do you want to do the same with GCC or PPCR? Maybe if
each
one of us puts $10 that's enough to pay for it.
If you want to trivially write a C++ parser in CL that would be even better!
> C++ sucks. to interface to C++, you need wrapper code in C++ that makes
> it possible to interface Common Lisp to the wrapper code. this code may
> well be strictly C-compatible, as in `extern "C"'.
Well, C++ sucks, but the CL add-on product could know enough about the calling
conventions of the particular C++ compiler, and about C++ syntax to do a lot
of stuff directly,
for example by leveraging your dead Lucid code [But don't throw loads of money
at this! Better is to license the tech from EDG
(of course disgusting for the developers, should the other one be written in
Lisp. That's one disgust in exchange)], or by being
a real GCL integrated with the rest of GCC [someone applied for a grant to
implement a Scheme frontent for GCC, BTW]
>
> | For C, you can easily write a FFIGEN `backend' adapted to your CL
> | implementation. That's true.
>
> so what prohibits you from being smart and utilizing this fact when
> dealing with the utter braindamage of C++? my answer: nothing. it's
> better to waste time in wrapper code than on stupid programmer tricks.
lcc (and hence FFIGEN) only does C. See above.
Fernando D. Mato Mira
> PPCR
BZZT. PCCTS.
Erik Naggum
| "believe me, once you can figure out the braindamaged syntax of all these
| stupid infix languages with a plethora of static types and other junk
| enough to do the necessary steps of (1) writing wrapper code in that same
| language or in C that is more friendly to a Common Lisp interface, and
| (2) knowing enough to write foreign function interface code in Common
| Lisp, producing output that fits one of umpteen different foreign
| function interface definition "languages" for various Common Lisp
| implementations is _really_ trivial."
but Fernando read:
| "Once you figure out how to do (1) and (2) it's trivial"
no wonder we don't communicate!
| If you want to trivially write a C++ parser in CL that would be even better!
try a remedial reading comprehension class instead of this idiocy, will you?
| Well, C++ sucks, but the CL add-on product could know enough about the
| calling conventions of the particular C++ compiler, and about C++ syntax
| to do a lot of stuff directly, for example by leveraging your dead Lucid
| code [But don't throw loads of money at this!
that's why I stated, and quite explicitly at that, that you need to write
WRAPPER CODE IN THAT SAME LANGUAGE OR IN C THAT IS MORE FRIENDLY TO A
COMMON LISP INTERFACE. will you _please_ get it?
#:Erik
Fernando D. Mato Mira
>
> | "Once you figure out how to do (1) and (2) it's trivial"
>
> no wonder we don't communicate!
I was going to write:
"Once you figure X in order to see how to do (1) and (2) it's trivial"
Obviously, you have to "figure out X" if you're going to
"figure out how to do (1) and (2)"
Anyway, Erik says:
"Figuring out the C++ syntax takes infinite time so, relatively speaking,
implementing a mapping is trivial"
Fernando says:
"Figuring out the C++ syntax is trivial ("IT SUCKS!!!"), so absolutely and
relatively speaking, the non-zero amount of work required
to learn and use uninteresting non-lisp based tools that do the sweating for you
is (by definition) nontrivial. If you want to do a better job,
embed N C++ linkers. If you want to do an even better one, implement C++ compiler
for inlines. Apply 10X `infinite rule' to semantics. Good luck."
William Deakin
> WRAPPER CODE IN THAT SAME LANGUAGE OR IN C THAT IS MORE FRIENDLY TO A COMMON
> LISP INTERFACE?
Ouch. For two reasons really. First the inherent evil in c++ library naming. It
needs 'putting to the sword.' Oh, and the shouting ;)
:) will
Erik Naggum
| Ouch. For two reasons really. First the inherent evil in c++ library
| naming. It needs 'putting to the sword.'
I'm operating under the assumption that the name mangling thing is known
to the compiler, and that `extern "C"' means the functions can refer to
internal functions with mangled names, but export un-mangled names, that
mere mortals can predict. the wrapper functions around "native" C++
functions can also do away with the braindamaged passing of pointers to
structuresd classes, and use real argument lists. at least half of the
problem with interfacing to C++ is having to deal with the incredible
propensity of C++ programmers to make function calls "efficient" by using
pointers and references and whatnot in a very chaotic way. such is what
happens to people when they don't have lambda lists and multiple return
values, but there's no reason to try to map such pain into the Common
Lisp world.
#:Erik
Erik Naggum
| "Once you figure X in order to see how to do (1) and (2) it's trivial"
once again, you have missed what "it" refers to. I'm tiring of this.
| Obviously, you have to "figure out X" if you're going to
| "figure out how to do (1) and (2)"
|
| Anyway, Erik says:
|
| "Figuring out the C++ syntax takes infinite time so, relatively speaking,
| implementing a mapping is trivial"
what I did in fact say, you George W. Bush you, was that once you got the
information, _which_ particular form the FFI glue code should take is
trivial. the argument, since you missed it completely, was against
having a _standard_ FFI form, since that is such a trivial piece of the
whole equation. do you get it _now_?
I realize that some people are so devoid of ethics as to pretend that
other people said things they never did simply by putting those funny ""
characters around any damn lie they want, but I take exception to that,
and I take exception to the whole personality of people who are so
mind-bogglingly unware of their own actions as not to realize that they
are doing this kind of shit.
go away, Fernando D. Mato Mira.
#:Erik
William Deakin
> ...that `extern "C"' means the functions can refer to internal functions
> with mangled names, but export un-mangled names, that mere mortals can
> predict.
I agree. I just think this is ugly. But I've whinged about this before so I'll
shut up. Urggh.
[...elided an excellent description of more problems with c++...]
More urggh. You've convinced me, lo-quality c++ programmers should be offered
retraining or burning at the stake.
Best Regards,
:) will
ps: There is no fervid zeal like that of a convert ;)
Harley Davis
news:31595613...@naggum.no...
> * William Deakin <wi...@pindar.com>
> | Ouch. For two reasons really. First the inherent evil in c++ library
> | naming. It needs 'putting to the sword.'
>
> I'm operating under the assumption that the name mangling thing is known
> internal functions with mangled names, but export un-mangled names, that
> functions can also do away with the braindamaged passing of pointers to
Erik, could you say a few more words about when you've seen C++ programmer
inappropriately pass pointers to structs and classes? I can't recall having
seen much of this to disapprove of, so I'm curious what your experience has
been.
Thanks,
-- Harley
Erik Naggum
| Erik, could you say a few more words about when you've seen C++ programmer
| inappropriately pass pointers to structs and classes? I can't recall having
| seen much of this to disapprove of, so I'm curious what your experience has
| been.
it is not "inappropriate" for C++ programmers to pass pointers around --
they have no other mechanisms to use for non-trivial argument passing of
any kind. what I consider inappropriate is trying to map such C++-style
pointer-passing directly into Common Lisp at the FFI level when we have
powerful lamba lists and multiple values, and therefore I favor writing
wrapper code in C/C++ that makes use of far simpler argument-passing
techniques that can be called with far more ease from Common Lisp. and
since this is drudgery at best, it should be handled by automated tools.
(and before we have another stupid confusion, I'm _not_ saying (and never
have said) that writing such tools is trivial -- I'm saying that the
output of such automated tools will of necessity be trivial to make fit
_any_ form of FFI glue code that people invent in solitude, and that we
should re-focus on the tools, not on standardizing FFIs, which will be a
lot of meaningless work to tie vendors and developers into using an FFI
with a standard form that won't be able to handle all that interfacing to
C++ requires, anyway, simply because of the magnitude of the braindamage
in that language and what people do to survive it.)
#:Erik
Harley Davis
> * "Harley Davis" <nospam...@nospam.museprime.com>
> | Erik, could you say a few more words about when you've seen C++
programmer
> | inappropriately pass pointers to structs and classes? I can't recall
having
> | seen much of this to disapprove of, so I'm curious what your experience
has
> | been.
>
> it is not "inappropriate" for C++ programmers to pass pointers around --
> they have no other mechanisms to use for non-trivial argument passing of
> any kind. what I consider inappropriate is trying to map such C++-style
> pointer-passing directly into Common Lisp at the FFI level when we have
> powerful lamba lists and multiple values, and therefore I favor writing
> wrapper code in C/C++ that makes use of far simpler argument-passing
> techniques that can be called with far more ease from Common Lisp. and
> since this is drudgery at best, it should be handled by automated tools.
Thank you - I had misunderstood your complaint.
I certainly would never claim that writing such a tool is trivial, having
undertaken the effort twice now (once for Lisp and once for Java), nor do I
see how someone could claim that someone else with even an ounce of sense
might believe that it was a trivial task. It is difficult on the face of
it. Just weigh the printed copy of ISO C++ and it's pretty obviously going
to be a hard problem...
And yes, we did wrap all linked C++ functions in extern "C" wrapper calls to
avoid silly name mangling problems, and we had very precise rules about how
various pointers, references, pointers to pointers, etc etc for the ten
gazillion cases were handled in the Lisp (and Java) proxies...
I have to say that it was an extremely fun project both times.
-- Harley
Martin Cracauer
>Barry Margolin <bar...@bbnplanet.com> writes:
>> So he's interfacing to the same foreign APIs, and just wants a
>> single FFI syntax to describe it.
>Paul Meurer has a common FFI layer in his SQL/ODBC library that works
>with LispWorks and Allegro (among others).
Xeros PARC ILU also has a layer over FFIs. While ILU is for Allegro
only for now, the interface is designed to be generic enough to be
used over different Lisp implementations.
In fact, an ORB like ILU is a kind of FFI.
Still, see my other message why I think the specialized FFIs are
better.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
"Where do you want to do today?" Hard to tell running your calendar
program on a junk operating system, eh?
Martin Cracauer
>Why doesn't LISP have a standard foreign language interface?
First, you mean an interface to "C", I assume.
Because the thickness of the layer you need varies from one Lisp
implementation to another.
For example, CMUCL internally represents character strings the same
way as C. As 8-bits chars with a terminating zero (CMUCL of course has
an additional length integer, but the terminating zero in addition).
That means that you can use C string in CMUCL much more directly than
in other implementations.
The biggest difference is that many Lisp implementations need some
kind of "glue" code. That is C code that is a layer between the C
interface you want to use. This layer converts the calling convention
and data types in a way that a second interface appears that does the
same thing as your C interface, but can be called from Lisp.
Other Lisp implementations (i.e. CMUCL) can model C structs directly.
You can have Lisp data types that represent C data types directly. You
don't need to write glue code and only a minimum of conversion is
needed.
Please check out the CMUCL alien manual
(http://www.mindspring.com/~rtoy/software/cmu-user/node221.html) and
maybe the GCL one. It will be obvious that the problem here is that
the task of interfacing is very different (despite the fact that the
goal is the same) that it doesn't make sense to push these different
tasks in a common interface.
A standard FFI would have to standardize an interface that assumes the
maximum incompatiblity of C and Lisp data types and calling
convention, that means the thickest layer imaginable. It is very hard
to automatically optimize code that uses this highest-level interface
to a low-level direct interface your implementation might provide.
You may consider ORBs like CORBA a kind of standard FFI, BTW. I don't
think there is much future in those kind of things, though.
What we would need is a standalone tool that generates FFI code
(either only Lisp code or Lisp code and C glue code) from a common
description of the C interface. That common description of a C
interface would ideally be a C header file, but that approach meets a
lot of problems. As far as I know, no specialized description language
for that purpose has been written.
Marco Antoniotti
crac...@bik-gmbh.de (Martin Cracauer) writes:
> Robert Posey <mu...@raytheon.com> writes:
>
> >Why doesn't LISP have a standard foreign language interface?
>
> First, you mean an interface to "C", I assume.
>
> Because the thickness of the layer you need varies from one Lisp
> implementation to another.
... lots of useful comments deleted...
> A standard FFI would have to standardize an interface that assumes the
> maximum incompatiblity of C and Lisp data types and calling
> convention, that means the thickest layer imaginable. It is very hard
> to automatically optimize code that uses this highest-level interface
> to a low-level direct interface your implementation might provide.
>
> You may consider ORBs like CORBA a kind of standard FFI, BTW. I don't
> think there is much future in those kind of things, though.
A pretty thick layer, isn't it?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Pierre R. Mai
> What we would need is a standalone tool that generates FFI code
> (either only Lisp code or Lisp code and C glue code) from a common
> description of the C interface. That common description of a C
> interface would ideally be a C header file, but that approach meets a
> lot of problems. As far as I know, no specialized description language
> for that purpose has been written.
As I have pointed out before, SWIG (http://www.swig.org/) is such a
standalone tool that is being used quite successfully to genereate FFI
code (usually both implementation-specific FFI code and C wrapper/glue
code) for most of the common scripting languages (i.e. Perl, Tcl,
Python and to some extent Guile).
As I see it, the approach of SWIG, which tries to parse as much as
possible out of the existing C/C++ headers, and only relies on
seperate annotations where necessary, seems the most useful approach
for the front-end. I haven't looked deeply enough into the back-end
structure of SWIG, but I'd guess that using SWIG to produce FFI code
for the usual CL implementations shouldn't be that much of a problem
really.
So those who are constantly complaining about the lack of a
standardized FFI, might be better of hacking SWIG, IMHO. I haven't
yet had the need for such a tool in CL, since I prefer to use very
minimal interfaces to C code, where the time needed to handcode the
FFI code is a very small fraction of the time needed to create good
interfaces. That approach is not always possible, though.
Regs, Pierre.
--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Jon S Anthony
>
> You may consider ORBs like CORBA a kind of standard FFI
IMO, ORBs are really the most flexible and simplest way to go for this.
This is even true for various pieces of your application written in
the same language. Most ORBs (certainly ORBlink from Franz) have
enough smarts to bypass any network stuff when the objects are
in the same image.
Further, there are plenty of free ones around for things like Java,
C/C++, Perl, etc. We've used several for several of these and things
just work. The Lisp ORBs are generally simpler, much easier to use,
conform more to the IDL spec, and much more robust than things like
MICO, OMNIOrb, Visigenic, Orbix, JDK's Orb, etc., but they are all
readily useable on complex system interfaces (btw, yes, I pretty much
like the mapping that Franz produced - a few simple things were changed
due to some of my requests, but basically it is quite nice.)
The ORB approach is actually quite similar in spirit to Erik's idea
of just generating all the necessary bits. Java writers push a button
and work in Java, Common Lisp programmers push a button and work in
CL, etc. In the end, the pieces all work together, and pretty
seamlessly. Also, it is reasonably straightforward to build a
thin bridge between your CORBA interface on one side and COM crud
on the other. We've done this too. So, at the end of the day if
someone really wants to cobble some VB application specific UI
together that interacts with our CL server, they can. Our standard
UI is written in Java (which has its ups and downs...). Other UIs
have been built with C++. All work seamlessly (all at once for that
matter) with our server
Of course you get the added benefit of not having some (just waiting
to segmentation fault/null-pointer access) goofy foreign code crash
your system.
>, BTW. I don't
> think there is much future in those kind of things, though.
Judging by the turn outs at OMG meetings, I would beg to differ.
Judging by the real success of using this stuff I would certainly
hope you are in error.
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
Kenneth P. Turvey
Martin Cracauer <crac...@bik-gmbh.de> wrote:
[Snip]
>
>You may consider ORBs like CORBA a kind of standard FFI, BTW. I don't
>think there is much future in those kind of things, though.
>
You may believe that ORBs are a bit bulky for many applications, and
that they need some more refinement, but you don't think they are going
to disappear any time in the near future, do you?
If so, why, and what will replace them?
--
Kenneth P. Turvey <kt-...@SprocketShop.com>
--------------------------------------------
Ninety percent of the politicians give the other ten percent a bad name.
-- Henry Kissinger
Patrick Tufts
<mato...@iname.com> wrote:
> Automatic FFI generation from C++ header files is far from trivial.
However, it can be done. SWIG, for example, generates Python and Perl
FFIs to C and C++ automagically.
--Pat
Fernando D. Mato Mira
Sure. But it doesn't do templates. Neither did LispWorks nor ILOG Talk.
[Neither does any reverse engineering CASE tool I've tried, either.]
One prob I see with SWIG is that it's implemented in
C++ and instead of reusing the available parsers/grammars yet another
(incomplete) one has been crafted.
[Hey, but if it does the job for you, go for it]
Note that you shouldn't need to read an extended syntax. Two separate
ones yes. You're
not supposed to reannotate your header files every time a new release is
made.
It would be nice if one could designate an annotation root so that for
each header file
path, an annotation file root/path is automatically searched for an
included, if it exists.
[Maybe it already does. Otherwise seems like a good candidate for an
RFE: useful and easy to implement]
The current maintainer of PCCTS seems to be looking for a job
(http://www.polhode.com/pccts.html),
but the author has moved on to www.antlr.org, which should appeal a
little bit more to the Lisp crowd.
Tim Bradshaw
> You may believe that ORBs are a bit bulky for many applications, and
> that they need some more refinement, but you don't think they are going
> to disappear any time in the near future, do you?
> If so, why, and what will replace them?
This is comp.lan.lisp, we know the answers to these questions here!
Something even worse will replace them, because worse is better.
--tim
Marc Battyani
Tim Bradshaw <t...@cley.com> wrote in message
news:ey3ln4k...@cley.com...
It's already on the way with things like XML-RPC, SOAP, etc.
I'm not sure it's worse though, but it's definitively more "lite".
http://msdn.microsoft.com/workshop/xml/general/SOAP_V09.asp
http://www.xml-rpc.com/
Marc Battyani
Martin Cracauer
>On 16 Feb 2000 08:55:18 +0100,
>Martin Cracauer <crac...@bik-gmbh.de> wrote:
>[Snip]
>>
>>You may consider ORBs like CORBA a kind of standard FFI, BTW. I don't
>>think there is much future in those kind of things, though.
>>
>[Snip]
>You may believe that ORBs are a bit bulky for many applications, and
>that they need some more refinement, but you don't think they are going
>to disappear any time in the near future, do you?
I don't think they will disappear, but I believe that their usage will
not grow as much as ORB advocates think.
The higher-level (Application Library) CORBA interfaces have stopped
development quite some time abo, apparently surrendering to the
applicable Java-only things. When this happend, there were some
comments on the bigger new Web Sites about the issue, you may want to
look them up.
A famous quote from such a comment (sorry, forgot by whom) was
"towards interoperability standards, not portability standards". This
pretty much expresses my opinion about the issue. Taken concrete this
means we will implement network protocols and parse data layout
standards in the language we prefer.
There is some work undergoing in network protocols and data layout
specifications that makes exactly this task easier. http for network
and XML for data are ASCII - based, a big help for reimplementing from
scratch. Also, both are easy to use when you want simple things and
get harder to parse for complicated things than more well thouugh-off
data format. I don't say that is good, I just say it supports the
direction I indicated.
On a completely different note, I think that any constraints in the
exact network protocol used are bad for today's and tommorrows network
applications. Even the simple requirement for non-overlapping replies
to ORB requests is very heavy. The overhead of IIOP is as well.
In my opinion, network bandwidth and - even more important - network
latency develop slower than the need for them. You just need maximum
efficiency.
You also want maximum flexibility in your network protocol. For
example, for use in firewalled environments. If your client and server
pair is constraint to use UDP, you need coorperation from a firewall.
If your hosts are constraint in that they use TCP, but the client must
connect the server, and not the other way round, you are constraint by
the firewall that may not let you set up TCP directions in the
direction you want. A modern networked application must not rely on
more than one or few simple byte streams, and it must support opening
them in any imaginable way.
This is not easy to do in CORBA. In IIOP you don't have it and when
you design your own protocol you give up much interoperability and you
can't use standard CORBA setup procedures anymore.
I also fear the complexity of CORBA. Bugs in your ORB will cause a lot
of headache.
Most people say that reusing well-tested modules or tools is
preferrable to implementing everything for yourself. I have to say
that this did not proove right for me in the last years. The general
tools are more general and complex. Their complexity is so much higher
than the complexity of my direct selfmade implementations that the
advantage has turned into a disadvantage several times. I won't even
start on the speed differences. For normal libraries, this is not a
big issue, as you can usually replace them with a different
implementation quite easily. If you're fixed to an ORB, you cannot
replace it by yourself, it is too complex. If you used cl-http and
something breaks, you can work around it or fix it much easier.
When I read "towards interoperability standards, not portability
standards", I suddenly knew what I was thinking. BTW, if you do
reserach and find the source of the quote, I would be grantful if you
dropped me a line, I feel the need to give proper credits. Thanks.
To answer your question directly: I don't think anything will replace
CORBA. I say we will stay on a lower level and instead grow
language-specific libraries like cl-http and our own part replacements
for things we don't like about the libraries.
Happy Lisping
Martin Cracauer
>When I read "towards interoperability standards, not portability
>standards", I suddenly knew what I was thinking. BTW, if you do
>reserach and find the source of the quote, I would be grantful if you
>dropped me a line, I feel the need to give proper credits. Thanks.
Found it myself, it's on http://www.objectwatch.com/Issue_19.htm
Eric Marsden
[trend from CORBA to simpler XML-RPC approaches]
mc> In my opinion, network bandwidth and - even more important -
mc> network latency develop slower than the need for them. You just
mc> need maximum efficiency.
But the lightweight networking protocols you mention (XML over
HTTP stuff like SOAP) are much more bandwidth-consuming than CDR over
IIOP! Also, since CORBA is able to optimize invocations to in-process
objects into procedure calls, it should provide better average latency
than XML-over-HTTP (given that for remote calls latency should be
equivalent).
mc> I also fear the complexity of CORBA.
CORBA is complex because it addresses many difficult problems:
* location transparency
* server migration
* interface evolution
* service discovery
* bindings for many different programming languages, including CL
[hop, on-topic :-]
XML-over-HTTP is simple because there's nothing there. Most
non-trivial applications will need to address these sort of problems;
IMO it is much better to use proven approaches and components than to
invent ad-hoc partial solutions. Isn't that the CL philosophy?
mc> If you're fixed to an ORB, you cannot replace it by yourself, it
mc> is too complex. If you used cl-http and something breaks, you
mc> can work around it or fix it much easier.
if you are dissatisfied with an ORB, you can switch to another one
without requiring extensive modifications to your application. It is
unfortunately hard to find a replacement for CL-HTTP.
--
Eric Marsden