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.)

Muddy

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.

  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.

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

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

  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 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!

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]

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

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

  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?

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."

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

  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.

  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.

[...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

Thanks,

  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.)

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.