Scope confusion

[August]

Hello all,

Consider the following two modules:

MODULE M0;
TYPE T0* = RECORD x: INTEGER END;
END M0.

MODULE M1;
IMPORT M0;
TYPE T1 = RECORD (M0.T0) x: REAL END;
END M1.

If I compile the modules with the OOC compiler everything works fine,
but with the XDS compiler I get an error message about x allready
being defined in T0. According to "The Programming Language Oberon-2",
section 6.3 about record types:

"If a record type is exported, field identifiers that are to be
visible outside the declaring module must be marked. They are called
`public fields'; unmarked elements are called `private fields'."

It further says that:

"All identifiers declared in the extended record must be different
from the identifiers declared in its base type record(s)."

(Note the absence of "public" before the second occurence of
"identifiers").

So which compiler is the faulty one?

Regards,
August

[Chris Burrows]

Post by August
So which compiler is the faulty one?

XDS.

An identifier that is not exported from a module is invisible to client
modules.

Look at the situation from a practical point of view. You should be able to
extend M0.T0 even if you do not have the source code for M0 - all you need
to know is the interface. If you did not have the source code how could you
ever hope to know which identifier names to avoid?

Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp

[Ondrej Hrabal]

Post by Chris Burrows

Post by August
So which compiler is the faulty one?

XDS.
An identifier that is not exported from a module is invisible to client
modules.
Look at the situation from a practical point of view. You should be able to
extend M0.T0 even if you do not have the source code for M0 - all you need
to know is the interface. If you did not have the source code how could you
ever hope to know which identifier names to avoid?
Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp

I've never noticed this. If it is this way, then it's a pretty serious
problem. And I don't really understand how this is possible at all.
That would mean that the private features are being stored in the
symbol files, too. Why? It had to take a big effort to implement this
fault... :-(

Regards, Andy

[Christian Demmer]

Post by Ondrej Hrabal
problem. And I don't really understand how this is possible at all.
That would mean that the private features are being stored in the
symbol files, too. Why? It had to take a big effort to implement this
fault... :-(

I don't know XDS but as far as I know they have a C backend.
What I know is that my own Compiler has the same fault. If you generate
(high level) C code you need all fields of the record to get the
alignment right (or you need to handle the alignment manually), and
therefore you need some names to generate the structs in C.
Straightforward solution is to use the original ones you only have to
include them in the symbol file.
Since the problem does not occur often I was too lazy to fix this, which
is not very easy because of the requirements of C code generation.

A compiler generating machine code or low level C does not need this
info, it will work happily with a field offset.

Greetings, Christian

[Ondrej Hrabal]

Post by Christian Demmer

Post by Ondrej Hrabal
problem. And I don't really understand how this is possible at all.
That would mean that the private features are being stored in the
symbol files, too. Why? It had to take a big effort to implement this
fault... :-(

I don't know XDS but as far as I know they have a C backend.
What I know is that my own Compiler has the same fault. If you generate
(high level) C code you need all fields of the record to get the
alignment right (or you need to handle the alignment manually), and
therefore you need some names to generate the structs in C.
Straightforward solution is to use the original ones you only have to
include them in the symbol file.
Since the problem does not occur often I was too lazy to fix this, which
is not very easy because of the requirements of C code generation.
A compiler generating machine code or low level C does not need this
info, it will work happily with a field offset.
Greetings, Christian

The C back-end would explain everything. There exists a version of XDS
using a C back-end, as well as one with a native code generator.

Andy

[August]

Post by Chris Burrows
An identifier that is not exported from a module is invisible to
client modules.
Look at the situation from a practical point of view. You should be
able to extend M0.T0 even if you do not have the source code for
M0 - all you need to know is the interface. If you did not have the
source code how could you ever hope to know which identifier names
to avoid?

Yes, that ought to be the expected behaviour. I guess the XDS compiler
developers interpretated the sentence:

"All identifiers declared in the extended record must be different
from the identifiers declared in its base type records(s)"

incorrectly. The above is true if the extended record along with all
its base type records are declared in the same module. Maybe the
sentence should be clarified as:

"All identifiers declared in the extended record must be different
from the *visible* identifiers declared in its base type records(s)"

-- August

[Chris Burrows]

incorrectly. The above is true if the extended record along with all its
base type records are declared in the same module. Maybe the sentence
"All identifiers declared in the extended record must be different from
the *visible* identifiers declared in its base type records(s)"

To me that would be merely stating the obvious. Note that in the
introduction of the language report it states:

"This report is not intended as a programmer's tutorial. It is intentionally
kept concise. Its function is to serve as a reference for programmers. What
remains unsaid is mostly left so intentionally, either because it can be
derived from stated rules of the language, or because it would require to
commit the definition when a general commitment appears as unwise."

Your example or something similar would be an excellent one to use in a
Programmer's Tutorial, when discussing the finer points of scope rules.

Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp

[August]

Post by Chris Burrows

Post by August
"All identifiers declared in the extended record must be different
from the *visible* identifiers declared in its base type
records(s)"

To me that would be merely stating the obvious.

I agree, any other interpretation would not make sense... but you
still wonder what made the XDS compiler developers do such a serious
misstake.

-- August

[Chris Burrows]

Post by August

Post by Chris Burrows

Post by August
"All identifiers declared in the extended record must be different
from the *visible* identifiers declared in its base type
records(s)"

To me that would be merely stating the obvious.

I agree, any other interpretation would not make sense... but you
still wonder what made the XDS compiler developers do such a serious
misstake.

Christian Demmer's earlier response in this thread (related to using a C
backend) seems a plausible explanation.

Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp