• conditional macro definition also for recursive conditionally limited expansion

    From Marco Munari@allerta.it@gmail.com to comp.std.c on Sun Jan 9 16:52:07 2022
    From Newsgroup: comp.std.c

    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
    --- Synchronet 3.19b-Linux NewsLink 1.113
  • From James Kuyper@jameskuyper@alumni.caltech.edu to comp.std.c on Mon Jan 10 00:48:52 2022
    From Newsgroup: comp.std.c

    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.
    --- Synchronet 3.19b-Linux NewsLink 1.113
  • From Tim Rentsch@tr.17687@z991.linuxsc.com to comp.std.c on Mon Jan 17 07:13:14 2022
    From Newsgroup: comp.std.c

    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.)
    --- Synchronet 3.19b-Linux NewsLink 1.113
  • From Tim Rentsch@tr.17687@z991.linuxsc.com to comp.std.c on Mon Jan 17 07:51:06 2022
    From Newsgroup: comp.std.c

    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...
    --- Synchronet 3.19b-Linux NewsLink 1.113
  • From Marco Munari@allerta.it@gmail.com to comp.std.c on Tue Jan 18 04:24:24 2022
    From Newsgroup: comp.std.c

    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
    --- Synchronet 3.19b-Linux NewsLink 1.113
  • From Tim Rentsch@tr.17687@z991.linuxsc.com to comp.std.c on Wed Jan 19 06:53:55 2022
    From Newsgroup: comp.std.c

    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!
    --- Synchronet 3.19b-Linux NewsLink 1.113