gEDA-user: Switch gschem to another scripting language?

[Stuart Brorson <sdb@xxxxxxxxxx>]

> 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
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user