Re: transpiling to low level C

On 2024-12-22, bart <bc@freeuk.com> wrote:

On 22/12/2024 21:45, Kaz Kylheku wrote:

On 2024-12-21, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 21.12.2024 02:28, Tim Rentsch wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>

On 16.12.2024 00:53, BGB wrote:
>

[...]
>
Pretty much all higher level control flow can be expressed via goto.

>
A 'goto' may be used but it isn't strictly *necessary*. What *is*
necessary, though, that is an 'if' (some conditional branch), and
either 'goto' or recursive functions.

>
Conditional branches, including 'if', '?:', etc., are not strictly
necessary either.

>
No? - Can you give an example of your statement?

 
In a functional langauge, we can make a decision by, for instance,
putting two lambdas into an array A, and then calling A[0] or A[1],
where the index 0 or 1 is comes from some Boolean result.
 
The only reason we have a control construct like if(A, X, Y) where X
is only evaluated if A is true, otherwise Y, is that X and Y
have side effects.
 
If X and Y don't have side effects, then if(A, X, Y) can be an ordinary
function whose arguments are strictly evaluated.
 
Moreover, if we give the functional language lazy evaluation semantics,
then anyway we get the behavior that Y is not evaluated if A is true,
and that lazy evaluation model can be used as the basis for sneaking
effects into the functional language and conctrolling them.
 
Anyway, Turing calculation by primitive recursion does not require
conditional branching. Just perhaps an if function which returns
either its second or third argument based on the truth value of
its first argument.
 
For instance, in certain C preprocessor tricks, conditional expansion
is achieved by such macros.
 
When we run the following through the GNU C preprocessor (e.g. by pasting
into gcc -E -x c -p -):
 
   #define TRUE_SELECT_TRUE(X) X
   #define TRUE_SELECT_FALSE(X)
 
   #define FALSE_SELECT_TRUE(X)
   #define FALSE_SELECT_FALSE(X) X
 
   #define SELECT_TRUE(X) X
   #define SELECT_FALSE(X)
 
   #define PASTE(X, Y) X ## Y
 
   #define IF(A, B, C) PASTE(TRUE_SELECT_, A)(B) PASTE(FALSE_SELECT_, A)(C)
 
   #define FOO TRUE
   #define BAR FALSE
 
   IF(FOO, foo is true, foo is false)
   IF(BAR, bar is true, bar is false)
 
We get these tokens:
 
   foo is true
    bar is false

>
>
So, how long did it take to debug? (I've no idea how it works. If I

I typed it out right in the middle of my article and piped it out to
gcc, iterating a few times. I made a few silly mistakes in IF, mostly
due to referencing the wrong A, B, C.

Also, the SELECT_TRUE and SELECT_FALSE macros are dead code; not used.

change all TRUE/FALSE to BART/LISA respectively, it still gives the same
output. I'm not sure how germane such an example is.)

If you rename consistently, it will work. But it's not hygienic in that
since the solution relies on calculated identifiers, you have to change
TRUE_SELECT_TRUE to TRUE_SELECT_BART.

How it works is very simmple in that PASTE(TRUE_SELECT_, A) calculates
TRUE_SELECT_TRUE or TRUE_SELECT_FALSE depending on whether A contains
TRUE or FALSE. Then the argument list (B) is combined with this
calculated name, resulting in a macro call to TRUE_SELECT_TRUE(B) or
TRUE_SELECT_FALSE(B) with the value of B as an argument.
If the former is used, then it expands to B; if the latter, then to
nothing.

One of the two PASTE calls in the expansion of IF() produces tokens, and
the other nothing. The two results are catenated together into one token
sequence, so we get the result of whichever one is nonempty.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca