Warped Name Space 
Author Message
 Warped Name Space

Hi,

I was given a strange type declaration and now I am wondering how the
Oberon compilers out there react on this particular kind of
strangeness.  I'm especially interested to hear how ETH compilers
react on this piece of code:

MODULE T;

TYPE
  A* = RECORD
    b*: POINTER TO B
  END;
  B* = A;

  C* = RECORD
    c*: POINTER TO C
  END;

VAR
  a*: A; b*: B;
BEGIN
  a := b
END T.

I know that oo2c treats the type alias "B=A" wrong.  Can a forward
declaration of a pointer base type be resolved through an alias
declaration?

Regards,
Michael van Acken



Sat, 01 Dec 2001 03:00:00 GMT  
 Warped Name Space
MacOberon (ETH/OP2 based with FatBinary support) reports undeclared identifier
on B in the declaration of A.  The only kind of forward declaration allowed in
type declarations is that of pointer types before their record base types.

The declaration of C is accepted as is by the compiler.

Quote:
> MODULE T;

> TYPE
>   A* = RECORD
>     b*: POINTER TO B <<0: undeclared identifier>>
>   END;
>   B* = A;

>   C* = RECORD
>     c*: POINTER TO C
>   END;

> VAR
>   a*: A; b*: B;
> BEGIN
>   a := b
> END T.

--



Sat, 01 Dec 2001 03:00:00 GMT  
 Warped Name Space

Quote:

> I was given a strange type declaration

Obviously from some sort of demented "C" programmer ;-)

Quote:
> and now I am wondering how the
> Oberon compilers out there react on this particular kind of
> strangeness.  I'm especially interested to hear how ETH compilers
> react on this piece of code:

> MODULE T;

> TYPE
>   A* = RECORD
>     b*: POINTER TO B
>   END;
>   B* = A;

>   C* = RECORD
>     c*: POINTER TO C
>   END;

> VAR
>   a*: A; b*: B;
> BEGIN
>   a := b
> END T.

> I know that oo2c treats the type alias "B=A" wrong.  Can a forward
> declaration of a pointer base type be resolved through an alias
> declaration?

The BlackBox (1.3.1) Component Pascal compiler accepts this without any
complaints whatsoever.

Perhaps someone can test the new (1.3.2) BlackBox Oberon-2 compiler.

Cheers,
- Stewart



Sun, 02 Dec 2001 03:00:00 GMT  
 Warped Name Space

Quote:

> > I was given a strange type declaration

> Obviously from some sort of demented "C" programmer ;-)

Could you please explain what makes you "think" so?

Quote:

> The BlackBox (1.3.1) Component Pascal compiler accepts this without any
> complaints whatsoever.

Not even a C Compiler would accept similar code :-)

Sorry, I could not resist.

Christian.

--
Christian Luginbuehl



Sun, 02 Dec 2001 03:00:00 GMT  
 Warped Name Space
Quote:

> Hi,

> [...]
> I'm especially interested to hear how ETH compilers
> react on this piece of code:

[...]

not directly an ETH compiler :-)

Oberon Microsystem's Blackbox compiles it in both the
Component Pascal and the Oberon-2 mode without a glitch.

Browsing the symbol file yields:

DEFINITION T;

  TYPE
      A = RECORD
        b: POINTER TO A
      END;

      B = A;

      C = RECORD
        c: POINTER TO C
      END;

  VAR
    a: A;
    b: A;
END T.

--
    Bernhard Treutwein             Tel. +49-89-5996-642, Fax -615
    Institut f. Med. Psychologie  Ludwig-Maximilians-Universitaet

    --------------------------------  ---------------------------
    C is its own virus



Sun, 02 Dec 2001 03:00:00 GMT  
 Warped Name Space
Quote:

> Hi,

> [...]
> I'm especially interested to hear how ETH compilers
> react on this piece of code:

[...]

not directly an ETH compiler :-), but Oberon Microsystems
Blackbox compiles it in both the Component Pascal and the
Oberon-2 mode without a glitch. Browsing the symbol file yields:

DEFINITION T;

  TYPE
      A = RECORD
        b: POINTER TO A
      END;

      B = A;

      C = RECORD
      c: POINTER TO C
    END;

  VAR
    a: A;
    b: A;
END T.

regards

   Bernhard



Sun, 02 Dec 2001 03:00:00 GMT  
 Warped Name Space

Quote:


> > > I was given a strange type declaration

> > Obviously from some sort of demented "C" programmer ;-)

> Could you please explain what makes you "think" so?

Sorry. That was an "in" joke. I should explain...

I gave the original problematic declaration to Michael. While I do
occasionally regard myself as a "demented C programmer", I didn't
actually write the code. It was written in "C" and translated to
Oberon-2 by H2O, a tool that I am writing (admittedly, very slowly) for
the OOC project.

The offending declaration comes from the W3C's libwww header files.
Libwww implements various Web transport protocols (HTTP, FTP, etc) and
provides a useful framework for building Web clients and servers. It
also contains HTML and XML parsers.

The original libwww "C" code looks like this:

  typedef struct _HTList HTList;

  struct _HTList {
    void * object;
    HTList * next;
  };

This sort of declaration occurs several times within libwww. Currently,
H2O translates this code as:

   _HTList_struct* = RECORD
      object* : LONGINT (* void pointer *);
      next* : POINTER TO HTList
    END;

    HTList* = _HTList_struct;

Since most (but not all!) C compilers maintain separate namespaces for
typedef and struct types, it is theoretically legal to use the same name
twice. Thus, H2O appends "_struct" to all structure names to avoid
potential name clashes. This translation maintains the "spirit" of the
original "C", preserving both the type names _HTList and HTList. We
could argue about whether or not this is a good thing. Perhaps it would
be better to produce:

   HTList = RECORD
     object* : LONGINT (* void pointer *);
     next* : POINTER TO HTList
   END;

This is perfectly valid Oberon-2. The equivalent in "C" would be:

  struct _HTList {
    void * object;
    struct _HTList * next;
  };

However, people often like to express these things in terms of typedefs
so that "struct" can be omitted from declarations.

Quote:

> > The BlackBox (1.3.1) Component Pascal compiler accepts this without any
> > complaints whatsoever.

> Not even a C Compiler would accept similar code :-)

Most C compilers will accept this and more.

For example, the statement

  typedef struct _HTList HTList;

creates a forward declaration for "struct _HTList". This can later be
resolved by a structure declaration such as in the above. Occasionally,
forward declarations are left completely unresolved. You might think
that this is an error (I thought so!), but apparently not. This quirk is
occasionally (eg. in libwww) used to implement a form of "opaque"
structure type. To do this, I might put

  typedef struct _Foo Foo;

in my public declarations (foo.h), and only include the definition
(resolving the forward declaration) within my private implementation
code. If only one module implements foo, then the definition might go in
foo.c which #includes foo.h. If several modules implement foo, then I
might create a separate foo2.h which #includes foo.h, but fully defines
struct _Foo. This could then be #included by several private
implementation modules. To my clients I simply distribute foo.h, which
allows their compilers to know that Foo is a structure, but not its
definition.

Hence the term "demented".

- Stewart



Mon, 03 Dec 2001 03:00:00 GMT  
 Warped Name Space

according to the examples is the oberon2 deffinition, you should declare
that kind of thing as

   TYPE
      B = POINTER TO A;
      A = RECORD
         b : B;
      END;

maybe that's what the compiler has grown to accept..?

pedro gonnet

Quote:
> Hi,

> I was given a strange type declaration and now I am wondering how the
> Oberon compilers out there react on this particular kind of
> strangeness.  I'm especially interested to hear how ETH compilers
> react on this piece of code:

> MODULE T;

> TYPE
>   A* = RECORD
>     b*: POINTER TO B
>   END;
>   B* = A;

>   C* = RECORD
>     c*: POINTER TO C
>   END;

> VAR
>   a*: A; b*: B;
> BEGIN
>   a := b
> END T.

> I know that oo2c treats the type alias "B=A" wrong.  Can a forward
> declaration of a pointer base type be resolved through an alias
> declaration?

> Regards,
> Michael van Acken



Mon, 03 Dec 2001 03:00:00 GMT  
 Warped Name Space

Quote:
> according to the examples is the oberon2 deffinition, you should declare
> that kind of thing as

>    TYPE
>       B = POINTER TO A;
>       A = RECORD
>          b : B;
>       END;

> maybe that's what the compiler has grown to accept..?

Certainly.  But I am responsible for compiler, which explains my
interest in pathological cases.  The idea being, of course, to have
the compiler do the Right Thing(TM).  Because the language report is
no help here, I try to solve my problem by means of a public vote.
Currently the vote is in favor of permitting forward declarations to
be resolved by an alias declaration.

-- Michael van Acken



Mon, 03 Dec 2001 03:00:00 GMT  
 Warped Name Space

[Explanation]

Thanks for the in-deep explanation.

Quote:

> > > The BlackBox (1.3.1) Component Pascal compiler accepts this without any
> > > complaints whatsoever.

> > Not even a C Compiler would accept similar code :-)

> Most C compilers will accept this and more.

My statement refered to the fact that in

Quote:
> TYPE
>   A* = RECORD
>     b*: POINTER TO B

B has not been forward-declared.

As thus, it would be

struct A
{
   B* b;

and here, not knowing B, the compiler would complain.

I am still not certain wether I like the implicit forward declaration.

Quote:

> For example, the statement

>   typedef struct _HTList HTList;

> creates a forward declaration for "struct _HTList". This can later be
> resolved by a structure declaration such as in the above. Occasionally,
> forward declarations are left completely unresolved. You might think
> that this is an error (I thought so!), but apparently not. This quirk is

IMHO this is not a quirk at all. It is perfectly legal, AFIK it's called an
'incomplete type'.

Notice that you can also write

   struct _HTList;

on it's own.

Quote:
> occasionally (eg. in libwww) used to implement a form of "opaque"
> structure type. To do this, I might put

[Description of how to implement opaque types in C]

I did similar things in the past. If the client does not need to know
the internals of a type, it should not see it at all. I now use
a similar approach in C++ classes to hide the implementation details
from the public header file alltogehter.

Quote:
> Hence the term "demented".

Well, now, maybee I am demented, too. But I feel rather good at it :-)

Christian.

--
Christian Luginbuehl



Mon, 03 Dec 2001 03:00:00 GMT  
 Warped Name Space

Quote:



> > > > I was given a strange type declaration

> > > Obviously from some sort of demented "C" programmer ;-)

> > Could you please explain what makes you "think" so?

> Sorry. That was an "in" joke. I should explain...

> I gave the original problematic declaration to Michael. While I do
> occasionally regard myself as a "demented C programmer", I didn't
> actually write the code. It was written in "C" and translated to
> Oberon-2 by H2O, a tool that I am writing (admittedly, very slowly) for
> the OOC project.

From OOPiO2

A4 Declarations and Scope Rules

...
The scope of an object X extends textually from the point of its declaration
to the end of the block (module, procedure, or record) to which the
declaration
belongs and hence to which the object is local.
...

Seems absolutely clear that any compiler that doesn't execpt the 'demented'
code is incorrect WRT the Oberon-2 language spec.

Please guys, when you have questions about how something should be
implemented:

1) be intimately familiar with the language
2) be intimately familiar with the language spec
3) refer to the language spec when in doubt.

Please DO NOT rely on 'observed behavior' when something is clearly
documented.
If you ARE going to rely on 'observed behavior' of other products to determine

your behavior, DOCUMENT it so that the next person has something on which
to rely.

Taylor Hutt
Unemployed as of 5pm PDT 1999.06.16 (I quit, if you were wondering)



Mon, 03 Dec 2001 03:00:00 GMT  
 Warped Name Space

Quote:

> > > > The BlackBox (1.3.1) Component Pascal compiler accepts this without any
> > > > complaints whatsoever.

> > > Not even a C Compiler would accept similar code :-)

> > Most C compilers will accept this and more.

> My statement refered to the fact that in

> > TYPE
> >   A* = RECORD
> >     b*: POINTER TO B

> B has not been forward-declared.

> As thus, it would be

> struct A
> {
>    B* b;

> and here, not knowing B, the compiler would complain.

True.

- Show quoted text -

Quote:
> I am still not certain wether I like the implicit forward declaration.

> > For example, the statement

> >   typedef struct _HTList HTList;

> > creates a forward declaration for "struct _HTList". This can later be
> > resolved by a structure declaration such as in the above. Occasionally,
> > forward declarations are left completely unresolved. You might think
> > that this is an error (I thought so!), but apparently not. This quirk is

> IMHO this is not a quirk at all. It is perfectly legal, AFIK it's called an
> 'incomplete type'.

> Notice that you can also write

>    struct _HTList;

> on it's own.

Actually, I prefer this form. Although it declares an incomplete type,
it is at least a declaration. Without something like this, it can be
very hard to tell where a declaration comes from. This is because
incomplete types are also part of the forward reference mechanism;
reference to a type is actually a form of declaration.

For example, suppose I see:

  struct Node {
    struct Chunk * data;
    struct Node * next;
  };

This actually consitutes a legal declaration for "struct Chunk" as well
as "struct Node". It is not clear whether "struct Chunk" is a complete
type declared somewhere else (eg. in some other API header) or whether
it is an incomplete type that has not been further declared anywhere.
Verifying the absence of a further declaration can be difficult,
especially given the unstructured nature of the C's macro processing
phase (fortunately, we have tools like "grep" ;-). I believe that the
polite thing to do is to declare:

  struct Chunk;

separately so that the programmer at least knows that the type is
associated with the current header file and not with another one. This
still does not reduce the possibility of name clashes between modules.
For example, "struct Chunk" may actually be declared in another
unrelated header with a different meaning and implementation. The
compiler would then treat the reference as a forward reference to
another type, not the one whose definition you have carefully hidden.
Unless you are very careful, things can go horribly wrong.
Unfortunately, since C has no real notion of "module" it would be hard
to prevent this sort of thing.

Quote:
> > occasionally (eg. in libwww) used to implement a form of "opaque"
> > structure type. To do this, I might put

> [Description of how to implement opaque types in C]

> I did similar things in the past. If the client does not need to know
> the internals of a type, it should not see it at all. I now use
> a similar approach in C++ classes to hide the implementation details
> from the public header file alltogehter.

In a way, an incomplete type is a very limited form of abstract type. It
can't be (legally!) instantiated because its size is undefined. It can
be extended once, by its definition.

Fortunately, C++ has several other safer mechanisms that can be used to
separate definition and implementation of types. With C++ (and
Oberon-2), type extension can be used. Abstract types are probably
better, but only a few dialects of Oberon support these.

Quote:
> > Hence the term "demented".

> Well, now, maybee I am demented, too. But I feel rather good at it :-)

I'm sure it can be a very useful skill in many situations!

Cheers,
- Stewart



Mon, 10 Dec 2001 03:00:00 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. Name spaces - instantiation labels and entity names

2. Hyper-space WARP speed: Compile, Link and Test

3. Mass change of all Warp 3 URL's to Warp 4 URLs

4. Name spaces - is it really that simple?! [VW]

5. Spaces in Directory Names - Long Filenames

6. renaming name space

7. Name spaces - is it really that simple?! [VW]

8. Name spaces

9. Name Space Pollution

10. P2P Name-Space Project Need Comments

11. DRAFT Ved utility for editing files whose names have spaces

12. Name Space Pollution

 

 
Powered by phpBB® Forum Software