EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Macro names
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Fri, 16 Aug 2002 22:22:02 +0200
Andrew Johnson wrote:
> 
> A couple of questions about macro substitution in database files that I
> need to check before I define some changes that could adversely affect
> some EPICS sites:
> 
> 1. Does anybody currently use macro names that have funny characters in
> them?  The EPICS macro library allows almost any character to be used in a
> name right now, but I'm thinking of significantly restricting this in
> R3.15 (and within VDCT) to allow only alpha-numerics and underscore
> [a-zA-Z0-9_] characters in the macro name.  Macro values will obviously
> still be able to contain any character.  Any complaints, or requests for
> additional characters to be added to that list?
> 
> 2. Does anybody actually use the facility whereby macro names can
> themselves be constructed using macros? - eg $(xx$(y)_$(zz))  I'm not
> threatening to change this, just interested to hear if it's actually
> useful.
> 
> I'm in the process of defining how hierarchical templates should work for
> VDCT, and I need to add some syntax to macro names so templates can be
> usefully modular.

IMHO, the whole macro substitution mechanism is a conceptual mistake. It
is a low-level approach (plain text substitution) on top of a structured
and statically typed one (record instances and record types). All the
widely known problems with database templates and macro substitution
result from this. Generating higher levels of abstraction (typically
device oriented) should build on top of the field, record and recordtype
concepts, and therefore use high-level methods which preserve and extend
the low-level (signal oriented) record database structure.

One important step to get there is the new link support which breaks up
the monolithic one-string approach to device addressing and database
links.

We need to replace the concept of database template file by some sort of
meta-recordtype; and macro substitution by some sort of instantiation of
these meta-recordtypes to meta-records. With structured (and
compile-time checkable) renaming and aliasing of low-level features
(fields) to meta-features.

Just my two pence.

Ben

Replies:
Re: Macro names Peregrine M. McGehee
References:
Macro names Andrew Johnson

Navigate by Date:
Prev: RE: Macro names Redman, Russell O.
Next: Re: Macro names Peregrine M. McGehee
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Macro names john sinclair
Next: Re: Macro names Peregrine M. McGehee
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·