Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #6415 > unrolled thread

conditional macro definition also for recursive conditionally limited expansion

Back to article view | Back to comp.std.c

Contents

  conditional macro definition also for recursive conditionally limited expansion Marco Munari <allerta.it@gmail.com> - 2022-01-09 16:52 -0800
    Re: conditional macro definition also for recursive conditionally limited expansion James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-10 00:48 -0500
      Re: conditional macro definition also for recursive conditionally limited expansion Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 07:13 -0800
    Re: conditional macro definition also for recursive conditionally limited expansion Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 07:51 -0800
      Re: conditional macro definition also for recursive conditionally limited expansion Marco Munari <allerta.it@gmail.com> - 2022-01-18 04:24 -0800
        Re: conditional macro definition also for recursive conditionally limited expansion Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-19 06:53 -0800

#6415 — conditional macro definition also for recursive conditionally limited expansion

I thought it could be nice to introduce condition inside macro definition, to produce less jumping code (so compiler can output bigger but more efficient code with concise definition)

a syntax could be defined by adding an optional #defif (due to the late time this could be introduced to C, that would be my preference reminding to who would learn by seeing it that the if is part of the macro definition) as
#define macro(#N,x) #defif (#N>0) macro(#N-1,…) #defelse …

usable with macro(5,x)
expansion parameter that i called #N need to be a constant provided to the expansion engine, the # prefix I indicated here is not a syntax necessity because it can be deduced by the fact that this parameters appears in the #defif condition which also must be fully valuable during preprocessing (just a bit more powerful preprocessing)

or if you prefer instead of #defif a shorter #IF or even #if but inside the line (expandable with \ ending lines)  of a #define pragma, and the correspondent #defelse or #ELSE or #else
the result of the definition has to be a single entity as it is currently, but can be tweaked over the parameters of the macro definition during each expansion

e.g. for something like binary search in batch of direct elaboration without use of stack each batch of depth 5

#define f(N,bt,a) #defif(N>0) (a == bt->val) ? bt : (a < bt->val) ? f(N-1,bt->left,a) : f(N-1,bt->right,a) #defelse g(bt,a)

struct {int val; binarytree *left,*right} binarytree;
int g(binarytree bt, int a) {
  return f(5,bt,a); /* recursive batch dept 5 is stored only here */
}
 would correspond to a very uncomfortable to write and maintain but efficient form

what do you think of the idea?

All the best,
MARco MunARi
— 
x(t),y(t) = th(3t-34.5)*e^[-(3t-34.5)^2]/2-4.3+e^(-1.8/t^2)/(.8*atg(t-
3)+2)(t-1.8)-.3th(5t-42.5),(1.4e^[-(3t-34.5)^2]+1-sgn[|t-8.5|-.5]*1.5*
|sin(pi*t)|^[2e^(-(t-11.5)^2)+.5+e^(-(.6t-3.3)^2)])/(.5+t)+1  ; 0<t<14

[toc] | [next] | [standalone]

#6416

On 1/9/22 7:52 PM, Marco Munari wrote:
> I thought it could be nice to introduce condition inside macro definition, to produce less jumping code (so compiler can output bigger but more efficient code with concise definition)
> 
> a syntax could be defined by adding an optional #defif (due to the late time this could be introduced to C, that would be my preference reminding to who would learn by seeing it that the if is part of the macro definition) as
> #define macro(#N,x) #defif (#N>0) macro(#N-1,…) #defelse …
> 
> usable with macro(5,x)

The committee decided long ago to not allow recursive macros. The
relevant wording is:

2 If the name of the macro being replaced is found during this scan of
the replacement list (not including the rest of the source file’s
preprocessing tokens), it is not replaced. Furthermore, if any nested
replacements encounter the name of the macro being replaced, it is not
replaced. These nonreplaced macro name preprocessing tokens are no
longer available for further replacement even if they are later
(re)examined in contexts in which that macro name preprocessing token
would otherwise have been replaced." (6.10.3.4p2).

The Rationale explains: "A problem faced by many pre-C89 preprocessors
is how to use a macro name in its expansion without suffering “recursive
death.” The C89 Committee agreed simply to turn off the definition of a
macro for the duration of the expansion of that macro."

I doubt that the committee is likely to change it's mind on that matter.

[toc] | [prev] | [next] | [standalone]

#6422

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 1/9/22 7:52 PM, Marco Munari wrote:
>
>> I thought it could be nice to introduce condition inside macro
>> definition, to produce less jumping code (so compiler can output
>> bigger but more efficient code with concise definition)
>>
>> a syntax could be defined by adding an optional #defif (due to the
>> late time this could be introduced to C, that would be my preference
>> reminding to who would learn by seeing it that the if is part of the
>> macro definition) as
>> #define macro(#N,x) #defif (#N>0) macro(#N-1,?) #defelse ?
>>
>> usable with macro(5,x)
>
> The committee decided long ago to not allow recursive macros.  The
> relevant wording is:
>
> 2 If the name of the macro being replaced is found during this scan of
> the replacement list (not including the rest of the source file's
> preprocessing tokens), it is not replaced.  Furthermore, if any nested
> replacements encounter the name of the macro being replaced, it is not
> replaced.  These nonreplaced macro name preprocessing tokens are no
> longer available for further replacement even if they are later
> (re)examined in contexts in which that macro name preprocessing token
> would otherwise have been replaced."  (6.10.3.4p2).
>
> The Rationale explains:  "A problem faced by many pre-C89 preprocessors
> is how to use a macro name in its expansion without suffering 'recursive
> death.'  The C89 Committee agreed simply to turn off the definition of a
> macro for the duration of the expansion of that macro."

IMO this conclusion is unwarranted.  The earlier decision was
about how to deal with unexpected and infinite recursion.  What
is being proposed does involve recursion, but recursion of a form
that is neither unexpected nor infinite.  There is no reason to
expect comments about unexpected and infinite recursion to apply
to macro definitions that are explicitly and finitely recursive.
(Of course there does need to be some sort of limit because any
actual compiler cannot accommodate recursion that is arbitrarily
deep even if still finite, but that is a separate issue.)

[toc] | [prev] | [next] | [standalone]

#6423

Marco Munari <allerta.it@gmail.com> writes:

> I thought it could be nice to introduce condition inside macro
> definition, to produce less jumping code (so compiler can output
> bigger but more efficient code with concise definition)
>
> a syntax could be defined by adding an optional #defif (due to the
> late time this could be introduced to C, that would be my preference
> reminding to who would learn by seeing it that the if is part of the
> macro definition) as
> #define macro(#N,x) #defif (#N>0) macro(#N-1,?) #defelse ?
>
> usable with macro(5,x)
> expansion parameter that i called #N need to be a constant provided
> to the expansion engine, the # prefix I indicated here is not a
> syntax necessity because it can be deduced by the fact that this
> parameters appears in the #defif condition which also must be fully
> valuable during preprocessing (just a bit more powerful
> preprocessing)  [...]

It's an interesting idea.  There are details that need to be
explored and understood first.  Also I think it would be better
if expanded and generalized, perhaps along the lines of 'cond'
in lisp, or alternatively with ?# :# as preprocessing if/else.
Hmmm...

[toc] | [prev] | [next] | [standalone]

#6427

On Monday, January 17, 2022 at 4:51:12 PM UTC+1, Tim Rentsch wrote:
> Marco Munari <aller...@gmail.com> writes: 
> 
> > I thought it could be nice to introduce condition inside macro 
> > definition, to produce less jumping code (so compiler can output 
> > bigger but more efficient code with concise definition) 
> > 
> > a syntax could be defined by adding an optional #defif (due to the 
> > late time this could be introduced to C, that would be my preference 
> > reminding to who would learn by seeing it that the if is part of the 
> > macro definition) as
> > #define macro(#N,x) #defif (#N>0) macro(#N-1,...) #defelse ...
> > 
> > usable with macro(5,x) 
> > expansion parameter that i called #N need to be a constant provided 
> > to the expansion engine, the # prefix I indicated here is not a 
> > syntax necessity because it can be deduced by the fact that this 
> > parameters appears in the #defif condition which also must be fully 
> > valuable during preprocessing (just a bit more powerful
> > preprocessing) [...] 
[I wrote this first post encountering the message
 "Your message has not finished sending yet."(google)
 when trying to escape a buggy group post editing in iPad,
 buggy because the keyboard was totally covering the insert point...
 (I miss NNTP interfaced with gnus in emacs...)]
the binary search three example should have been consistent to the following:
#define f(#N,bt,a) \
 #defif(#N>0) \
  bt == NULL ? bt : (a == bt->val)           \
                  ? bt : (a < bt->val)       \
                       ? f(#N-1,bt->left,a)  \
                       : f(#N-1,bt->right,a) \
 #defelse \
  g(bt,a)
/* f macro definition ended here, below the example continue with the use */
struct {int val; binarytree *left,*right} binarytree;
binarytree* g(binarytree* bt, int a) {
return f(5,bt,a); /* recursive batch dept 5 is stored only here */
}

[Also, the character shown in inclusive replies with "?" was "..."
 but transformed by iPad in an unicode single character of three dots,
 now I replaced to the original three dots also inside my inclusion
 which obviously meant   unspecified traditional #define content]

> 
> It's an interesting idea. There are details that need to be 
> explored and understood first. Also I think it would be better 
> if expanded and generalized, perhaps along the lines of 'cond' 
> in lisp, or alternatively with ?# :# as preprocessing if/else. 
> Hmmm...

I'm favorable to any changes to the syntax I proposed,
including something a less powerful but simpler as
a number in the square brakes before the macro name
saying how many recursive expansion are permitted

#define f(bt,a) \
  bt == NULL ? bt : (a == bt->val)           \
                  ? bt : (a < bt->val)       \
                       ? [5]f(bt->left,a)  \
                       : [5]f(bt->right,a) \
 #defelse \
  g(bt,a)

You mentioned lisp, yes and why not lisp... I mean even lisp syntax!
limited to that (#define)context (which might exceptionally if you like,
save from the obligation of end lines with backslash when parenthesis
are not balanced at the end of #define line)
(cond CLAUSES...) (returning empty expansion where 
returns nil when all clausole are unsatisfied).
Anyway (cond) could be along the line of #defswitch ... #defcase
wich is to #defif / #defelseif / #defelse (or without the prefix def)

Interesting also your concise syntax ?# :# (or maybe you meant ... #? ... #: ...
as the dash come before in preprocessing recognition) as a form of ... ? ... : ...
but with dash used as preprocessing-only condition, with the same
functionality that I invoked with #defif / #defelse), it can be both
CPP forms, as the C has the dual.

As it was not introduced for so long to C/CPP, I welcome to open the discussion
and make a wise choice, which include cases of possible and opportune use studio.
Actually I have in mind recursion batch as a case where this is effectively
needed/beneficial, but the case of generic constant condition... I'm not too
sure is a generic benefit for maintenance and code understanding (furthermore
there is also already the possibility of #if before the #define for different
and constant #define),
maybe the  [number]macro  on invocation syntax within the #define macro
is sufficient as well as missing to permit something quite essential.
Let's think about cases of essential use

I'm also considering that there are a series of tools as Visual Studio, gdb
interpreation of macro expansion information saved in debug compiled file
format, which have some expectations on preprocessing, and the change
should be so welcome

[toc] | [prev] | [next] | [standalone]

#6428

Marco Munari <allerta.it@gmail.com> writes:

> On Monday, January 17, 2022 at 4:51:12 PM UTC+1, Tim Rentsch wrote:
>
>> Marco Munari <aller...@gmail.com> writes:
>>
>>> [conditional / recursive macro expansion]
>>
>> It's an interesting idea.  There are details that need to be
>> explored and understood first.  Also I think it would be better
>> if expanded and generalized, perhaps along the lines of 'cond'
>> in lisp, or alternatively with ?# :# as preprocessing if/else.
>> Hmmm...
>
> I'm favorable to any changes to the syntax I proposed,

I don't mean to suggest any specific changes, just throwing
out ideas.

> You mentioned lisp, yes and why not lisp... I mean even lisp
> syntax!  [...]

I think it would be hard to integrate lisp syntax into C's
lexical environment.  Technically it might be feasible, but
there are also human factors to consider, and those look
rather daunting.

> Interesting also your concise syntax ?# :# (or maybe you
> meant ... #? ... #: ...  [...]

It was just a casual suggestion.  Obviously there are lots
of details to consider before settling on specifics.

Good luck!

[toc] | [prev] | [standalone]

Back to top | Article view | comp.std.c

csiph-web