Re: VDCT expand and template constructs

[Andrew Johnson <anj@aps.anl.gov>]

Benjamin Franksen wrote:
> > expansion syntax may also include a default value, in the form
> > $(name=value). The default is used if no macro by that name is found.
>
> and later
>
> > I don't like your idea of trying to separate out what you're calling
> > a "port macro" and a "string substitution macro" - I assume the
> > latter is intended for expansion only in a dbLoadRecords() statement.
> > I don't think you can make this kind of distinction though; in some
> > cases the template may have all its macros expanded on the host by a
> > parent.vdb file, and in others the same template parameters may be
> > provided to dbLoadRecords().
>
> which is somewhat contradictory, I'd say. In the second paragraph you 
> give a very good reason why retaining an undefined macro makes a lot of 
> sense (i.e. because I might want to give a value only later e.g. in the 
> startup file). Or do you propose that in every such case eitehr the 
> template has a definition a la $(name=$(name)) or the substitution must 
> be name=$(name)? That would be boring, wouldn't it?

Actually I don't think there can be any difference in the macLib output 
between $(name) and $(name=$(name)) whether the 'name' macro is defined 
or not, since the default value in the latter version is itself subject 
to macro expansion.  The usual behaviour for macLib is not to expand 
macros that are undefined, leaving the macro syntax in place; I believe 
that VDCT maintains this behaviour (Nick mentioned this IIRC).

The default value substitution is really only useful to the immediate 
parent of a template that makes use of it - the only way to override 
such a default value is to have the named macro defined by the parent. 
I don't see a major contradicition here though, just a feature with 
limited usefulness.

Kay-Uwe Kasemir wrote:
> On Dec 16, 2005, at 17:59 , Andrew Johnson wrote:
>
> > > these are subtly different. If a port macro is not resolved then it
> > > shouldn't be an error, I believe it should be treated as if it never
> > > existed in the first place.
> >
> > I strongly disagree.  If a parent diagram is trying to use  
> > information from a port that a template it's expanding doesn't  
> > actually define, then the parent diagram is wrong and this should  
> > cause an error at instantiation time.
>
> I think the naming of these 'text' or 'port' macros isn't 100% clear.

I agree that the term 'port macro' could be confusing; I was quoting 
Nick's message above, and try to avoid using it myself.

I use the term 'macro' to mean a $(name) substitution, the value of 
which is set from above; and 'port' to mean a $(instance.name) 
substitution, the value of which is set by the 'instance' template 
expansion below.  The latter differs somewhat from a 'port' on a 
hierarchical electronics schematic, but nobody complained about this 
when we were defining the hierarchical syntax in 2002 and the words 
'port' and 'macro' are part of the syntax implemented in VDCT now.

> When we compare this to circuit diagrams
> or IC pinouts, there are 'input' and 'output' ports.

Comparing EPICS databases with circuit diagrams doesn't work too well in 
this case, because in EPICS the wires are being used purely for text 
substitution.  If you think about information flow in the template 
expansion process then a 'port' is always an output from a template and 
a 'macro' is always an input to one, but that has no relation to the 
direction that data flows through a link that is configured using a 
port/macro substitution.  If we have a link that crosses a hierarchy 
then whether we use a port or a macro merely depends on which .vdb file 
owns the record that contains the link, irrespective of whether the link 
field itself is an input or an output.

- Andrew
--
* * Matt Santos / / For a Brighter America * *