From b2707494cd338a0d1b889921f0095399d8de42e6 Mon Sep 17 00:00:00 2001 From: Sean Whitton Date: Tue, 16 Mar 2021 18:21:51 -0700 Subject: 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 --- doc/ideas.rst | 8 -------- 1 file changed, 8 deletions(-) (limited to 'doc/ideas.rst') 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 ------------------- -- cgit v1.2.3