> Why have we so much scheme in gEDA? Back when Ales was architecting the gEDA suite, he make gschem the GUI program which allowed one to draw a schematic. It only held the concepts of graphical objects like line, arc, net segment, text, etc.
He created a separate program, gnetlist, which held all the circuit and electronic knowedge. gnetlist's job is to take the graphical drawing of the circuit, and translate it into an electrical netlist. He architected gnetlist in a particularly intelligent way: The core of the program, which reads the .sch file and creates an internal representation of the actual circuit was written in C. He created hooks to a scriptable back-end which allowed the *user* to write any netlist format he wanted. The back end is handed the internal representation of the netlist, and it's up to the back end to translate that representation into the text format suitable for the next tool in the chain. The text format might be a SPICE netlist suitable for simulation using a SPICE circuit simulator, or the text format might be an Allegro netlist used to create a PCB layout using Allegro, or it might be something else. (Most commonly, users who wanted to do layout using the open-source program PCB had to use a couple of different back-ends to create the correct files to read into PCB. This is more of a PCB issue than a problem with gnetlist. Since many users had problems figuring out how to do that, Bill Wilson created gsch2pcb, which basically invokes gnetlist a couple of times using a convient command-line tool.) The decision to separate netlisting from schematic capture is a good one, since it makes gschem a drawing program [1], and gnetlist the thing which deals with electrical knowledge. The decision to make gnetlist have a scripted back-end is a *great* one, since it allows any user to customize gnetlist's output for his own purposes. OK, so why Scheme? When Ales was architecting all this stuff, the only way to embedd a scripting engine (interpreter and so on) into a C program -- allowing the scripting language and C to communicate in two directions -- was to use guile, which was GNU's scripting language at the time. guile is a Scheme interpreter, so that's why we have Scheme. As for why the GNU project choose Scheme as the embedded scripting language, that's probably because Scheme (and earlier Lisp) were pushed heavily at MIT, and are very popular with the programmers under the influence of the MIT computer science department. (Think about the classic "Structure and Interpretation of Computer Programs" book [2]. It's all in Scheme.) Therefore, Scheme became the GNU project's scripting language, and from there it made its way into gEDA. I should also add that gschem also uses guile to process the config files like gafrc. The config files are actually written in a format easily parsed and executed by a Scheme interpreter. The reason for this is that guile offered an easy solution to the problem of implementing a parser for reading and parsing config files. Also, folks working on gschem have expanded the use of Scheme to also use it to creat customizations and extensions to gschem's functionality. Therefore, there's a lot of Scheme in gEDA. > I know that scheme may be useful for scripting/extending gEDA. (Today > many people may prefer more modern languages like Ruby, Python,...) > But large integral parts of gEDA software is done in scheme? Is scheme > so much more powerful than C? Many people hate scheme/guile -- since > some days I am one of these, trying some hours to get gwave2 to work on > gentoo, without success. I really wonder why gwave needs scheme. Some > (german) people really wonder why gEDA config files are scheme. Contrary to your point about "modern scripting languages", Scheme itself is a beautiful and extremely powerful language. You can do things in Scheme which you can't do in any other language. Also, the interpreter can be very compact and simple. That's a good thing when it comes to embedding an interpreter into a larger program. The combination of simplicity in the Scheme interpreter's implementation and the power of the language is why using it for gEDA was a very good decision. IMO, if there is a problem with scripting in gEDA, the problem is that the guile developers (and not the Scheme language) have created problems for us repeatedly. Specifically, they have moved the API many times, breaking gEDA every time they spin a new guile release. Also, they have embedded all kinds of libraries into their implementation which become required dependencies, leading to dependency hell for folks who want to build gEDA from source. IMO, the solution to the guile problem is to simply take control and use our own interpreter, maybe including the TinyScheme source into libgeda, or something like that. However, I understand that others don't want the discussion to go in that direction, so I'll leave my point at that. So why don't people like Scheme? Here's my opinion: 1. There are lots of folks who whine about learning another language. "I already know TCL, so why should I learn Scheme?" As John Doty says, this attitude stinks. It implies that the person with this attitude doesn't want to learn, which is a terrible attitude for a practicing engineer. I ignore those people since they whine about gEDA, but don't actually contribute code. 2. Some people think Scheme is hard. It's not. It *is* a functional programming language (as opposed to a procedural language), so it requries the programmer to think in a different way than the usual "step 1, do this, step 2, do that" way they are probably used to. But once you (quickly) get the concept of how to think in Scheme, it's pretty easy to use since the syntax is very regular and simple. Think of it as the difference between the old TI calculators and the old HP calculators. The TI calculators used straight infix notation when entering a calculation, but the HP calculators used RPN. Many folks couldn't wrap their heads around RPM, but those who did found HP calculators to be be easier to use and more efficient than those from TI. BTW: The fact that Scheme is a functional programming language is the reason that it's an excellent choice for generating text netlists from the internal representation of a netlist in gnetlist. I won't elaborate, but its a fact. 3. Some people are confused by Scheme's many parentheses. It is true that poorly indented Scheme code can be hard to read, but the same is true of obfuscated Perl, or any poorly structured program. And FWIW, the netlists implemented by Scheme back-ends in gnetlist are generally well written and easy to understand. Nowadays, 10 years after gEDA was started, there are other interpreters & languages available which one might think about using instead of Scheme. However, since nobody has actually stepped up to embedd one of those other interpreters into gEDA, we continue to use Scheme. Also, we have over 20 different netlisters written in Scheme, some of them quite advanced. Finally, folks like John Doty who have actually bothered to learn Scheme have created very interesting and useful netlisters for gEDA using it. Also, I should note that there are probably two uses of a scripting language for gEDA: 1. Use as the thing to create netlists via a gnetlist back-end. 2. Use as a language one can use to automate various actions in gschem. This is probably closer to the way Eagle users think about scripting Eagle. IMO, Scheme is an excellent language for use 1. Other languages aren't really suited to creating netlists as easily. As for use 2, well I can see that some folks might prefer another language (like TCL) as schem's language to automate actions. Since a Scheme interpreter is already bundled into gschem for free (via libgeda), some developers want to use it for this task too. OTOH, if somebody actually stepped up and added a TCL interpreter to libgeda (i.e. instead of whined about it), then it might quickly grow a large array of functionality, which would be nice. Meanwhile, folks who want a scripting language for task automation (use 2) are free to use Python, Perl, or whatever they want to process .sym and .sch files written in gschem's open, text-based file format. I hope this clarfies this issue a little bit. Regards, Stuart [1] Personally, I think this decision is showing some limits, as you can see from all the ongoing discussion about how to deal with slots, attributes, ad nauseum. Those problems were not foreseen at the time gEDA was originally envisioned, and that's OK since they did not appear until folks started trying to do advanced things with gEDA. However, I don't have any intelligent proposals about how to handle these issues. [2] http://mitpress.mit.edu/sicp/ _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
