[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Reinventing the wheel

On May 18, 2011, at 1:56 PM, Stefan Salewski wrote:

> The problem in not only missing documentation, but the fact that not all
> geda guile code is really clean and beautiful, as stated by one of the
> experts some time ago on this list. I don't know if that is true, but I
> have seen that even experts had to work hard to make small improvements.
> I think that learning lisp/scheme/guile is an interesting (academic)
> task. But I think that gEDA is not a really good point to start
> learning, because: 1. the C-guile interaction and 2. the risk of
> breaking something.

The prevailing style for gnetlist back ends has several problems:

1. The near-universal use of recursion for iterating over lists. In most cases, the code is executed for side effects, typically output. For those cases (for-each) is a much simpler and clearer construct. (map) may also be useful in other cases. Recursion is a cool theoretical idea, but in practice it should be a last resort for when simpler iteration constructs don't work cleanly.

2. Excessively long functions. These are hard to read, hard to debug, and hard to maintain. A good scheme function is so simple it's almost trivial. Scheme allows procedural programming, but clumsily: one should prefer functional composition in most cases.

3. The use of (display) where (format) is more reasonable. I used to favor (display), but Peter B. dragged me kicking and screaming to (format). Thanks, Peter.

Last year, I rewrote my Osmond-PCB back end based on these ideas, and I think the new version is much simpler and clearer. I submitted it as a patch, but it hasn't made it to release yet. I think it illustrates just how good the gnetlist API is for flat PCB-oriented netlist generation: the back end receives the data in very conveniently digested form.

Attachment: gnet-osmond.scm
Description: Binary data

John Doty              Noqsi Aerospace, Ltd.

geda-user mailing list