Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Bart's Language
Date: Fri, 21 Mar 2025 00:33:11 +0000
Organization: A noiseless patient Spider
Lines: 144
Message-ID: <vric47$c9ev$1@dont-email.me>
References: <vracit$178ka$1@dont-email.me> <vrbo88$1j3e0$1@paganini.bofh.team>
 <vrbtve$2irc9$1@dont-email.me> <vrc2d5$1jjrf$1@paganini.bofh.team>
 <vrcri2$3doia$1@dont-email.me> <vri5c8$26v8m$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 21 Mar 2025 01:33:12 +0100 (CET)
Injection-Info: dont-email.me; posting-host="01edc3bdc8bae69ef7cb5aa841da74a4";
	logging-data="402911"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Erih6M+FSzkmdLjd7XMkX"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:4ferk/1motAijqAn3EU7H9q0em4=
Content-Language: en-GB
In-Reply-To: <vri5c8$26v8m$1@paganini.bofh.team>
Bytes: 6130

On 20/03/2025 22:38, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>> On 18/03/2025 15:10, Waldek Hebisch wrote:
>>> bart <bc@freeuk.com> wrote:
>>>> On 18/03/2025 12:17, Waldek Hebisch wrote:
>>>>> bart <bc@freeuk.com> wrote:
>>>>>>
>>>>>> This is the document I produced:
>>>>>>
>>>>>> https://github.com/sal55/langs/blob/master/MFeatures.md
>>>>>>
>>>>>> A couple of more substantial demo programs are here:
>>>>>> https://github.com/sal55/langs/tree/master/MExamples
>>>>>>
>>>>>> (The bignum.m file was ported - by hand - to the bignum.c version that I
>>>>>> posted recently.)
>>>>>
>>>>> Looking at features, can you say if the program below works?
>>>>> And if it works, what is retrun value of foo?  "Equvalent" can
>>>>> be written in C, but in C you have to keep sane order.
>>>>
>>>>
>>>> There were some tweaks needed; it indicates some basic info missing from
>>>> my write-up! (For example, that the function call needs to be bar() not
>>>> bar; 'const' is only for compile-time expressions; and that C's 'const'
>>>> doesn't exist - it only briefly mentions an attempt at 'let'.)
>>>>
>>>> The revised code is shown below, with what I assumed were your
>>>> intentions.
>>>
>>> Well, my intentions beter correspond to the C version below:
>>>
>>> int foo() {
>>>       const int c = c1(10);
>>>       const int b = c + c2(2);
>>>       const int a = b+c3(c);
>>>       bar();
>>>       baz();
>>>       return c;
>>> }
>>
>>
>> In this case, just write it like that, and only adjust it for the
>> somewhat different syntax:
>>
>>    func foo:int =
>>        let int c := c1(10)
>>        let int b := c + c2(2)
>>        let int a := b+c3(c)
>>        bar()
>>        baz()
>>        return c
>>    end
> 
> In your description you wrote that declarations can be written
> "out of order" and compiler will rearrange them in correct
> order.

I made a decision to allow out-of-order definitions for all names, and I 
followed through with that. That is useful for:

* Function definitions
* Types and records (usually mutually referential ones)
* Named compile-time-constants
* Enumerations
* Macros
* FFI Import declarations
* Module-level variables

So, you just don't need to worry about it. Inside the top-level scope of 
a module for example, such a mix of definitions all exist 
simultaneously; there is no ordering.

All the above are defined using '=', which is a compile-time concept 
(variables either are not initialised so are all-zeros, or use '=' too 
at module scope).

However, you've picked on local variables inside a function, where 
assignments/initialisations are done with ':=', a runtime operation. 
Hence there is a ordering to those assignments, even if the variable 
/names/ that are defined exist function-wide and are unordered with 
respect to other names in the scope.


> That looked like great opportunity to write obfuscated
> code.

Sorry, it's not quite up to the standard of C, where:

* There are unlimited numbers of block scopes within each function

* So the same name A can be reused in each one, with a different type

* Scopes can start part-way through a block, so two different A's can
co-exist within the block

* There are parallel struct/enum tag and label namespaces, so that A can 
also be a struct A or enum A or A: in the same scope:

     int A; {++A; struct A {int A;} A; A: A=A; goto A;}

* If that is not quite enough, you can define parallel instances of A 
but in lower case 'a'.

I haven't even had to call upon macros for extra obfuscation!

> As you explained, it works differently, but I think
> already the fixed version of code I gave shows potential.
> And the following seem to satisfy your restriction that
> 'const' is compile time constant and what happens is
> puzzling to the reader (better than goto-s used to confuse
> control flow):
> 
> func foo:int =
>      const a = b + c
>      let int cc := c1(a)
>      const b = c + 2
>      let int bb := c2(b) + cc
>      const c = 10
>      bb + c
> end

Here's an actual use-case from an older C compiler project. It's some 
lines from a table of type-enums with parallel arrays:

     (tschar,        "schar",    8,  1,  tsint),
     (tsshort,       "short",    16, 1,  tsint),
     (tsint,         "int",      32, 1,  0,   ),
     (tsllong,       "llong",    64, 1,  0,   ),

The left column is enums used to denote C types inside the project.

The last column starting 'tsint' specifies what narrow types expand to 
in an expression.

Notice that 'tsint' is an enum name which is itself not specified until 
a couple of lines later. This is out-of-order definitions in action.

What obfuscations are needed in C to achieve the same? Maybe X-macros, 
or defining discrete arrays which need to be kept in sync. Maybe all 
sorts of other workarounds.