Re: gEDA-user: merge multi symbol components

[John Doty <jpd@xxxxxxxxx>]

On Jul 22, 2009, at 10:05 AM, Kai-Martin Knaak wrote:

> On Wed, 22 Jul 2009 08:23:40 -0400, John Doty wrote:
>
>> I'm unhappy that you're putting another complex, opaque, inflexible
>> mechanism into the gnetlist *front* end. Put hooks into the front
>> end, yes, but leave the back end in control, with default behavior
>> defined in gnetlist.scm.
>
> Talk about opaqueness and complexity. With its lack of types,
> declarations and explicit return values scheme is anything but
> transparent to the casual hacker. Add to this the abundance of heavily
> nested parenthesis and result is black-box magic to the uneducated  
> eye.

But Scheme is *simple*. So the uneducated eye is easily educated.

> By the way, in gnetlist.scm I find procedures commented only with:
>
> ;; this is really crude, but I'm tired... :)
> (...)
> ;; ah.. wonder what use this is...
> (...)
> ;; ha. I'm playing with scheme here.. don't mind me

True. But the procedures so commented are trivial and transparent.

>
>
>> Keep gnetlist flexible for the future: don't stiffen it to
>
> I don't "stiffen" anything.
> gnetlist already considers symbols with the same refdes to  
> represent the
> same physical device. This is, of course, in accordance with the  
> official
> description of the meaning of redes in the master attribute list.  
> What I
> work on, is to make sure, that the result does not depend on  
> invisible,
> inaccessible subtleties like the order of symbols in the *.sch  
> file. In
> particular
> Such quasi random behavior does not represent flexibility but a bug.

As you know, I agree that it's a bug. But given that the correct  
behavior may depend on the project flow, the back end should be in  
control. And *you* brought up the question of whether your solution  
would affect other flows. That you merely asked is an indication that  
you're not sure about their needs. That's wisdom, but you need to  
apply it: don't put in unnecessary rigidity.

>
>
>> make it work just in *your* scenario.
>
> I am unhappy with you implying shortsightedness of about everybody on
> this list, including me. This makes me feel hostile towards your
> opinions.

It worries me that people are wiring their scenarios into the tools,  
when gEDA's unique strength is its flexibility. This isn't limited to  
gEDA: it seems to be a programming universal that people feel  
obligated to turn simple, flexible toolkits into bloated, inflexible  
"applications".

See:

http://harmful.cat-v.org/cat-v/

>
>
>> The front end code is rather difficult and opaque, as you've  
>> discovered.
>
> Not where I am looking at.

You wrote:

> Some items in this definition seem opaque to me.
> What is the property "nlid" used for?
> What is the meaning of the boolean "composite_component"?
> What are the possible values of the "hierarchy_tag"?

And I completely agree that this code is difficult to understand. I  
must have 1000 times more experience with C than I have with Scheme,  
yet the Scheme code here is easier.

>
>
>> But the back ends, with just a tiny bit of Scheme knowledge, are  
>> pretty
>> transparent.
>
> So, you propose to work around a bug in the front-end by  
> modification of
> the majority, if not all back-ends.

No, I wrote:

> leave the back end in control, with default behavior
> defined in gnetlist.scm.

In this approach, no back end would need modification unless it had  
needs incompatible with your approach. An existing example is the get- 
uref mechanism.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user