'#pragma reserve' statement to reserve backend keywords
Re: '#pragma reserve' statement to reserve backend keywords
That's probably just how it was named when it was created.
I've renamed KeyPgPragma => KeyPgPpPragma in the database to follow the page naming pattern.
The individual links on pages will need to be updated.
I've renamed KeyPgPragma => KeyPgPpPragma in the database to follow the page naming pattern.
The individual links on pages will need to be updated.
Re: '#pragma reserve' statement to reserve backend keywords
I'm taking care of it.coderJeff wrote:The individual links on pages will need to be updated.
[edit]
Done.
Re: '#pragma reserve' statement to reserve backend keywords
Documentation updated (in accordance with previous posts):
- KeyPgPpPragmaReserve → fxm [new page '#PRAGMA RESERVE']
- KeyPgPpPragma → fxm [added link to new page '#pragma reserve']
- ProPgPreprocessor → fxm [added link to new page '#pragma reserve']
- CatPgPreProcess → fxm [added link to new page '#pragma reserve']
- PrintToc → fxm [added link to new page '#pragma reserve']
- CatPgFunctIndex → fxm [added link to new page '#pragma reserve']
- CatPgFullIndex → fxm [added link to new page '#pragma reserve']
- KeyPgPpPragmaReserve → fxm [new page '#PRAGMA RESERVE']
- KeyPgPpPragma → fxm [added link to new page '#pragma reserve']
- ProPgPreprocessor → fxm [added link to new page '#pragma reserve']
- CatPgPreProcess → fxm [added link to new page '#pragma reserve']
- PrintToc → fxm [added link to new page '#pragma reserve']
- CatPgFunctIndex → fxm [added link to new page '#pragma reserve']
- CatPgFullIndex → fxm [added link to new page '#pragma reserve']
Re: '#pragma reserve' statement to reserve backend keywords
@Jeff,
Can you show with a simple example the difference in behavior between:
#pragma reserve symbol
and
#pragma reserve (shared) symbol
Can you show with a simple example the difference in behavior between:
#pragma reserve symbol
and
#pragma reserve (shared) symbol
Re: '#pragma reserve' statement to reserve backend keywords
It's not well tested. It only seems to work in a nested scope. In current version it's not working correctly for the implicit main scope module level.fxm wrote:Can you show with a simple example the difference in behavior between:
#pragma reserve symbol
and
#pragma reserve (shared) symbol
After I started testing '#pragma reserve' with namepaces I have become distracted by #645 Access to global duplicated symbol is captured by local symbol
Code: Select all
'' scoped to module
#pragma reserve (shared) shared_scope
'' should be scoped to implicit main only
#pragma reserve main_scope
sub proc()
scope
'' scoped to local scope only (or sub, do, select, etc)
#pragma reserve nested_scope
end scope
#assert( defined(shared_scope) )
#assert( not defined(nested_scope) )
'' failed assert - is a current bug with '#pragma reserve symbol'
#assert( not defined(main_scope) )
end sub
Re: '#pragma reserve' statement to reserve backend keywords
Indeed, it would perhaps be interesting to treat these 2 problems ('#pragma reserve [ (shared) ] symbol' and 'bug(s) #645/#581/#871') at the same time because they can be linked.coderJeff wrote:It only seems to work in a nested scope. In current version it's not working correctly for the implicit main scope module level.
After I started testing '#pragma reserve' with namepaces I have become distracted by #645 Access to global duplicated symbol is captured by local symbol
Re: '#pragma reserve' statement to reserve backend keywords
I am making progress on fixing the bugs. Found some syntax that is not well defined.fxm wrote:Indeed, it would perhaps be interesting to treat these 2 problems ('#pragma reserve [ (shared) ] symbol' and 'bug(s) #645/#581/#871') at the same time because they can be linked.
What should purpose of '.symbol' be?
'..symbol' -> always global namespace
'.symbol' -> well defined for use inside 'WITH'
'symbol' -> lookup based on enclosing scope / namespace
'ns.symbol' -> explicit namespace lookup
'.symbol' seems unclear the purpose when used outside of a WITH statement.
Re: '#pragma reserve' statement to reserve backend keywords
Indeed, the simplest and clearest would be that:
- '.symbol' can only be used inside a With block to access a member of the instance specified in the With declaration,
- '..symbol' is exclusively reserved for accessing a duplicate symbol defined in the global scope, and that it is the only possible syntax (no more '.symbol' possible for that).
- '.symbol' can only be used inside a With block to access a member of the instance specified in the With declaration,
- '..symbol' is exclusively reserved for accessing a duplicate symbol defined in the global scope, and that it is the only possible syntax (no more '.symbol' possible for that).
Re: '#pragma reserve' statement to reserve backend keywords
Should this also work ?
Code: Select all
Dim shared As Integer x = 1
' '..symbol' access also true inside any compound block statement
Scope
Dim As Integer x = 2
Print x '' 2
Print ..x '' 1 => NOK
Print
End Scope
' '..symbol' access also true inside any procedure body
Sub s()
Dim As Integer x = 3
Print x '' 3
Print ..x '' 1 => NOK
Print
End Sub
s()
Sleep
Re: '#pragma reserve' statement to reserve backend keywords
Yes, I have '..' working in scopes now too. '..' prefix always selects the global namespace.fxm wrote:Should this also work ?
'..' prefix is starting to give more consistent results. For readability, can do:
Code: Select all
#define global .
dim shared x as integer
print global.x
Under the hood:
- from long ago the '.' prefix alone would select the global namespace.
- But that would be ambiguous inside a WITH block.
- So '..' prefix is allowed inside or outside a WITH block to select the global namespace.
I will leave the single '.' prefix alone for now. But the double '..' prefix should be preferred. Maybe a single '.' prefix can select the enclosing namespace if one exists -- in some future feature change.
Re: '#pragma reserve' statement to reserve backend keywords
Therefore, both syntaxes ('.symbol' and '..symbol') must be described in the documentation (except inside a With block).coderJeff wrote:I will leave the single '.' prefix alone for now. But the double '..' prefix should be preferred.
I will do this at the same time as when I will update the documentation on accessing duplicate symbols defined as global outside of any compound block (not only a namespace) and any procedure body (not just a member procedure body).
[edit]
Done.
Last edited by fxm on Sep 27, 2021 9:47, edited 1 time in total.
Reason: update
Reason: update
Re: '#pragma reserve' statement to reserve backend keywords
@Jeff,
After having solved and closed #645 Access to global duplicated symbol is captured by local symbol, it would be necessary to change the status of #581 Locals break/override THIS access to inherited members to "open" (classified a priori as "duplicate"), because the problem is not solved for this one.
[edit]
Done, thank you.
After having solved and closed #645 Access to global duplicated symbol is captured by local symbol, it would be necessary to change the status of #581 Locals break/override THIS access to inherited members to "open" (classified a priori as "duplicate"), because the problem is not solved for this one.
[edit]
Done, thank you.
Last edited by fxm on Sep 27, 2021 11:49, edited 1 time in total.
Reason: update
Reason: update
Re: '#pragma reserve' statement to reserve backend keywords
Spent a good chunk of the day trying to figure out why I couldn't show the difference.fxm wrote:Can you show with a simple example the difference in behavior between:
#pragma reserve symbol
and
#pragma reserve (shared) symbol
Then finally found this weird behaviour. Try this in any version of fbc:
Code: Select all
dim x as integer
sub proc
#if defined( x )
print "REALLY?"
#endif
'' error: variable not declared
print x
end sub
proc()
There are some subtle differences between shared and non-shared module level symbols and what symbols are allowed to be shadowed. Depends on if a namespace used and the symbol type, like const. paul doe called this debugging by coincidence.
Re: '#pragma reserve' statement to reserve backend keywords
Regarding the latest changes:
I'm waiting for a new build from St_W to play with it, and also before updating the documentation.- fbc: '#pragma reserve symbol' statement will reserve a symbol name in the current scope / namespace and generate an error if the symbol is used in an expression
- fbc: '#pragma reserve', asm and shared are mutually exclusive and throw an error if used in any scope block or procedure
Re: '#pragma reserve' statement to reserve backend keywords
Maybe with this:coderJeff wrote:Spent a good chunk of the day trying to figure out why I couldn't show the difference.fxm wrote:Can you show with a simple example the difference in behavior between:
#pragma reserve symbol
and
#pragma reserve (shared) symbol
Code: Select all
Namespace N
#pragma reserve myName1
#pragma reserve (shared) myName1 '' OK
End Namespace
#pragma reserve myName2
#pragma reserve (shared) myName2 '' error: Duplicated definition
Code: Select all
Namespace N1
#pragma reserve myName1
Dim As Integer myName1 '' OK
End Namespace
Dim As Integer myName1 '' error: Duplicated definition
Namespace N2
#pragma reserve (shared) myName2
Dim As Integer myName2 '' error: Duplicated definition
End Namespace
Dim As Integer myName2 '' OK