Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 19 Dec 2005 15:40:55 -0600

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 * *

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System