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 Cc: geda-user AT delorie DOT com Subject: Re: [geda-user] Parameter substitution References: <98D1C4E4-581D-4A03-94E4-E0330960EADF AT wellesley DOT edu> Date: Sun, 24 Jul 2016 00:20:46 +0200 In-Reply-To: (Roland Lutz's message of "Sat, 23 Jul 2016 22:56:19 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 Precedence: bulk Roland Lutz writes: > On Sat, 23 Jul 2016, Stephan Böttcher wrote: >> Roland Lutz 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 ) $(system ) $(lookup key, ) 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