Path: utzoo!attcan!uunet!mcvax!kth!enea!naggum!isncr!m2cs!frode
From: frode@m2cs.uu.no (Frode Odegard)
Newsgroups: comp.lang.modula2
Subject: Re: Portable Oberon compiler
Summary: Portable Oberon compiler
Keywords: Oberon portable compiler ETH Wirth
Message-ID: <131@m2cs.uu.no>
Date: 7 Feb 89 11:18:36 GMT
References: <INFO-M2%89012710550179@DB0TUI11> <772@jungfrau.UUCP>
Organization: Modula-2 CASE Systems A.S, Oslo, Norway
Lines: 57

In article <772@jungfrau.UUCP>, marvin@jungfrau.UUCP (Rico und Jan) writes:
> In article <INFO-M2%89012710550179@DB0TUI11> Modula2 List <INFO-M2%UCF1VM.bitnet@jade.berkeley.edu> writes:
> In Oberon you can have so-called 'public projections'. This means
> you can have a partial definition of a record type in the definition
> part and the full definition of it in the implementation part (for
> details see the last paragraphs of the section "Type extension" from the
> paper "From Modula to Oberon"). This feature might be quite nice, but it
> introduces serious problems for the compiler. If the public projection
> (i.e. the declaration in the definition part) has a size smaller than
> the actual declaration in the implementation part, the compiler looks at
> the symbol file, and __patches__ it in order to have the size of the
> record fixed ! To avoid this, the portable Oberon compiler will have a
> slight modification to the language: you have to add a compiler hint in
> the definition part. It will then look like this (referring to the
> example in the paper): 
> 
> TYPE	Viewer = RECORD
> 		   width, height : INTEGER;
> 		   [8]
> 		 END;
> 
> The number indicates the size of the record as it will be in the
> implementation part. It's not quite clear to me if it is possible to
> give any size, even if it is bigger then the actual size in the
> implementation part. I hope It will be clear in their report.
> 

FTL Modula-2 supports structured opaque types by patching the symbol file.
You don't have to do it that way, but unless you want a monster linker
that's the way you do it. The Oberon language modification you mention
sort of takes away the whole beauty of public projection. The point of
public projection (and opaque types in Modula-2) is to _hide_ the
(parts of the) data stuructures you don't want the module's clients
to be able to touch and give the author of the implementation module
a choice of implementing data structures as well as procedures.
Declaring the size of the type T in the implementation part I
consider a crude solution, be it Oberon or Modula-2.

Still, I'm happy that someone's doing a portable Oberom compiler. As
Oberon is played with around the globe, I'm sure N.W. will get lots
of feedback. A couple of days ago, I heard someone say that type
extension could be the Modulean's answer to not having inheritence
in his language. Oberon is an experimental language of course, and
it lacks features many Moduleans wouldn't live without (like subrange
and enumeration types).

Has anyone looked into applying an Oberon-like manner of type extension
to Modula-2?  After doing some large-scale projects in Modula-2, I've
found a need for type extensions and/or parameterized types/modules.

				- Frode

-- 
| Frode L. Odegard         |"The world is coming to an end! Repent and|
| Modula-2 CASE Systems    |rm /bin/cc"                               |
| NORWAY (EUROPE)     	   |                                          |
| Email: frode@m2cs.uu.no  |                                          |