Variable definitions at the begining of functions always?


#1

I am not sure that this is a bug (if it is the workaround is trivial).

This doesn’t compile:

#!/stor/sandbox/little/L/bin/L

void main() {
   string foo = "foo";
   puts("foo is ${foo}");
   string bar = "bar";
   puts("bar is ${bar}");
}

I get:

[lyderic@nuc little]$ ./hello
./hello:6: L Error: syntax error, unexpected id, expecting (
   string bar
          ^

    while executing
"L --lineadj=-1
#!/stor/sandbox/little/L/bin/L

void main() {
   string foo = "foo";
   puts("foo is ${foo}");
   string bar = "bar";
   puts("bar is $..."
    (file "./hello" line 1)

To make it work, I have to put the variable definitions / assignments at the begining of the function like this:

#!/stor/sandbox/little/L/bin/L

void main() {
   string foo = "foo";
   string bar = "bar";
   puts("foo is ${foo}");
   puts("bar is ${bar}");
}

This is unexpected behaviour to me. Please note I am a C and Java programmer, and I am not used to Tcl nor perl.

Anyway keep up the excellent work! L is a excellent language. I love it :wink:


#2

Hi,

This “feature” is on purpose. It comes from code reviewing, when you are looking at a function it is usually easier to review it if all the variables are up top. I’ll admit it’s my preference and I could be talked into allowing variables are the beginning of a new curly brace scope.

Thanks for the kind words, glad you are enjoying it.

–lm


#3

Well as you say, it is a matter a personal preference.

That being said, as I understand that L is developed in the spirit of C compatibility (one of its biggest selling points IMHO), I would personally prefer to have the C-like behaviour of allowing variables to be initialised anywhere within a curly brace scope.

If not, I would suggest to make at least very clear in the documentation that variables have to be defined at the begining. I don’t think it is said in the documentation, but I have not had time to look very deep yet.

It took me some time to figure out this bug, until I realised it is actually a feature :wink:


#4

This feature is in keeping with ANSI C, which a lot of people still prefer for embedded work. I guess an argument could be made for keeping Little’s C-likeness consistent with C89/90 rather than C99/11.


#5

I didn’t know ANSI C had this limitation. Quoting from K&R (Second Edition, ANSI C): “In C, all variables must be declared before they are used, usually at the beginning of the function before any executable statements.” They don’t say it is mandatory, but usual. Moreover, compiling the following code with ‘gcc -Wall -ansi’ or even ‘gcc -Wall -std-c89’ doesn’t even raise a warning:

#include <stdio.h>

int main() {
   char *foo = "foo";
   printf("foo is %s\n", foo);
   char *bar = "bar";
   printf("bar is %s\n", bar);
   return(0);
}

Anyway, this is not a big issue, just a little (sane) habit for me to force myself into. So far, it looks I am the only one annoyed by this “feature”, am I?


#6

You forgot -pedantic (or perhaps -Wpedantic nowadays). Otherwise, despite the name, -c89 is C89 + a few compatible GNU extensions.


#7

Yes, you got it:

$ gcc -Wall -pedantic -ansi hello.c
hello.c: In function ‘main’:
hello.c:6:4: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
    char *bar = "bar";
    ^