On Sat, Aug 1, 2009 at 2:37 PM, John Doty<j...@noqsi.com> wrote: > > Hmm, I think Guile is fine for gnetlist's purposes. A minor problem > has been backward compatibility, leading to "dependency hell". The > people who package the distros have this under better control than > they did a few years ago. Python has similar problems.
I'm actually a big fan of functional languages so you don't need to convince _me_ to Scheme. ;-) > The real problem, I think, is that many people get phobic when they > see all those parentheses. But, really, Guile is easy to learn and > easy to use. Well, I see several other problems here as well: 1. Guile (as a Scheme implementation) is not particularly well supported, this leads to "dependency hell" and missing/incomplete wrappers for modern libraries (like gtk2 - not really a problem for gnetlist but an issue for gschem and others), 2. Scheme being a simplistic language. Both Perl and Python come with regexps and easy to use and versatile container types to name a couple of useful features. 3. Scheme not being a main stream language (often misinterpreted as a "parentheses problem"). This makes code written in Scheme not easier to extend than one written in a primitive but well known language. So, from pragmatic POV, I am OK with moving from Guile to something more practical. >> and gnetlist architecture is >> hardcoded in C, > > Yes. Too much is hardcoded into the front end. The front end even > gets in the way of the back end's access to command line options. > Back ends can't see hierarchy. Back ends can't see all attributes. > Now, a lot of back ends don't need to see all that stuff, but that's > what the interface layer (gnetlist[-post].scm) is for: simple back > ends can get the filtered info, trickier ones can reach around to the > front end and get the data they need. The current implementation > doesn't exploit the capabilities of the interface layer very well. > The front end needs to be trimmed back to the minimum, and the logic > moved to the interface layer. > > Hmm. In the gnetlist case, the minimum for the hard-coded part is > nothing: why bother with C at all? Fully agree. The only exception is that part of functionality (reading and interpreting gEDA file formats) could be abstracted out in a form of libgeda library (still the netlister doesn't need to be written in C/C++, just libgeda itself). Regards, -r. _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user