Help with Scoping: Definitions only in dedicated blocks and only befor

[Downsite]

Hi,

the default scoping seems to be tree-based (sibblings and anchestors).
Not having much experience with TScript, I struggle to adapt my own Scoping mechanism.

Before starting, I wanted to ask if there is already a reference for this, as it seems not so uncommon to want the following behavior:

Only check for past references.
In addition I want either
a) Scoping is identical to the default, but a given block defines global scope
or
b) Only references in a specific block can be referenced.

To illustrate, let me give a simplified example:

definitions:
Symbol a := 0.5;
Symbol b := 0.5;


evaluation:
a + b;
//c + b; //this should fail


definitions:
Symbol c := 0.5;

Simplified example for the targeted grammar:

grammar HelloWorld

entry Model:
    (Definition_Block | Eval_Block)*;

Definition_Block:
    'definitions' ":" (Definition)*;

Eval_Block:
    'evaluation' ":" (Evaluation)*;    

Definition infers SSymbol:
    'Symbol' name=ID ":=" FLOAT ";";

Evaluation:
    LHS=[SSymbol:ID] "+" RHS=[SSymbol:ID] ";";



FLOAT: {infer FLOAT} ("-")?DIGIT?"."DIGIT+;

hidden terminal WS: /\s+/;
terminal ID: /[_a-zA-Z][\w_]*/;
terminal DIGIT: ("0".."9");

hidden terminal ML_COMMENT: /\/\*[\s\S]*?\*\//;
hidden terminal SL_COMMENT: /\/\/[^\n\r]*/;
 

[cdietrich]

how are the definition and eval block related? in your grammar they are siblings. you also dont assign them to lists.

[Downsite]

As msujew has commented, I had many unassigned rules (I left that out for simplicily).
His suggested grammar would be more realistic.

They are siblings as they can not be nested. My current plan is to keep them as siblings as shown in the example grammar. I saw that I can "trick" the default scoping mechanism by not differentiating between them. Something similar to

entry Model:
    ((header=Header)? (lines+=(Definition|Evaluation))*);

but then I could have definitions also under "evaluation:".

[msujew]

FYI, there are a few issues with your grammar:

entry Model:
    blocks+=(Definition_Block | Eval_Block)*;

Definition_Block:
    'definitions' ":" (definition=Definition)*;

Eval_Block:
    'evaluation' ":" (eval=Evaluation)*;    

Definition infers SSymbol:
    'Symbol' name=ID ":=" value=FLOAT ";";

Evaluation:
    LHS=[SSymbol:ID] "+" RHS=[SSymbol:ID] ";";

fragment terminal DIGIT: ("0".."9");
terminal FLOAT: ("-")?DIGIT*"."DIGIT+;

having everything unassigned will lead to a lot of issues in general. Unassigned rule calls should only be used in special circumstances. Regarding your questions:

Only check for past references.

I wouldn't recommend adding that to the scoping mechanism. Instead, I would handle this similar to most other programming languages: Allow scoping to "future" elements, but add a validation that ensures that the user gets an error:

Scoping is identical to the default, but a given block defines global scope

Can you clarify? What do you mean by "a block defines global scope"?

[Downsite]

To be honest, the validation mechanism seems even more scary than the scoping mechanism for a novice. I was hoping that excluding "future" elements would be something I did not need to touch the AST for. The standard "Could not resolve reference" warning was good enough for my needs.

What do you mean by "a block defines global scope

With the example

definitions:
Symbol a := 0.5;
Symbol b := 0.5;


evaluation:
a + b;

with my (or your improved version of my) grammar, the definitions (in the definitions) block are hidden in other blocks and can not be used in cross-references from the "evaluation" block (or other "definitions" blocks).

I want the definitions in "definitons" blocks to be global in the sense that all "SSymbols" defined there can be used everywhere else.

In the evaluaiton blocks, the default scoping is fine.

[msujew]

The validation is actually way easier than the scoping mechanism, trust me on this. See here for a solution on this.

[Downsite]

Thank you for that snippet, together with the partial solution of the poster of that thread, I have a starting point.
I wonder if such a validator would be a good target to put as a (optional) default in the yeoman generator.

In regard to scoping, is there an obvious way to have everything at global scope? I think that would be sufficient for my needs.

Otherwise, I think I need either find the needed understanding of the used data structures and helper functions to add all names to all containers,
or maybe there is an easier way (since this language only considers single files), overriding getGlobalScope.
What do you think would be easier?

[msujew]

In regard to scoping, is there an obvious way to have everything at global scope? I think that would be sufficient for my needs.

You can create an override of the ScopeComputation service similar to here. But instead of building fully qualified names, you just expose all elements to the global scope with their given names.

[Downsite]

I got some good hints, thanks for your input.