Constants and modules

[Erich]

Hi,

I have a question about enumerations and modules. I have an enumeration for all ascii characters in a module, like this (abbreviated):

Code: Select all

Enumeration ascii 0
    #NUL
    #SOH
    #STX
    #ETX
    #EOT
    #ENQ
    #ACK
    #BEL
    #BS
    #HT
    #LF
    #VT
    #FF
    #CR
; and so forth
 EndEnumeration
EndDeclareModule
Module ASCII
EndModule

I then include the module by XIncludeFile "ascii.pb", but without UseModule, and use the entries as in:

Code: Select all

 Procedure.b IsSingleCharToken(c.i)
    Select c
      Case #LF,
           ASCII::#LPAREN, 
           ASCII::#RPAREN,
           ASCII::#COLON,
           ASCII::#COMMA,
           ASCII::#PERIOD,
           ASCII::#LBRACKET,
           ASCII::#RBRACKET,
           ASCII::#LBRACE,
           ASCII::#RBRACE
        ProcedureReturn #True
      Default
        ProcedureReturn #False
    EndSelect
  EndProcedure

The problem is if I use ASCII::#LF from my module instead of the built-in constant #LF, I get an error "Constant not found #LF".

That's no problem in this example, but seems pretty bad in general. When I write a module, shouldn't I be able to be sure that no name clashes can occur because of things defined outside of the module as long as the module is not used?

Is that a bug?

[ts-soft]

All predefined API-Constants and #PB_ Constants must be available in Module for programming anything

[idle]

All predefined API-Constants and #PB_ Constants must be available in Module for programming anything

Yes but that shouldn't preclude namespace resolution working
the declared enumerations should be prefixed with the module name by the compiler so there isn't any conflict, #NUL <> #ModuleName_NUL
In the scope of a module the compiler should resolve all symbols by the module name first. ModuleNAME_X then fall back
to the global namespace to find X if ModuleName_X wasn't found.

[Erich]

Okay, so this is a bug or misfeature. The error message is also misleading - at least it should say something like "Attempt to redefine constant that is already defined globally" or something like that and give an error when the module is compiled. But I still don't understand why there couldn't be two constants #LF and ASCII::#LF as long as I don't import the names by UseModule ascii and only use prefixed names.

Like I said, it's not a big deal but I agree with idle that this should be fixed in future versions of PB, before this weirdness gets accepted as the "way it always worked".

[Little John]

Like I said, it's not a big deal but I agree with idle that this should be fixed in future versions of PB, before this weirdness gets accepted as the "way it always worked".

I agree.
Maybe you can write a bug report (should include some short executable code) in the regarding forum section for the OS where you encountered the issue?

[mhs]

But I still don't understand why there couldn't be two constants #LF and ASCII::#LF as long as I don't import the names by UseModule ascii and only use prefixed names.

Because inside the module the constant names are used without the ASCII:: and so there is a name conflict with the PB constant inside the module, if you use #LF.

[Little John]

Because inside the module the constant names are used without the ASCII:: and so there is a name conflict with the PB constant inside the module, if you use #LF.

Normally, assigning the same value to an existing constant does not cause an error in PB.
Only assigning a different value causes a problem:

Code: Select all

Debug #LF   ; displays 10

#LF = 10    ; no error

#LF = 11    ; error

[mhs]

Normally, assigning the same value to an existing constant does not cause an error in PB.
Only assigning a different value causes a problem:

Oh yes, you're right.

[PMV]

This topic was discussed heavy when modules are introduced.
PB commands and constants are not in its own namespace. Every
modul that has constants and/ or commands named like existing
PB commands and/ or constants will conflict!

This desicion is done by pb team, no bug, and i don't think this will change soon.
Feel free to search for that thread.

MFG PMV

[Little John]

This topic was discussed heavy when modules are introduced.
PB commands and constants are not in its own namespace. Every
modul that has constants and/ or commands named like existing
PB commands and/ or constants will conflict!

I vaguely recall it now.

However, IMHO the error message is misleading.
Here is a short executable code that demonstrates the issue:

Code: Select all

; PB 5.31 (x64) on Windows

DeclareModule Ascii
   Debug #LF         ; displays 10
   #LF = 10          ; no error
   Debug #LF         ; displays 10
EndDeclareModule

Module Ascii
EndModule


Debug #LF            ; displays 10
; Debug Ascii::#LF     ; --> Constant not found: #LF.

Without the last line, everything works fine.
After uncommenting the last line, the error message "Constant not found: #LF." is raised.
But #LF actually is known at that position, as we see when the last line is commented.
So I think the error message should read: "Constant not found: Ascii::#LF."
That would explain the problem more accurate.

[Erich]

So I think the error message should read: "Constant not found: Ascii::#LF."
That would explain the problem more accurate.

Hm, I don't think that's much better. It should read: "Attempt to redefine global constant #LF in module Ascii. You cannot redefine global constants.", and the error should occur at the line of the constant definition in the module, not at the place where the constant is first used.

Anyway, thanks for all the help. I understand now. It's not a great design decision, but changing it seems complicated, it'd require import, export and renaming of module identifiers and giving PB identifiers a namespace of their own. Not really worth the effort, I guess. I just missed the thread where it was discussed already and was a bit dumbfounded by the error message.

[Little John]

So I think the error message should read: "Constant not found: Ascii::#LF."
That would explain the problem more accurate.

Hm, I don't think that's much better. It should read: "Attempt to redefine global constant #LF in module Ascii. You cannot redefine global constants.", and the error should occur at the line of the constant definition in the module, not at the place where the constant is first used.

I agree, that's much better.

[mestnyi]

Code: Select all

Enumeration #PB_Event_FirstCustomValue 
 #Test 
EndEnumeration  

DeclareModule Test
  Debug #Test
EndDeclareModule

Module Test
  Debug #Test 
EndModule  

How to use a custom constant in the inside of the module?

[mhs]

Code: Select all

DeclareModule Test
  Enumeration #PB_Event_FirstCustomValue 
   #Test 
  EndEnumeration  
EndDeclareModule

Module Test
  Debug #Test 
EndModule  

put the enumeration into the same module declaration or make a separate module ("main" for example)

Code: Select all

DeclareModule Main
  Enumeration #PB_Event_FirstCustomValue 
   #Test 
  EndEnumeration  
EndDeclareModule

Module Main
  Debug #Test
EndModule Main

DeclareModule Test
EndDeclareModule

Module Test
  Debug Main::#Test 
EndModule  

[mestnyi]

mhs Thank you, so I did
He puts constant in module
But the question remains , if not how to be placed ?

Now another question.

Why is the first case everything runs smoothly and the second compiler swears?

Code: Select all

#Test = 5

DeclareModule Test
  #Test = 15
EndDeclareModule

Module Test
  Debug #Test
EndModule

Debug Test::#Test 
Debug #Test

Code: Select all

#Test = 5

DeclareModule Test
  #Test = 15
EndDeclareModule

Module Test
  Debug #Test
EndModule

UseModule Test
Debug #Test
UnuseModule Test
Debug #Test