diff options
| author | Sean Whitton <spwhitton@spwhitton.name> | 2021-03-16 18:21:51 -0700 |
|---|---|---|
| committer | Sean Whitton <spwhitton@spwhitton.name> | 2021-03-18 09:54:42 -0700 |
| commit | b2707494cd338a0d1b889921f0095399d8de42e6 (patch) | |
| tree | a9d19f68125f9ba040cbaa6707cf334cdfcf4729 /doc/ideas.rst | |
| parent | 36de7faaf8a3368d5616f310fac7465c12b9c916 (diff) | |
| download | consfigurator-b2707494cd338a0d1b889921f0095399d8de42e6.tar.gz | |
now we have DEFPROPSPEC, drop idea about DEFPROPLIST defining macros
In fact, there are at least some cases where having DEFPROPSPEC define a macro
would be less flexible than the current approach. For example, suppose what
we want is for one of the arguments to a property defined with DEFPROPLIST to
be evaluated and then passed as an argument to a property combinator, but
outside of a propapp. If DEFPROPSPEC defines a macro, then after
macroexpansion this argument will not appear inside a propapp, and so in the
evaluation of DEFPROPLIST's unevaluated propspec, it will not be evaluated.
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
Diffstat (limited to 'doc/ideas.rst')
| -rw-r--r-- | doc/ideas.rst | 8 |
1 files changed, 0 insertions, 8 deletions
diff --git a/doc/ideas.rst b/doc/ideas.rst index bd55de0..c2996fa 100644 --- a/doc/ideas.rst +++ b/doc/ideas.rst @@ -65,14 +65,6 @@ Core But maybe this is unnecessarily complex -- wouldn't it be better to just fail and fix your deployment definitions? -- It's not clear that the current implementation of DEFPROPLIST can support - everything we might want to do with it. An alternative approach to try out - would be for a call to DEFPROPLIST to expand into a macro definition, where - the new macro expands into the properties to be combined with DEFPROPLIST, - surrounded by ESEQPROPS. Calls to this new macro can then just be added to - propspecs by users. So in effect we would have a macro which can be used in - place of a propapp. - Project & packaging ------------------- |