On May 29, 2011, at 12:01 AM, Dave McGuire wrote: > This is my opinion, speaking as a professional developer of both hardware > and software: Scheme was a good choice for gEDA, and it should be left alone. > The chosen implementation of Scheme, guile, may not be the best tool for the > job right now, but the language is.
Abandoning Guile for this job means abandoning nearly all of the core code in gnetlist, because that's written in C, and uses Guile's FFI. That is a possible way to proceed. A rewrite of gnetlist in straight Scheme (which is certainly possible) would free us to choose a Scheme implementation. But who's volunteering? On the other hand, the totality of what we're discussing is also beyond gnetlist's capability as written. We can translate package attributes easily, but trickier mappings will be messy at best, and annotation is impossible. Given how much trouble fixing the attribute censorship bug was, refactoring the gnetlist we have now to adequately broaden its capability to allow it to address these issues seems likely to take years. So, one way or another, we're looking at a new tool, I think. Maybe we keep the old gnetlist around and feed it modified/annotated schematics. > > There will always be people who don't like a particular choice. That's true > of anything. All changing it will accomplish is changing who is pleased and > who is disgusted. I'm with DJ here: contributions will decide. The language doesn't matter so much to me. The big issue here is that our tool, gnetlist, hides much of the design data behind its API. This makes general-purpose design translation tricky, and annotation impossible. So, the first challenge to the various language advocates here is to prototype a fundamental API that reveals all, in a way convenient for higher level factors to exploit. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
