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


Groups > comp.lang.c > #391456

Re: Bart's Language

From bart <bc@freeuk.com>
Newsgroups comp.lang.c
Subject Re: Bart's Language
Date 2025-03-21 00:33 +0000
Organization A noiseless patient Spider
Message-ID <vric47$c9ev$1@dont-email.me> (permalink)
References (1 earlier) <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>

Show all headers | View raw


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.


Back to comp.lang.c | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Bart's Language bart <bc@freeuk.com> - 2025-03-17 23:51 +0000
  Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-18 12:17 +0000
    Re: Bart's Language bart <bc@freeuk.com> - 2025-03-18 13:54 +0000
      Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-18 15:10 +0000
        Re: Bart's Language bart <bc@freeuk.com> - 2025-03-18 15:45 +0000
          Re: Bart's Language David Brown <david.brown@hesbynett.no> - 2025-03-18 17:31 +0100
            int a = a (Was: Bart's Language) gazelle@shell.xmission.com (Kenny McCormack) - 2025-03-18 18:04 +0000
              Re: int a = a (Was: Bart's Language) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-18 19:36 +0100
                Re: int a = a (Was: Bart's Language) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-18 19:11 +0000
                Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-19 15:56 +0100
                Re: int a = a (Was: Bart's Language) scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 16:38 +0000
                Re: int a = a (Was: Bart's Language) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-19 14:29 -0700
                Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-20 09:39 +0100
                Re: int a = a (Was: Bart's Language) bart <bc@freeuk.com> - 2025-03-20 11:59 +0000
                Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-20 15:46 +0100
                Re: int a = a (Was: Bart's Language) wij <wyniijj5@gmail.com> - 2025-03-20 23:13 +0800
                Re: int a = a (Was: Bart's Language) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 02:02 -0700
                Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-20 15:57 +0100
                Re: int a = a (Was: Bart's Language) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-19 17:07 +0000
                Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-19 13:34 -0700
                Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 02:54 -0700
                Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 03:20 -0700
                Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-20 16:22 +0100
                Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 12:46 -0700
                Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-21 10:44 +0100
                Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-21 12:23 -0700
                Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-21 21:46 +0100
                Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-22 13:59 -0700
                Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-22 15:37 -0700
                Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-28 09:39 -0700
                Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-29 13:12 -0700
                Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-29 13:34 -0700
                Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-20 15:42 +0100
              Re: int a = a (Was: Bart's Language) scott@slp53.sl.home (Scott Lurndal) - 2025-03-18 19:37 +0000
              Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-18 20:51 +0100
                Re: int a = a (Was: Bart's Language) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-18 23:27 +0100
                Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-19 11:40 +0100
              Re: int a = a (Was: Bart's Language) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-18 23:52 -0700
                Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-19 01:55 -0700
                Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-27 13:41 -0700
                Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-19 11:43 +0100
                Re: int a = a (Was: Bart's Language) Rosario19 <Ros@invalid.invalid> - 2025-03-19 13:23 +0100
                Re: int a = a (Was: Bart's Language) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 01:32 -0700
          Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-20 22:55 +0000
            Re: Bart's Language Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 16:22 -0700
              Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-22 14:37 +0000
                Re: Bart's Language James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-22 11:41 -0400
                Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-22 16:52 +0000
                Re: Bart's Language James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-22 20:12 -0400
                By definition... (Was: Bart's Language) gazelle@shell.xmission.com (Kenny McCormack) - 2025-03-23 17:20 +0000
              Re: Bart's Language Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-27 11:53 -0700
                Re: Bart's Language Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-27 14:29 -0700
                Re: Bart's Language Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-06 14:04 -0800
                Re: Bart's Language Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-06 17:12 -0800
                Re: Bart's Language Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-06 09:04 -0800
        Re: Bart's Language bart <bc@freeuk.com> - 2025-03-18 22:19 +0000
          Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-20 22:38 +0000
            Re: Bart's Language Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-20 23:45 +0000
              Re: Bart's Language bart <bc@freeuk.com> - 2025-03-21 00:56 +0000
                Re: Bart's Language Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-21 17:47 +0000
                Re: Bart's Language Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-22 07:12 -0700
            Re: Bart's Language bart <bc@freeuk.com> - 2025-03-21 00:33 +0000

csiph-web