[Openmcl-devel] another make-record question

[mikel evins]

On Aug 20, 2004, at 10:28 AM, Cyrus Harmon wrote:

>
> On Aug 20, 2004, at 9:16 AM, Gary Byers wrote:
>
>> Consider a scenario where this is called in a standalone application.
>> Should the author of that application be required to distribute the
>> interface database with the application ?  (That's not illegal or
>> immoral or anything, and to some extent it's also a rhetorical
>> question.)
>
> While the OpenMCL interface database stuff is incredibly cool and 
> useful, this does bring up some issues that I've been grappling with a 
> little bit. I've never really like the idea of "the interface 
> database". Just for some background on what I've been doing, I've been 
> trying to call the vImage framework from LISP code, with an eye 
> towards other frameworks and libraries. One of the neater (to me) 
> things I've discovered in doing this is that I don't need to go and 
> much with "the interface database" and that through some clever usage 
> of logical-pathnames and I can take my own .cdb files, place them 
> wherever I need them and get the interface machinery to give me #_ and 
> #$ access described by the .cdb files without having to touch the 
> OpenMCL internals. Back to the somewhat rhetorical question. If we're 
> going to require access to the shared library (of course) at runtime, 
> is it really that much worse to require access to the .cdb files? This 
> information has to live somewhere and it can either get compiled in 
> via macro magic or we can distribute it with the application. Doesn't 
> seem to make too much of a difference to me, as long as it con be 
> distributed in a nice clean way.
>
> There is another issue of efficiency in that we can get some of this 
> stuff out of the way at compile-time, which is probably a good thing, 
> but I go back to the idea of the registration at macro-expansion time 
> as a way to do this.

I'm pretty interested in this whole line of thinking. At present, I'm 
building Clotho with the interface databases copied into the 
application bundle. I adjust the appropriate pathnames when the 
application starts up so that wherever someone installs Clotho, calls 
to foreign functions and references to foreign types will work 
appropriately.

This approach seems completely reasonable for Clotho, which is, after 
all meant to be a development environment. It's natural to build the 
interfaces into it because a user might want to make arbitrary calls 
and reference arbitrary foreign types.

However, I'm certainly going to want to build other applications that 
are not meant to be development systems and ideally should not tack 7 
MB of interface databases onto the application bundle in order to be 
able to run. So I'm interested in finding a method of statically 
resolving the interfaces that the application actually uses and 
building the result of that resolution into the app.

The fact of the matter is that I haven't yet made the time to 
understand the issues well enough to know whether any solution more 
comfortable than including the interface databases is practical, but 
I'm certainly interested in the discussion as a step in my 
self-education.

--me