Re: Bart's Language

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.