Grammar Unique to LSL

[Love Zhaoying]

Can you help see if I am missing some "grammar" features unique to LSL?

1. '<' and '>' delimiters for Vector and Rotation types

2. "." (period) used as "Structure/Member Access" but ONLY for Vector and Rotation members X, Y, Z, and R.

3. "State" keyword / Scope where each "State" can contain Events duplicated in another State.  (This really makes it more like a "Class" Scope.)

4. Specific intrinsic / atomic types: list, vector, rotation.  ("Key" is really more like a String). List syntax is really like "array" syntax, grammar-wise..

 

Edited April 19, 2023 by Love Zhaoying

[Wulfie Reanimator]

Do you want like a complete list of all keywords and operators, or some more specific subset?

Edited April 19, 2023 by Wulfie Reanimator

[Love Zhaoying]

Just now, Wulfie Reanimator said:

Do you want like a complete list of all keywords and operators, or are you interested in something specific?

From a parsing perspective.

Specific grammar / parsing differences. A good example is, Operators not really used the same as in other languages.

I basically listed the features that I am focused on now, which don't match "normal" parsing grammar (or aren't really flexible, for the example you can only have .X, .Y, .Z, and .R.)

"Keywords", not so much.  I THINK that have that handled. A quick review of the page confirms that for me.  https://wiki.secondlife.com/wiki/Category:LSL_Keywords/All  I don't count "function names" and "event names" as "keywords" in the context of my question.

 

[Quistess Alpha]

except for possible weird edge cases, like '/*' being allowed without a corresponding '*/' after the "end" of a script, I think you've thought of most of them. do+while and else+if are interesting parsing wise, but similar to many other languages.

Edited April 19, 2023 by Quistess Alpha

[Love Zhaoying]

1 minute ago, Quistess Alpha said:

except for possible weird edge cases, like '/*' being allowed without a corresponding '*/' after the "end" of a script, I think you've thought of most of them. do+while and else+if are interesting parsing wise, but similar to many other languages.

I think standard Microsoft VB / VBA has both the "do{block}while()" (as "repeat..until") and "while(){block}" constructs, so while they may not both be in standard C++ they were pretty "normal" to me.

If I understand corectly, the end of the script / "EOF" is before the closing "*/"?   I did not create a Schema for the "/*..*/" edge case yet, but basically was going to approach it like "{..}" or "BEGIN/END" blocks.  For my proposed Schema, if I find "/*" but no matching "*/" before EOF, I would have either an Error or Warning "*/ expected".  Same as BEGIN missing END, "{" missing "}",  "(" missing ")", etc.  For this specific edge case, it could be a "warning" - unless the comment block was in the middle of a function, etc. of course!  So, it would only be valid if the comment block started after the end of the final "state" in the script (or source language, in my case).

[Fenix Eldritch]

1 hour ago, Love Zhaoying said:

.R

Accessing the 4th element of a rotation/quaternion uses the .s accessor. Trying it with .r will not compile.

[Love Zhaoying]

1 minute ago, Fenix Eldritch said:

2 hours ago, Love Zhaoying said:

.R

Accessing the 4th element of a rotation/quaternion uses the .s accessor. Trying it with .r will not compile.

LOL! Thanks!!! 

It's been that long since i needed to touch the 4th dimension. Rotations, sucketh verily.

Since my initial POC testing is going from "BASIC" syntax into LSL => compiled, then I would find out pretty quick and just change the Schema from "r" to "s"!

[Quistess Alpha]

3 hours ago, Love Zhaoying said:

If I understand corectly, the end of the script / "EOF" is before the closing "*/"? 

Yes, and I might also mention LSL supports scope-based variable overloading, As an example of both:

default
{   state_entry()
    {   integer x;
        {  string x = (string)x; // x is type integer to the right of '='
           string y = x+ "s"; // x is of type string at this point
        }
        ++x; // x is an integer, the string overload went out of scope.
        {  string x = "x"; // variable name overload need not use the previous value before it is masked.
        }
    }  
}
/* there is no closing comment indicator

should compile.

[Love Zhaoying]

6 minutes ago, Quistess Alpha said:

Yes, and I might also mention LSL supports scope-based variable overloading, As an example of both:

default
{   state_entry()
    {   integer x;
        {  string x = (string)x; // x is type integer to the right of '='
           string y = x+ "s"; // x is of type string at this point
        }
        ++x; // x is an integer, the string overload went out of scope.
        {  string x = "x"; // variable name overload need not use the previous value before it is masked.
        }
    }  
}
/* there is no closing comment indicator

should compile.

Sounds like a buggy implementation side-effect! The example with "string x = (string)x;", is particularly bothersome. In any case, implied scope with same-name variables is scary! I much prefer explicit scope (named scope, or referencing a specific pointer, class, Parent, instance, etc.).

So anyway, I will try to keep this nightmarish example in mind. Thank you!

 

[Love Zhaoying]

@Quistess Alpha, ironically - the example you gave is a natural fit for targeting my interpreted system (not LSL)! (Due to order of interpretation, scoping, etc.) And probably not a big deal for the way my Schemas work for LSL.

But, if I want this "first cut" of Schemas to parse from an "intermediate" level BASIC to LSL, probably I'll be smart to only allow global scope and "function-level" scope. At "primitive" level BASIC, I'd only have global scope! ..even if targeting LSL!

Technically, I can obviously design a set of Schemas for each implementation. Right now, I'm trying to pick one and stick with it. "Primitive" BASIC would be smartest to start, we'll see. (Just a main(), no functions or subroutines, but GOSUB/RETURN internal to the one nain(). This can still target LSL and result in separate LSL functions.)

 

[Anna Salyx]

On 4/19/2023 at 1:40 PM, Love Zhaoying said:

3. "State" keyword / Scope where each "State" can contain Events duplicated in another State.  (This really makes it more like a "Class" Scope.)

I suppose you can draw a parallel of 'state' to a 'class', but if you want to be more accurate, LSL more more of a Finite State Machine (FSM) structure/model. Each STATE shares a specific set of potential input conditions (events) that it can respond to, and the implementation of the events and, corresponding outputs, is directly dependent on the state in question. They may share a common pool of constants and variables and pass date between states that way as output and input events, but each state functions more as as a discreet Virtual Machine than a class, since you have to fully exit one state, shutting it down, before entering another and no two shall never directly interact.

[Love Zhaoying]

36 minutes ago, Anna Salyx said:

I suppose you can draw a parallel of 'state' to a 'class', but if you want to be more accurate, LSL more more of a Finite State Machine (FSM) structure/model. Each STATE shares a specific set of potential input conditions (events) that it can respond to, and the implementation of the events and, corresponding outputs, is directly dependent on the state in question. They may share a common pool of constants and variables and pass date between states that way as output and input events, but each state functions more as as a discreet Virtual Machine than a class, since you have to fully exit one state, shutting it down, before entering another and no two shall never directly interact.

That all sounds reasonable, keeping in mind that I'm mostly trying to relate the LSL language structure to other languages.

On the other hand..the way I've dealt with the FSM aspect in my Parser-> interpreter model is to ignore it completely for the main interpreter script, which only uses a single state, with just state_entry() and link_message()! (Other "helper" scripts implement other events as needed.)

I haven't thought about the events much for the Parser->LSL model. Guess I'll have to eventually..! 

Thanks so much for your feedback!

Edited April 24, 2023 by Love Zhaoying
Fun fact: "FSM" is also the standard abbreviation for Flying Spaghetti Monster!

[Anna Salyx]

1 hour ago, Love Zhaoying said:

That all sounds reasonable, keeping in mind that I'm mostly trying to relate the LSL language structure to other languages.

On the other hand..the way I've dealt with the FSM aspect in my Parser-> interpreter model is to ignore it completely for the main interpreter script, which only uses a single state, with just state_entry() and link_message()! (Other "helper" scripts implement other events as needed.)

I haven't thought about the events much for the Parser->LSL model. Guess I'll have to eventually..! 

Thanks so much for your feedback!

I get that and I think the main issue is that while most everything else can be related in some way to other languages, even events, the state itself really can't.  At least I'm not sure there really is an elegant way to do that.  Each state is like it's own self contained mini machine residing with other mini machines in the same container sharing resources but only one can get power at any given time. I'll def be interested in seeing what you do come up with though; I'm happy to have my horizons be broadened

Oh, and re: your edit message - All hail His noodly appendages.