Re: Bart's Language

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
'let' seems to still work, and will do the job of C's const in simple cases like this.
Versions in both languages now report Lines 5 3 1 2 4.
The 'let' here is enforced more strongly that C's 'const', in that it /has/ to be initialised. C needs the right compiler and the right options
to complain about it.

 Part of the question was if "execution" of declarations is
interleaved with execution of code or if declarations go
before the code.
 I am not saying that you should implement this, rejecting the
code as insane would be fine for me.
 

And below that is that code ported to C. Both versions
produce this output:
>
  Line 1
  Line 2
  Line 3
  Line 4
  Line 5
  10
  Line 1
  Line 2
  Line 3
  Line 4
  Line 5
  10
>
Note that both 'b' and 'c' in foo() are used uninitialised. I couldn't
apply 'const' to those, as the const declaration would be separate from
the assignment, and the later assignment is then not possible.
>
(To answer your presumably implied point, in:
>
      print a
      int a:=100
>
the assignment is done at that place in the code (after print), but the
scope of 'a' is function-wide. My compiler doesn't detect accesses to
unitialised variables, but I could add a debug option to clear
stack-frame variables on function entry.)

 I see.  So your feature conflicts with C feature "variable which is
initialized at declaration time is always used initialized".