delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/07/23/18:22:34

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
From: geda AT psjt DOT org (Stephan =?utf-8?Q?B=C3=B6ttcher?=)
To: Roland Lutz <rlutz AT hedmen DOT org>
Cc: geda-user AT delorie DOT com
Subject: Re: [geda-user] Parameter substitution
References: <98D1C4E4-581D-4A03-94E4-E0330960EADF AT wellesley DOT edu>
<s6na8h89ydi DOT fsf AT blaulicht DOT dmz DOT brux>
<alpine DOT DEB DOT 2 DOT 11 DOT 1607231941050 DOT 16188 AT nimbus>
<s6na8h843d4 DOT fsf AT blaulicht DOT dmz DOT brux>
<alpine DOT DEB DOT 2 DOT 11 DOT 1607232216030 DOT 1399 AT nimbus>
Date: Sun, 24 Jul 2016 00:20:46 +0200
In-Reply-To: <alpine.DEB.2.11.1607232216030.1399@nimbus> (Roland Lutz's
message of "Sat, 23 Jul 2016 22:56:19 +0200 (CEST)")
Message-ID: <s6n60rwyp1d.fsf@blaulicht.dmz.brux>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u6NMLHhF001910
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

Roland Lutz <rlutz AT hedmen DOT org> writes:

> On Sat, 23 Jul 2016, Stephan Böttcher wrote:
>> Roland Lutz <rlutz AT hedmen DOT org> writes:
>>> I'd guess that, since that's quite a relevant change, the
>>> developers didn't want to just apply it without prior discussion.
>>
>> A discussion that never happend. :-(
>
> So, let's discuss it now.
>
> I think everyone on this list agrees that having parametric
> subschematics would be a nice thing.  

About the semantics of this feature, the only comment I ever received
was from John, who did not like some aspect of it.

> The easiest way to achieve this would be the way you implemented:
> simple substitution.  On the other end of the spectrum, the
> subschematic could contain complex logic which instantiates components
> algorithmically.

${NAME} is simple

Look how that evolved in make and bash.  There is room for future
development ..

> While this sounds great in theory (and may be fun to work on), I'd
> suggest to keep it simple for now and stick to the method both of us
> implemented. As to the semantic differences in our implementations:

That is syntax:

> - I'd suggest shortening the name of the attribute which defines a
> substitution from "parameter=" to "param=".  

I do not like shortenings like this.  The feature is not used often, and
the parameter= part is not normally visible.

 parameter=
 substitution=

Nice and readable.

> Components are probably going to have multiple instanes of them, each
> potentially being a long line, so there is no point in making the
> attribute name longer than necessary. I'd personally prefer calling
> the attribute "subst=" to indicate that it's a simple substitution (as
> opposed to a "real" parameter), but I wouldn't object "param=",
> either.
>
> - I'd suggest using the character "=" to separate substitution name
> and value.  This way, the attributes can be set to "show value only"

"show value only" shows everythinj after the first =  in an attribute,
right?  If you enhance gschem to have a separate switch for visibility
of the middle part, it could as well be a : separator.

> to show a neat list of substitutions for a given symbol.  (Using
> upper-case letters for substitution names and possibly a different
> color for the text objects would minimize the risk of mistaking them
> for regular attributes.)
>
> - As to whether to use "$(NAME)" or "$NAME"/"${NAME}", I've mostly
> been following a gut instinct when going with "$(NAME)".  I've thought
> a bit about why "$NAME" feels wrong for me, and I think it's something
> about context: in places where you use "$NAME" (e.g., shell scripts),

Use $NAME where appropriate, and ${NAME} or $(NAME) when required or
more readable

My use case looks like this:

 value=$RFB

> there's usually all kinds of substitutions going on, whereas in places
> where you use "$(NAME)" (e.g., Makefiles), it's usually the only kind
> of substitution (or other "$" sequences mean different,
> non-substitution things).

in Makefiles,  $A, ${A}, and $(A) are equivalent.  Just like $*, ${*},
$(*).  OTOH, $NAME == ${N}AME

> Therefore, I'd suggest using "$(NAME)".

> I haven't had the time yet to look at your implementation in detail,
> but I hope I'll be able to do so in the next few days.

Thanks!

So there is to review and discuss

1. Semantics

  When to apply the substitutions to what?

  My patch applies the substitutions to all text objects of subsheets
  after the hierachy has been built.  This will pretty obviously fail
  for source= attributes.  

2. Syntax

  I do not care much, but I will keep my own private patch with the
  snytax I have used in the last few years.

   - attribute name  subst(itution) param(eter)
   - separator : =
   - parentheses  $NAME ${NAME} $(NAME)
   - extendability   $(eval <expression>)
                     $(system <shellcommand>)
                     $(lookup key, <filename>)

3. Implementation

  I am not familiar with the gnetlist code.  I was looking for a hook to
  attach the code to, found it, and implemented the substitutions in the
  least intrusive way.  There may be cases/attributes where the
  substitutions do not work, because the attributes are used at
  different times. 


> Roland

-- 
Stephan

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019