Study of symbol lookups in namespaces and types

Forum for discussion about the documentation project.
Post Reply
SARG
Posts: 1756
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Study of symbol lookups in namespaces and types

Post by SARG »

fxm wrote:changelog.txt (today):
Where do you find it ? Not the master.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Study of symbol lookups in namespaces and types

Post by fxm »

SARG
Posts: 1756
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Study of symbol lookups in namespaces and types

Post by SARG »

fxm wrote:changelog.txt (today):
The update was not done today but 12 days ago. Misinterpreted....
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Study of symbol lookups in namespaces and types

Post by fxm »

Excuse me.
I confused with daily build.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Study of symbol lookups in namespaces and types

Post by fxm »

I found a compiler bug around name look-up (Aborting due to runtime error 12 ("segmentation violation" signal)) not due to the fbc 1.09 changes:

Code: Select all

Namespace M
    Sub ok() : Print "OK" : End Sub
End Namespace

Type UDT
    Declare Sub test()
    Dim As Integer __
End Type

Sub UDT.test()
    Using M
    This.ok()
End Sub
To also take into account.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: Study of symbol lookups in namespaces and types

Post by Munair »

You mean that it should throw a different error because of This?

If I understand the code correctly, This.ok tries to find the member ok in UDT. Without This. there's no error:

Code: Select all

Namespace M
    Sub ok() : Print "OK" : End Sub
End Namespace

Type UDT
    Declare Sub test()
    Dim As Integer __
End Type

Sub UDT.test()
    Using M
    ok()
End Sub

dim u as udt

u.test()
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Study of symbol lookups in namespaces and types

Post by coderJeff »

Munair wrote:I always use TYPES as a way of structuring module code. That's why I was wondering about the necessity of an additional namespace feature. Are there declarations that can be part of namespaces but not TYPES?
A TYPE can be declared inside a NAMESPACE, but you can't declare a TYPE inside a TYPE. (angros47 was requesting that feature so that fbc could interface with some g++ libraries.)
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Study of symbol lookups in namespaces and types

Post by coderJeff »

SARG wrote:This morning I got an error using 1.09. It took me a bit of time before understanding it.

By error there was a dot before a variable name : '.typ'.
No error with 1.08 and it's working fine but with 1.09 this error happens : undefined symbol.
I guess that changes made for namespaces/types cause this new behaviour.
Do you have an example?

I forgot to synchronize sourceforge.net. github and sourceforge both now have latest changes (pushed today).
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Study of symbol lookups in namespaces and types

Post by coderJeff »

fxm wrote:I found a compiler bug around name look-up (Aborting due to runtime error 12 ("segmentation violation" signal)) not due to the fbc 1.09
Drat.

I see what is happening, yes.
Munair wrote:If I understand the code correctly, This.ok tries to find the member ok in UDT.
Yes, and erroneously finds it, thinking it is an inherited member of 'UDT'. Because in the current context after 'using M', 'M.ok()' has been imported in to 'UDT', well in the current scope, anyway.

The segfault happens because fbc tries to construct a call to M.ok() with the instance pointer 'this', and since the compiler hasn't planned for that, it craps out. IN the debug version of fbc, it throws an error on a failed assert.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: Study of symbol lookups in namespaces and types

Post by Munair »

coderJeff wrote:
Munair wrote:I always use TYPES as a way of structuring module code. That's why I was wondering about the necessity of an additional namespace feature. Are there declarations that can be part of namespaces but not TYPES?
A TYPE can be declared inside a NAMESPACE, but you can't declare a TYPE inside a TYPE. (angros47 was requesting that feature so that fbc could interface with some g++ libraries.)
Seems like the same old difficulty between C and C++ libs, as demonstrated here.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Study of symbol lookups in namespaces and types

Post by coderJeff »

What I mean is that without NAMESPACE, every TYPE has to have a unique name in the entire source. That might be OK if you control all the source. If you don't control all the source, NAMESPACE may help.

Code: Select all

namespace library1
   type T '' some plain old struct
      __ as integer
   end type
end namespace
namespace library2
   type T extends object '' something fancy
end namespace

dim x as library1.T
dim y as library2.T
Can't do that with TYPES only in fbc currently (independently of any g++ desires).
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: Study of symbol lookups in namespaces and types

Post by Munair »

coderJeff wrote:
Munair wrote:If I understand the code correctly, This.ok tries to find the member ok in UDT.
Yes, and erroneously finds it, thinking it is an inherited member of 'UDT'. Because in the current context after 'using M', 'M.ok()' has been imported in to 'UDT', well in the current scope, anyway.

The segfault happens because fbc tries to construct a call to M.ok() with the instance pointer 'this', and since the compiler hasn't planned for that, it craps out. IN the debug version of fbc, it throws an error on a failed assert.
BTW, I tested it with FBC 1.08 and it gives the same error: "Aborting due to runtime error 12 ("segmentation violation" signal)" (copied from Geany). So it's not just 1.09.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Study of symbol lookups in namespaces and types

Post by coderJeff »

fxm wrote:To sum up, the unqualified name look-ups for future fbc 1.09 version should verify the priority hierarchy as follows:
- (1) current namespace/type
- (2) base types (by 'Extends'), ranked from closest to furthest in inheritance hierarchy
- (3) parent namespaces, ranked from closest to furthest in ancestry hierarchy (including global namespace: always furthest in hierarchy)
- (4) imported namespaces (by 'Using'), without hierarchy between them
I pushed changes to fbc/master that fix #948 Overriding class members doesn't work inside methods of further-extended subclasses

I added quite a few tests to the test suite. It was kind of tricky at first to test namespaces directly in the test-suite because the framework is based on ... namespaces. :)

A couple of examples that show changes from fbc-1.08 (simplified from test-suite entries)
1)

Code: Select all

dim shared A as integer = 2

type P extends object
	A as integer = 1
	declare sub proc()
end type

sub P.proc()
	? __FUNCTION__
	? A
end sub

type C extends P
	declare sub proc()
end type 

sub C.proc()
	? __FUNCTION__
	? A
end sub

type C2 extends C
	declare sub proc()
end type

sub C2.proc()
	? __FUNCTION__
	? A
end sub

dim z as C2
                      '' fbc-1.08  fbc-1.09
cast(P, c).proc()     ''    1        1
cast(C, c).proc()     ''    2        1
z.proc()              ''    2        1
2)

Code: Select all

type P extends object
	A as integer = 1
	declare sub proc()
end type

sub P.proc()
	? __FUNCTION__
	? A
end sub

type C extends P
	A as integer = 2
	declare sub proc()
end type 

sub C.proc()
	? __FUNCTION__
	? A
end sub

type C2 extends C
	declare sub proc()
end type

sub C2.proc()
	? __FUNCTION__
	? A
end sub

dim z as C2
                      '' fbc-1.08  fbc-1.09
cast(P, c).proc()     ''   n/a       1
cast(C, c).proc()     ''   n/a       2
z.proc()              ''   n/a       2
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: Study of symbol lookups in namespaces and types

Post by Munair »

coderJeff wrote:What I mean is that without NAMESPACE, every TYPE has to have a unique name in the entire source. That might be OK if you control all the source. If you don't control all the source, NAMESPACE may help.

Code: Select all

namespace library1
   type T '' some plain old struct
      __ as integer
   end type
end namespace
namespace library2
   type T extends object '' something fancy
end namespace

dim x as library1.T
dim y as library2.T
Can't do that with TYPES only in fbc currently (independently of any g++ desires).
Yes, I understand.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Study of symbol lookups in namespaces and types

Post by fxm »

coderJeff wrote:
SARG wrote:This morning I got an error using 1.09. It took me a bit of time before understanding it.

By error there was a dot before a variable name : '.typ'.
No error with 1.08 and it's working fine but with 1.09 this error happens : undefined symbol.
I guess that changes made for namespaces/types cause this new behaviour.
Do you have an example?

Code: Select all

Dim Shared As Integer I
Print .I          '' OK

Dim As Integer J
Print .J          '' error 8: Undefined symbol, J in 'Print .J' with fbc 1.09
                  '' OK with fbc 1.08
Post Reply