Re: Bart's Language

On 18/03/2025 16:45, bart wrote:

On 18/03/2025 15:10, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

On 18/03/2025 12:17, Waldek Hebisch wrote:

 

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;
}
>
Part of the question was if "execution" of declarations is
interleaved with execution of code or if declarations go
before the code.

 A declaration like:
     int a := x
 can be considered to be:
     int a; a := x
 where the declaration can go anywhere in the scope=, but the assignment must be done here. There are languages where you have:
      print x
     where x is ...
 But the typical usage pattern in my own programs is that local variable are declared before first use.
 (Maybe a compiler option can enforce that, but I don't see it as critical.)
 

      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".

 That doesn't happen here:
    int a = a;
 gcc (with no extra options) tcc and bcc both put some undefined value in a.

It would be a little more accurate (in C terminology) to call it an "unspecified value" rather than an "undefined value" - gcc, and many other compilers, treat that as meaning "a" gets a valid int value, but you don't care which value it is.  Using the value in "a" is allowed - i.e., it is not considered as undefined behaviour by the compiler.  (I am not sure if the C standards require "int a = a;" to be treated like that - I suspect that it is undefined behaviour from the standards viewpoint, but defined by the implementation.)

 gcc won't warn until you say '-Wextra', and then only for:

 >
 >    int a = a + 1;
People would not normally write "int a = a;".  It is used as a common idiom meaning "I know it is not clear to the compiler that the variable is always initialised before use, but /I/ know it is - so disable the use-without-initialisation warnings for this variable".  So it makes perfect sense for the compiler not to warn about it!
gcc does have a "-Winit-self" warning (not part of -Wall or -Wextra) that will warn on "int a = a;".  (It is enabled by -Wall in C++, however, since in C++ such code can have very different semantics for more advanced types.)
"int a = a + 1;", on the other hand, clearly attempts to read the value of "a" before it is initialised, and a warning is issued if "-Wuninitialized" is enabled.  This warning is part of "-Wall".