On Wed, Dec 29, 2010 at 08:51:19PM +0100, Stephan Boettcher wrote: > John Doty <j...@noqsi.com> writes: > > > On Dec 29, 2010, at 6:23 AM, Stephan Boettcher wrote: > > > >> I can imagine that it's not a lot, since this is really a classical > >> case for said design pattern. > > > > The real difficulty here is the complexity of the Guile<->C > > interface. The functions and data on the C side are accessible to the > > midlayer only to the extent that somebody does the (difficult) work of > > exporting them. The C front end is very procedural, performing much > > semantic processing regardless of whether the back end ever requests > > the results. Not a good match to the factored, functional approach. > > Than that is the interface that needs to be morphed according to the > prescribed pattern: the C<->Guile interface. > > And when that's the case, a clean C-API that can be exported to Guile, > Python, Ruby, C++, Fortran, ... just dreaming.
I once started to do that to PCB usign libgpmi, and got a plugin that exports a small portion of PCB internals through some sort of higher level APIs to any scripting language libgpmi supports (10 at the moment). After scripting 1-2 plugins I really needed, development stalled, as I am the only user of the plugin. I think you'd get the same for a similar project around gschem, as gschem developers already speak guile so having other scripting languages will be interesting only as a theoretical possibility, not as a practical feature. At least, with my pcb-gpmi plugin feedback always was "wow, very nice, very interesting, will try some day". Btw, I still use it weekly, since I have a nice (partial) HPGL exporter written in awk. Regards, Tibor _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user