'#pragma reserve' statement to reserve backend keywords

Forum for discussion about the documentation project.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: '#pragma reserve' statement to reserve backend keywords

Post by coderJeff »

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.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: '#pragma reserve' statement to reserve backend keywords

Post by fxm »

coderJeff wrote:The individual links on pages will need to be updated.
I'm taking care of it.


[edit]
Done.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: '#pragma reserve' statement to reserve backend keywords

Post by fxm »

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']
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: '#pragma reserve' statement to reserve backend keywords

Post by fxm »

@Jeff,

Can you show with a simple example the difference in behavior between:
#pragma reserve symbol
and
#pragma reserve (shared) symbol
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: '#pragma reserve' statement to reserve backend keywords

Post by coderJeff »

fxm wrote:Can you show with a simple example the difference in behavior between:
#pragma reserve symbol
and
#pragma reserve (shared) symbol
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.
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
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: '#pragma reserve' statement to reserve backend keywords

Post by fxm »

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
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
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: '#pragma reserve' statement to reserve backend keywords

Post by coderJeff »

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.
I am making progress on fixing the bugs. Found some syntax that is not well defined.

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.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: '#pragma reserve' statement to reserve backend keywords

Post by fxm »

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).
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: '#pragma reserve' statement to reserve backend keywords

Post by fxm »

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
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: '#pragma reserve' statement to reserve backend keywords

Post by coderJeff »

fxm wrote:Should this also work ?
Yes, I have '..' working in scopes now too. '..' prefix always selects the global namespace.

'..' 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
I have only been testing variable types. Might be some differences if start testing with CONST, TYPE, ENUM, etc. But, I'll focus on variables for now.

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.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: '#pragma reserve' statement to reserve backend keywords

Post by fxm »

coderJeff wrote:I will leave the single '.' prefix alone for now. But the double '..' prefix should be preferred.
Therefore, both syntaxes ('.symbol' and '..symbol') must be described in the documentation (except inside a With block).
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
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: '#pragma reserve' statement to reserve backend keywords

Post by fxm »

@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.
Last edited by fxm on Sep 27, 2021 11:49, edited 1 time in total.
Reason: update
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: '#pragma reserve' statement to reserve backend keywords

Post by coderJeff »

fxm wrote:Can you show with a simple example the difference in behavior between:
#pragma reserve symbol
and
#pragma reserve (shared) symbol
Spent a good chunk of the day trying to figure out why I couldn't show the difference.

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()
Using defined(symbol) is a poor test. Besides, in most scopes symbols should be allowed to shadow other symbols provided that both still have a means to be accessed.

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.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: '#pragma reserve' statement to reserve backend keywords

Post by fxm »

Regarding the latest changes:
- 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
I'm waiting for a new build from St_W to play with it, and also before updating the documentation.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: '#pragma reserve' statement to reserve backend keywords

Post by fxm »

coderJeff wrote:
fxm wrote:Can you show with a simple example the difference in behavior between:
#pragma reserve symbol
and
#pragma reserve (shared) symbol
Spent a good chunk of the day trying to figure out why I couldn't show the difference.
Maybe with this:

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
Or with this:

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
Or are they both still bugs ?
Post Reply