Re: lgtk-0.0.3 - experimental gtk bindings for Common Lisp

Hi;

On Monday 03 November 2003 12:08 pm, Mario Mommer wrote:
> Aha - Which Lisp-like language? Which bindings? I'd like to take a
> look.

STELLA (STrongly TypEd Lisp-like LAnguage) -- compiles to any of
Common Lisp, Java, and/or C++.  I am having to do a lot of
code-generation for delivery in C++, and it is easier to generate
S-expression type code and use the STELLA translator, rather than
trying to generate the C++ directly.

> My thoughts on this are that there is some wisdom in choosing fights
> you can win, and so I think that in most circumstances it is not very
> wise to try to parse C/C++ headers, and then trying to understand
> whatever you get. :-)

Even the "Chinese Army" approach can fail on a suitably intractable,
moving problem, I suppose.

> As an alternative, I like the probing approach from sb-grovel better:
> produce c/c++ probes that print out the info you want, do what you
> can't achieve this way either by hand or by ad-hoc glue generation.

The C++ software I am trying to "bind" to or call is very, very, very
large (in terms of SLOC).  Certainly well over 1MSLOC.  Thus, I was
trying very, very hard to automate the process.  Aside from the
obvious difficulties, "ld" (or linking time) for building an
application can be measured in minutes rather than seconds.

I confess to being unfamiliar with sb-grovel.  Do you think
sb-grovel's "try it" approach would scale to this kind of problem?

> I've heard from people trying to use gccxml that it disregarded so
> much vital information (I don't remember the details) so that it was
> essentially useless for this. But things might have changed, so don't
> hesitate to find out and tell us ;-)

Eeek.  Is it possible to obtain a URL to the discussion?  I would like
to spare myself a Don Quixote style bout with a windmill, if indeed
gccxml is a futile approach.

> Another issue is that you want your bindings to make sense to language
> users, and this means that you want to at least to take a look at it
> and redo some interfacing decissions. An example might go like this:
>
> int some_function (char *fname);
> int another_function (char *str);
>
> You want a different wrapper for the first one (that is able to cope
> with cl pathnames) than for the second. You will need some fairly
> advanced AI if you want this to happen automagically (and correctly!).

Well, I would rather try to write that kind of smart code in Lisp
(say, after interning a rather large amount of XML in Lisp data
structures) rather than C++ (say, in a SWIG back-end, or in a C++ XML
program).

> An alternative to that might be to have some infrastructure that
> allows you to add functionality in a few easy steps. That is what I
> have tried to achieve in lgtk, and for me it works nicely.
>
> I have that vision of GUI with two text fields and a few buttons. I
> paste some piece of a C header into one text field, and it produces
> some lisp that it thinks is the correct binding. I may have to edit it
> slightly, but after pressing another button, it is in the lib ready to
> be used. Something like this should make it possible to write very
> nice interfaces that feel native with a moderate amount of effort.

Hmmm... If there is a way to minimize the likelihood of carpal tunnel
syndrome, I would like to know how.

I just wish that there were return value information stored in the
object files.  If there were, a ridiculously simple script using the
output of "nm" would suffice.  So near, and yet so far...

Thanks for the advice!

-jm

-- 
==== John Morrison
==== MAK Technologies Inc.
==== 185 Alewife Brook Parkway, Cambridge, MA 02138
==== http://www.mak.com/
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== [email protected]