enumerations 
Author Message
 enumerations


Quote:
> TYPE

>   Colour = SHORTINT; (* that much storage is needed in this case *)

> CONST

>   ColourRed = 0;      MinColour = ColourRed;
>   ColourGreen = 1;
>   ColourBlue = 2;
>   ColourWhite = 3;
>   ColourYellow = 4;   MaxColour = ColourYellow;

> With such naming conventions, the worst problems should go away, and there
> would be a good chance that any programmer who doesn't update the Min/Max-
> constants (given either well-known conventions and/or clear comments) will
> cause a lot more trouble in your application.

This is a nifty work-around for an inherent problem in the compiler.  However,
it _increases_ the amount of typing that is necessary to enter a list of
constants and runs the risk of making code unreadable with long names for
constants.  As you point out, maintenance is still a problem, especially if
someone attempts to extend this enumeration by adding more colours in another
module.  What happens to MinColour/MaxColour when more colours are added in
another module?  If the max value is redefined in the new module, how does one
know which maximum is the _real_ maximum?

Compare the above with the concise definition possible with other languages
such as Modula-2, Ada-9x, and C++ (syntax may vary):

MODULE M1;

TYPE
  Colour = (Red, Green, Blue, White, Yellow);

Which is clearer from a maintenance and readability point of view?  Of course,
Wirth's original concern of how to extend this enumeration in a separately
compiled module is still a valid point.  I would suggest a syntax like the
following to extend the Colour type:

MODULE M2;

IMPORT M1;

TYPE
  MoreColour  = M1.Colour(Orange, Purple, Magenta, Black);
  OtherColour = M1.Colour(Cyan, Fusia, Lavender);

Here the MoreColour type is an extension of Colour and follows the same sort
of rules concerning assignment and type compatibility as do integer type
inclusions: MoreColour includes all values of Colour.  Thus Colour variables
are compatible with and assignable to MoreColour variables but not vice versa.
MoreColour _is not_ compatible with OtherColour but both can be assigned from
Colour variables.

MIN(MoreColour) gives Red      MIN(Colour) gives Red
MAX(MoreColour) gives Black    MAX(Colour) gives Yellow

SYSTEM.VAL(SHORTINT, MIN(Colour))      gives 0
SYSTEM.VAL(SHORTINT, MAX(Colour))      gives 4
SYSTEM.VAL(SHORTINT, MAX(MoreColour))  gives 8
SYSTEM.VAL(SHORTINT, MAX(OtherColour)) gives 7

There may be problems with this sort of mechanism.  If so, I'd appreciate using
this forum to discuss these issues.

Michael Griebling
Evolutionary conundrum: If two heads are better than one, why are there no
two-headed animals?



Sat, 29 Mar 1997 21:29:11 GMT  
 enumerations

Quote:

>> I wrote
>> Problem:  Enumeration values become dependent on compile order.
>> Example:  Consider using an enumeration in a persistent object that is
>>          written to disk on computer A, and then moved to computer B.

>> Computer A has compiled the modules (a, b, c) in this order: abc
>> Computer B has compiled the modules (a, b, c, d) as: abdc

>> The possibility exists that module 'd' will usurp [take away] the
>> enumeration values used by computer A's module 'c', and cause the
>> persistent object model to be broken.

>Huh?  Can you give a more complete example?  Assuming statically-declared
>enumerations (see my earlier response), how do enumerations become dependent
>on compilation order?

Certainly.  I've included some of the relevant stuff from one of your
other posts -- I hope I picked the right one.

Quote:
>Revise the way ENUMERATIONs are used to the following:

>MODULE Colors;
>  ENUMERATION Color = (Red, Green, Blue);
>BEGIN
>END Colors.

>Then an importing client could say:

>MODULE Client1;
>  IMPORT Colors;
>  ENUMERATION Color2 = Colors.Color(Cyan, Magenta, Yellow);
>BEGIN
>END Client1.

First, I ask why you really need enumerations.  If you have so many
exported enumerations from a module that the types and use of these
integers is becoming a burden -- a burden that you want to introduce more
typing into the language -- would you accept that perhaps you can rethink
the design of the external projection of the module?  Perhaps a different
design will remove a lot of these integers?

Let us consider our favorite example: ebmedded elements in Write.
Suppose, for the moment that Write has an enumeration 'A'.  Let us also
assume that the members of the enumeration are small integers with no
dynamic information stored at runtime -- they are purely compile time
constructs which translate into a statically typed integer.  (I fear that
having a dynamic type of an enumeration would add some noticable overhead
to the way many people program -- although some of the problems in the
implementation could be avoided).

Example (slightly different from my original intent).

Suppose you purchase, from NerdulaWare (a wholly owned subsidiary of New
Zealand Corp), a module which gives you unimaginable power by extending
Write's A enumeration in wondrous and creative ways (it adds some
members).

Then, being the jelly-kneed type who loves a good adverti{*filter*}t at the end
of a Jerry Pournelle article in Byte, you rush out and buy Ganemede Macro
Software's (whose slogan is: Out Of This World Software At Prices You
Can't Afford) competing module which extends Write's A in a slightly
different, but (according to them) 'Ohh, so much better' fashion.

These two modules know not of each other's existence -- the Nerdula
extension of A will have the exact same integer values as the GMS version
of the extension, yet they will be completely different in meaning and
(static) type.

It would be possible, at this point, to assign a GMS value to a Nerdula
enumeration by going through a variable of type Write.A.  Clearly, this
is wrong, but it is a possiblity with this mechanism.

Even if some mechanism is provided that assigns enumerations values that
do not overlap (i.e.: similar to the databank of template expansions in
C++), mixing object modules from different sources (that is, different
companies) does not guarantee this non-overlap since a foreign module's
compilation information will never be available.

Since there is overlap, dynamic type information would be required to
ensure that no runtime mismatches occur -- and this increases the size of
the enumeration.

[Enumeration size digression:
  If you limited total elements in an enumeration to MIN(SHORTINT), and
  the total enumerations in the system to MIN(SHORTINT), you could get by
  with a special encoding an have 1 byte enumerations (1/2 = enumeration,
  1/2 = index into enumeration type table).  Too limiting.

  You could go upwards to allowing a 24 bit index into an enumeration table
  and a maximum of 255 elements in an enumeration and have 4 byte
  enumerations using similar schemes.  If you get to this point, the
  advantages of the enumeration are all but lost -- overhead in the program.
]

People have been talking off and on for sometime about enumerations in
Oberon, but not a single person has posted a concrete example of why they
absolutely need an enumeration.  Could one of the proponents do so?

As good examples of why an enumeration is not really needed:
{Display.replace, Display.invert, Display.paint} and
{Texts.insert, Texts.replace, Texts.delete}.

Although there is a visible overlap of constant names, I have not pulled
out one hair from my head, nor have I run screaming to the hills in
confusion over this problem.  Maybe it's just me, but it is blindingly
obvious which I need to use and at which point in a program.

Taylor Hutt, Query Central
Is the 'elite' Iraqi Republican Guard affiliated with the US Republican Party?



Sun, 30 Mar 1997 20:12:49 GMT  
 enumerations

|>
|> People have been talking off and on for sometime about enumerations in
|> Oberon, but not a single person has posted a concrete example of why they
|> absolutely need an enumeration.  Could one of the proponents do so?

Strictly speaking, we don't *need* anything above machine
language. But we find it useful to express ourselves using
various abstractions.

Enumerations have proven to be a useful abstraction to
think in, and help reduce the number of mistakes that can
be made without the compiler noticing.

MODULE TrafficLights;

TYPE
        Phase = (red, yellow, green);

PROCEDURE ScheduleChange(to: Phase; afterSeconds: INTEGER);

BEGIN
        ScheduleChange(green, 42);
END TrafficLights.

Notice that I can't accidentally say ScheduleChange(42, green)
which I would be allowed to do if the colours were just
integer constants.

Is that concrete enough?

|> Taylor Hutt, Query Central

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,          | A citizen of NewZealandCorp, a       |
Christchurch, New Zealand          | wholly-owned subsidiary of Japan Inc.|



Mon, 31 Mar 1997 05:41:03 GMT  
 enumerations

There's a lot of talk here about extending enumerations,
but it's not clear to me why it's desirable for them
to be extensible, or even what such a thing would mean.

Could someone give an example of what an extensible
enumeration would be used for, and how it would work?

|>
|> Here the MoreColour type is an extension of Colour and follows the same sort
|> of rules concerning assignment and type compatibility as do integer type
|> inclusions: MoreColour includes all values of Colour.  Thus Colour variables
|> are compatible with and assignable to MoreColour variables but not vice versa.
|> MoreColour _is not_ compatible with OtherColour but both can be assigned from
|> Colour variables.

But that's more or less the *opposite* of the rules that
apply to record extensions!

If enumeration extensions are to behave analogously to
record records, then it should be possible to
assign a value of type MoreColour to a variable of
type Colour, provided it is one of the legal values
for Colour.

But I can't really see what the use of this would be
in practice. Can anyone give an example?

|> Michael Griebling

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,          | A citizen of NewZealandCorp, a       |
Christchurch, New Zealand          | wholly-owned subsidiary of Japan Inc.|



Mon, 31 Mar 1997 05:50:59 GMT  
 enumerations


Quote:

> Let us consider our favorite example: ebmedded elements in Write.
> Suppose, for the moment that Write has an enumeration 'A'.  Let us also
> assume that the members of the enumeration are small integers with no
> dynamic information stored at runtime -- they are purely compile time
> constructs which translate into a statically typed integer.  (I fear that
> having a dynamic type of an enumeration would add some noticable overhead
> to the way many people program -- although some of the problems in the
> implementation could be avoided).

> Example (slightly different from my original intent).

> Suppose you purchase, from NerdulaWare (a wholly owned subsidiary of New
> Zealand Corp), a module which gives you unimaginable power by extending
> Write's A enumeration in wondrous and creative ways (it adds some
> members).

> Then, being the jelly-kneed type who loves a good adverti{*filter*}t at the end
> of a Jerry Pournelle article in Byte, you rush out and buy Ganemede Macro
> Software's (whose slogan is: Out Of This World Software At Prices You
> Can't Afford) competing module which extends Write's A in a slightly
> different, but (according to them) 'Ohh, so much better' fashion.

> These two modules know not of each other's existence -- the Nerdula
> extension of A will have the exact same integer values as the GMS version
> of the extension, yet they will be completely different in meaning and
> (static) type.

> It would be possible, at this point, to assign a GMS value to a Nerdula
> enumeration by going through a variable of type Write.A.  Clearly, this
> is wrong, but it is a possiblity with this mechanism.

> Even if some mechanism is provided that assigns enumerations values that
> do not overlap (i.e.: similar to the databank of template expansions in
> C++), mixing object modules from different sources (that is, different
> companies) does not guarantee this non-overlap since a foreign module's
> compilation information will never be available.

> Since there is overlap, dynamic type information would be required to
> ensure that no runtime mismatches occur -- and this increases the size of
> the enumeration.

> People have been talking off and on for sometime about enumerations in
> Oberon, but not a single person has posted a concrete example of why they
> absolutely need an enumeration.  Could one of the proponents do so?

> As good examples of why an enumeration is not really needed:
> {Display.replace, Display.invert, Display.paint} and
> {Texts.insert, Texts.replace, Texts.delete}.

> Although there is a visible overlap of constant names, I have not pulled
> out one hair from my head, nor have I run screaming to the hills in
> confusion over this problem.  Maybe it's just me, but it is blindingly
> obvious which I need to use and at which point in a program.

> Taylor Hutt, Query Central
> Is the 'elite' Iraqi Republican Guard affiliated with the US Republican Party?

Your example is exactly what my proposal was intended to address.  The
modules are incompatible.  Within the current language/OS, the only way to
detect that is when you start encountering bugs.  With the proposal I set
forth, you know at load time that you have a couple modules that do not
work together.

Enumeration was almost certainly a bad name for the construct I was looking
for.  Basically I want to say that this constant belongs to a particular
class/category/enumeration and no other constant defined as belonging to
this class/category/enumeration should have the same value.  This should be
detected this at compile time where possible and at run time otherwise.

Using 32-bit values for a lot of these things together with a reasonably
simple centralized registry would probably resolve a lot of these problems.
 For example consider a value allocation scheme based on the following
subdivisions:

16 bits to identify a "distributing group" -- e.g. company, institution

The remaining 16 bits are to be managed by the distributing group.

So, for example, Adobe would contact the Oberon Enumeration Distribution
Service and request a 16-bit value which would be guaranteed unique to
Adobe.  Within Adobe, we could then pursue whatever allocation strategy we
wanted for the other 16 bits.

(I'm not firmly set on 16/16.  It's just a natural breakpoint.)

Even with such a scheme, I think a way of enforcing uniqueness is probably
still valuable to catch when the system breaks down or is ignored.

Mark Hamburg
Adobe Systems, Inc.



Mon, 31 Mar 1997 00:16:06 GMT  
 enumerations
On Oct 12, Taylor Hutt wrote (in part):

Quote:
> People have been talking off and on for sometime about enumerations in
> Oberon, but not a single person has posted a concrete example of why they
> absolutely need an enumeration.  Could one of the proponents do so?

There is no more need for enumerations than there is for the FOR loop.  Both
simply make programming easier for the progammer and ensure that code is
robust by preventing small problems such as neglecting to terminate a loop
in the former and enforcing type-safe assignments in the latter.  The two
main reasons (I see) for using enumerations are:

1) They give us type-safe assignments. (e.g., Assume module A contains a
   constant called "FailSafe = 3" and module B contains a similarly-named
   constant "FailSafe = 5".  A programmer has no way of knowing whether
   module A or B should be used in a specific assignment.  Both may mean
   the same thing (i.e., the original designer's finger slipped and he
   mistyped the value) or they may be intended to be different in which
   case a variable such as "Reactor : SHORTINT" can be assigned either
   value.  Of course, the user(s) of the Reactor variable knows what was
   intended but the programmer (who doesn't have the source) will never
   know.  Typed enumerations give a hint to the programmer of what the
   module designer intended.  The compiler enforces these intentions.)

2) They make it simple to declare long lists of enumerations (such as are
   typical in parsers, compilers, etc.).  Wirth neatly sidestepped the
   issue by using numbers in most places in his compiler.  I sure wouldn't
   want to maintain the software if someone decides to extend the
   compiler by inserting an element somewhere and all the numbers shift
   by a count or two. ;-)

Quote:
> As good examples of why an enumeration is not really needed:
> {Display.replace, Display.invert, Display.paint} and
> {Texts.insert, Texts.replace, Texts.delete}.
> Although there is a visible overlap of constant names, I have not pulled
> out one hair from my head, nor have I run screaming to the hills in
> confusion over this problem.  Maybe it's just me, but it is blindingly
> obvious which I need to use and at which point in a program.

I agree, as long as you aren't using third party software, you would know
exactly what was meant by the above two declarations.  However, I can't
easily see what you intended by these two declarations or even why I
couldn't say:

 {Texts.insert, Display.invert, 12}

This new declaration may or may not make sense.  I can't tell -- that's why
we need typed enumerations.

Mike Griebling, Enumerations forever
Safe programming should not be left to the programmer (or why I hate C)



Sun, 30 Mar 1997 23:15:10 GMT  
 enumerations

Quote:
> If enumeration extensions are to behave analogously to
> record records, then it should be possible to
> assign a value of type MoreColour to a variable of
> type Colour, provided it is one of the legal values
> for Colour.

mea culpa -- your definition is correct.

Quote:
> But I can't really see what the use of this would be
> in practice. Can anyone give an example?

I suppose operating system message identifiers and persistant object extensions
might be two examples but I'm not too hot on extensible enumerations.  I
just thought everyone else felt it was necessary.  I could live with the
old enumerations that Modula-2 provided.

Mike Griebling



Mon, 31 Mar 1997 19:21:47 GMT  
 enumerations

: MODULE M1;
: TYPE
:   Colour = (Red, Green, Blue, White, Yellow);

: MODULE M2;
: IMPORT M1;
: TYPE
:   MoreColour  = M1.Colour(Orange, Purple, Magenta, Black);
:   OtherColour = M1.Colour(Cyan, Fusia, Lavender);

: Here the MoreColour type is an extension of Colour and follows the same sort
: of rules concerning assignment and type compatibility as do integer type
: inclusions.

I think they should follow the usual rules of type extension instead.
MoreColour is the direct extension of Color. Color is the direct base
of MoreColor. In my experience enumerations are used most often to
implement states or modes and properties such as MIN, MAX and VAL
are meaningless. I suspect that designs requiring these numeric operators
and other properties ( eg. storage size of INTEGERs ) would be better
implemented using INTEGER's.

:  Of course,
: Wirth's original concern of how to extend this enumeration in a separately
: compiled module is still a valid point.

You could get extensibility by adding type tags and descriptors to the
design. Of course you should use these to implement type-guards and
type-tests just they are done for records.

VAR
        b : Color; (* base )
        e : MoreColor; (* extension *)
BEGIN
        IF b IS MoreColor THEN
                e := b(MoreColor);
                IF e = M2.Orange THEN
                        ..
                END;
        END;
END

Also, you should not forget null modes/states/enumerations.

SubMsg = ();
Modify = SubMsg( extend, reduce );

-- Whitney



Mon, 31 Mar 1997 22:33:38 GMT  
 enumerations

Quote:



>> Let us consider our favorite example: ebmedded elements in Write.
>> Suppose, for the moment that Write has an enumeration 'A'.  Let us also
>> assume that the members of the enumeration are small integers with no
>> dynamic information stored at runtime -- they are purely compile time
>> constructs which translate into a statically typed integer.  (I fear that
>> having a dynamic type of an enumeration would add some noticable overhead
>> to the way many people program -- although some of the problems in the
>> implementation could be avoided).

>> Example (slightly different from my original intent).

>> Suppose you purchase, from NerdulaWare (a wholly owned subsidiary of New
>> Zealand Corp), a module which gives you unimaginable power by extending
>> Write's A enumeration in wondrous and creative ways (it adds some
>> members).

[I wrote it, I can delete it.]

Quote:
>Your example is exactly what my proposal was intended to address.  The
>modules are incompatible.  Within the current language/OS, the only way to
>detect that is when you start encountering bugs.  With the proposal I set
>forth, you know at load time that you have a couple modules that do not
>work together.

Yes, I see that your mechanism is supposed to trap this but I don't agree
that it is a good thing.  The interface for the module has not changed,
yet there may be some incompatability.  Now that really is a hidden cost
that would confuse the end-user to no end.

user: MM on command
computer: "I am terribly sorry, but I cannot load that text file because
           some perisistent objects have been used and one says the color
           blue is 1 and the other says the color red is 1"
user: "But those are commercial extensions to the base Oberon
       system; one piece was written by a ring-tailed lemur on Sri Lanka
       and the other by a mute hacker living in Cat Spit, Nebraska.  I
       don't have source code and I can't speak lemur or hacker."
computer: "Too bad; it's not my job to load globally uncoordinated software"

Well, you get the idea.  In essence, I think a terrible burden is being
placed on the programmer and user by this mechanism.  The size of the
enuemration is fairly well immaterial at this stage in history, but
requiring a registry is surely another unrealistic burden for a
programming construct as common as an identifying integer.  But, all in
all, if implemented Adobe should get 0ADBEH as it 16bit identifier!

Taylor Hutt, a wholly owned subsidiary of the US national debt
FBI: Fat, Bald & Ignorant



Mon, 31 Mar 1997 19:35:46 GMT  
 enumerations

Quote:


>|>
>|> People have been talking off and on for sometime about enumerations in
>|> Oberon, but not a single person has posted a concrete example of why they
>|> absolutely need an enumeration.  Could one of the proponents do so?

>Strictly speaking, we don't *need* anything above machine
>language. But we find it useful to express ourselves using
>various abstractions.

>Enumerations have proven to be a useful abstraction to
>think in, and help reduce the number of mistakes that can
>be made without the compiler noticing.

>MODULE TrafficLights;
>TYPE
>    Phase = (red, yellow, green);
>PROCEDURE ScheduleChange(to: Phase; afterSeconds: INTEGER);
>BEGIN ScheduleChange(green, 42);
>END TrafficLights.

>Notice that I can't accidentally say ScheduleChange(42, green)
>which I would be allowed to do if the colours were just
>integer constants.

>Is that concrete enough?

Sorry, no.  Call me stubborn, but Oberon is not a real-time language and
using real-time constructs to justify a change in the Oberon langauge
just does not seem to be completely valid.

I am looking for a real Oberon example where integers are not clear and
sufficiently dismbiguated to fit the bill.

Taylor Hutt, cranky young man
Baltimore Road Rule: Never signal when changing lanes -- it shows your intent.



Mon, 31 Mar 1997 19:40:40 GMT  
 enumerations

Quote:


>> > Traffic light example deleted

>> Sorry, no.  Call me stubborn, but Oberon is not a real-time language and
>> using real-time constructs to justify a change in the Oberon langauge
>> just does not seem to be completely valid.


>  "Oberon-2 is a _general-purpose_ language in the tradition of Oberon
>   and Modula-2."

>If a general-purpose language cannot be used for real-time constructs,
>what is it used for?

Sorry, that is not what I meant.
Let me put it more pointedly:  If you have nuclear reactor control
software or a traffic light control package in use with Oberon (or
currently under development), then the examples are valid.  If you don't
have either of these, then your examples are contrived.

Taylor Hutt, Medical Advisor to the Stars
Never put a tourniquet around your neck.



Tue, 01 Apr 1997 20:28:24 GMT  
 enumerations

Quote:
> >...
> >If a general-purpose language cannot be used for real-time constructs,
> >what is it used for?

> Sorry, that is not what I meant.
> Let me put it more pointedly:  If you have nuclear reactor control
> software or a traffic light control package in use with Oberon (or
> currently under development), then the examples are valid.  If you don't
> have either of these, then your examples are contrived.

I guess we'll have to get back to you once we've developed an Oberon
extension using extensible enumerations which is used in a `Real-world'
application (i.e., who can demonstrate enumeration extensions when they
aren't even supported by the language?).  If the language supports it,
it will be used.

Mike Griebling
The chicken or the egg: which came first?



Tue, 01 Apr 1997 21:43:04 GMT  
 enumerations

Quote:
> > Traffic light example deleted
> Sorry, no.  Call me stubborn, but Oberon is not a real-time language and
> using real-time constructs to justify a change in the Oberon langauge
> just does not seem to be completely valid.


  "Oberon-2 is a _general-purpose_ language in the tradition of Oberon
   and Modula-2."

If a general-purpose language cannot be used for real-time constructs,
what is it used for?

Mike Griebling, Author of "Oberon RT" -- a real-time dialect which uses
enumerations.  "The language which is a `true extension' of Oberon-2"



Tue, 01 Apr 1997 00:25:37 GMT  
 enumerations

Quote:
> : Here the MoreColour type is an extension of Colour and follows the same sort
> : of rules concerning assignment and type compatibility as do integer type
> : inclusions.

> I think they should follow the usual rules of type extension instead.

  ...

I stand corrected.

Quote:
> In my experience enumerations are used most often to implement states or
> modes and properties such as MIN, MAX and VAL are meaningless.

Actually, MIN/MAX could prove useful in performing FOR iterations which
must initialize arrays indexed by enumerations, etc.  I agree about VAL --
it probably is not as useful.

Quote:
> You could get extensibility by adding type tags and descriptors to the
> design. Of course you should use these to implement type-guards and
> type-tests just they are done for records.

  ... example deleted

Type-guards and type-tests would be a consistent way of adding enumeration
extensions but I'm not sure that type tags and descriptors would be needed.
How can a variable ever change its type? -- we're not talking about using
pointers here.  The compiler can do runtime range checks when compatible
types are assigned.  For the `IS', the compiler would probably check whether
the value of the variable is within the enumeration range.

Quote:
> Also, you should not forget null modes/states/enumerations.

  ... example deleted

Good idea!

Mike Griebling



Tue, 01 Apr 1997 01:00:30 GMT  
 enumerations

Quote:
> user: MM on command
> computer: "I am terribly sorry, but I cannot load that text file because
>            some perisistent objects have been used and one says the color
>            blue is 1 and the other says the color red is 1"
> user: "But those are commercial extensions to the base Oberon
>        system; one piece was written by a ring-tailed lemur on Sri Lanka
>        and the other by a mute hacker living in Cat Spit, Nebraska.  I
>        don't have source code and I can't speak lemur or hacker."
> computer: "Too bad; it's not my job to load globally uncoordinated software"

Every time Prof. Wirth does something, I spend several months wondering
why he did such a fool thing, given his record.  Later, I tend to think he
has earned his reputation again.  But the removal of enumerations has
proven to take considerably longer than the other changes.

I guess I cannot envision these difficulties.  To whit:

MODULE Reactor;
TYPE
  State = (Ok, Warning );
  WasteLevel   = (Low, Medium, High);
  IDType       = (ID0, ID1, ID2, ID3, ID4);

  Msg = POINTER TO ReactorDesc;
  ReactorDesc = RECORD
    Current : ReactorState;
    Level : WasteLevel;
    ID : IDType;
  END;
END Reactor.

MODULE Graphite; (*By Comrade Software, msk*)
        IMPORT Reactor;
        TYPE
                ReactorState = ( Reactor.State, Critical,  Burning ); (*extension syntax*)
                Msg = POINTER TO MsgDesc;
                MsgDesc = RECORD (Reactor.Msg) END;
END Graphite.

MODULE Water;
(* By HersheyWare, melts in your mouth, not your reactor *)
        IMPORT Reactor;
        TYPE
                ReactorState = (Reactor.State, Critical, Hydrogen );
                Msg = POINTER TO MsgDesc;
                MsgDesc = RECORD (Reactor.Msg) END;
END Water.

MODULE Panel;
        IMPORT (*Graphite*) Water;

        PROCEDURE Handler*( msg : Msg );
        BEGIN
                (*compile time error*)
                IF msg.Current = Graphite.Critical
                THEN AddHelium

                (*valid for this control panel*)
                ELSIF msg.Current = Water.Critical
                THEN AddOldRangerBorax

                (*Ambiguouity discussed in this thread, compile time error,
                 * type assignment violation. *)
                ELSIF msg.Current = 2
                THEN CussAndPray

                (*compile time error*)
                ELSIF msg.Current = Graphite.Burning
                THEN CallPravda

                (* valid for this control panel *)
                ELSIF msg.Current = Water.Hydrogen
                THEN CallHarrisburgFreePress
                END
        END Handler;

END Panel.

Quote:
>Organization: Police named Claridge in Baltimore County, MD are LIARS!

See  the Denver item in my www page.  Propogate the html as you please.
Updates envisioned.

--
http://wwwhost.cc.utexas.edu/~aubrey



Tue, 01 Apr 1997 00:46:47 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Follow up on enumerations

2. Eiffel enumerations

3. Reading ActiveX Control Enumerations

4. Fanaticism [was Re: Enumerations and Arrays Unnecessary!???]

5. Size of enumerations/subranges in Modula-2

6. Size of enumerations/subranges in Modula-2

7. Enumerations

8. Enumerations - slow down a minute!

9. Enumerations in Eiffel

10. Pattern for enumerations? (Attn: Roger Browne)

11. Enumerations in Oberon (was: Re: Enumerated types)

12. enumerations

 

 
Powered by phpBB® Forum Software