enumerations 
Author Message
 enumerations

Hello Y'all greetings from the Oberon world. We've been having a
disucssion over there on enumerated types (which are absent from
Oberon.)  Since modula-2 has them, I thought it would be interested to
hear your take on them. The debate seems to be tugging back and forth
between compiler complexity and user convenience.

----

Having enums does not necessarily imply having subranges and the
associated compiler complexity. It depends on how powerful one makes the
enums. i.e. what operations they support.  Consider the following
hierarchy:

(1) The simplest form of enums are named symbols (much like symbols in
scheme) simply have the property that they are unique and can be
compared for equality and assigned.  They have no inherent ordering. All
range checks would be performed statically by the compiler.

Supported operations:   :=, =, #

(2) We could, at the cost of a little more complexity preserve the
ordering of enums allowing for operations like <, >, <= and >=.

Supported operations:    :=, =, #, <, >, <=, >=

(3) This could be made somewhat more powerful by taking advantage of
this ordering to to provide support for INC and DEC operations. When
operating on enums, these inlined procedures would have to perform range
checks.

Supported operations:    :=, =, #, <, >, <=, >=, INC, DEC

(4) We could then add ORD and ENUM(enum-type, ord-value) to convert
between enums and equivalent integers.  In this case  range checking
would have to be performed by the ENUM function procedure.

Supported operations:    :=, =, #, <, >, <=, >=, INC, DEC, ORD, ENUM

(5) Only when we start allowing enums to be used explicitly as
subranges, array indexes and loop counters do things really become
hairy.  The usefulness of enums as type-safe constants can be had
without this complexity.

I've been reading through Wirth's Oberon-0 compiler from "Compiler
Construction" with 5 different colored highliters to take the thing
appart and understand exactly what's going on. (such is WCS)

In this compiler, he makes use of a bunch of constants for the terminal
symbols returned by the scanner.  They are defined as integer constants
with explicit values. (As Oberon has no enums).

He uses "=" tests on them often, for example to check if the user has
remembered to type "THEN" in an if-then statement.  He also uses >= <=,
< and > tests to check if values of sym lies above, below or between
certain values.  This implies that some (undocumented) information is
encoded in the ordering of the values assigned to these constants.

In order to do this with enums, we'd have to have enums at least as
powerful as type 2.  There is a way we could do it with type 1 enums,
but it would ask the ability to type set-literals of enums:

For (greatly simiplified) example:

Given the following tokens:

    TYPE
        token = (num, plus, minus, mult, div, rparen, lparen);
    VAR
        sym: token;

Using type (2) enums we might write:

    IF (sym >= plus) & (sym <= div) THEN
        (* it's an operator... *)

Using type (1) enums with set-literals, we could write:

    IF sym IN {plus, minus, mult, div} THEN
        (* it's an operator... *)

which seems to me, clearer, since it doesn't require the reader to
constantly refer back to the list of enums in the type declaration (way
at the other end of the module) just to understand what's going on.

Alternatively, one could give such a set a suggestive name:

    CONST
        operators = {plus, minus, mult, div};

    IF sym IN operators THEN ....

For such a set, defined as a constant, the compiler could, naturally
coose to generate code using <= and >= as an optimization.  Efficiency
need not be lost because of this notation.

--



Fri, 20 Jul 2001 03:00:00 GMT  
 enumerations
I can state as a compiler vendor for Modula-2 that enumeration types add no
real "complexity" to the compiler. They are simple ordinal types. Given how
our compiler is laid out the fact that a type is an enumeration or a
CARDINAL makes no difference as the parse simply accepts either one without
the need to check if it is an enumeration or a CARDINAL or an INTEGER. Array
subscripts, INC, DEC are such situations. Enumeration are just ordinal
types, of a defined range and are compatible only with themselves. For
example you cannot make one CARDINAL type incompatible with another CARDINAL
type and CARDINAL is an ordinal type. Where CARDINAL take constants of 1, 2,
3 etc., enumeration's has constants of user defined symbolic names. This
does add a small amount of code to the compiler, but this cannot be
considered "complexity". This is an except from our parser where it shows
exactly how much code it take to differentiate an enum literal from other
literals

    TkEnumId:
        CurrentExpr := ConstantNode(IdSymbol^.enumVal, IdSymbol^.typ);
        NextToken;
    |
    TkNumber:
        CurrentExpr := ConstantNode(NumberVal, ConstantType);
        NextToken;
    |
    TkRealNumber:
         CurrentExpr := RealNode(RealVal);
         NextToken;
    |
    TkStringLiteral:

--
Norman Black, Pcn
Stony Brook Software
To reply via email replace fubar with ix.netcom in my address.

Quote:

>Hello Y'all greetings from the Oberon world. We've been having a
>disucssion over there on enumerated types (which are absent from
>Oberon.)  Since modula-2 has them, I thought it would be interested to
>hear your take on them. The debate seems to be tugging back and forth
>between compiler complexity and user convenience.

>----

>Having enums does not necessarily imply having subranges and the
>associated compiler complexity. It depends on how powerful one makes the
>enums. i.e. what operations they support.  Consider the following
>hierarchy:

>(1) The simplest form of enums are named symbols (much like symbols in
>scheme) simply have the property that they are unique and can be
>compared for equality and assigned.  They have no inherent ordering. All
>range checks would be performed statically by the compiler.

>Supported operations:   :=, =, #

>(2) We could, at the cost of a little more complexity preserve the
>ordering of enums allowing for operations like <, >, <= and >=.

>Supported operations:    :=, =, #, <, >, <=, >=

>(3) This could be made somewhat more powerful by taking advantage of
>this ordering to to provide support for INC and DEC operations. When
>operating on enums, these inlined procedures would have to perform range
>checks.

>Supported operations:    :=, =, #, <, >, <=, >=, INC, DEC

>(4) We could then add ORD and ENUM(enum-type, ord-value) to convert
>between enums and equivalent integers.  In this case  range checking
>would have to be performed by the ENUM function procedure.

>Supported operations:    :=, =, #, <, >, <=, >=, INC, DEC, ORD, ENUM

>(5) Only when we start allowing enums to be used explicitly as
>subranges, array indexes and loop counters do things really become
>hairy.  The usefulness of enums as type-safe constants can be had
>without this complexity.

>I've been reading through Wirth's Oberon-0 compiler from "Compiler
>Construction" with 5 different colored highliters to take the thing
>appart and understand exactly what's going on. (such is WCS)

>In this compiler, he makes use of a bunch of constants for the terminal
>symbols returned by the scanner.  They are defined as integer constants
>with explicit values. (As Oberon has no enums).

>He uses "=" tests on them often, for example to check if the user has
>remembered to type "THEN" in an if-then statement.  He also uses >= <=,
>< and > tests to check if values of sym lies above, below or between
>certain values.  This implies that some (undocumented) information is
>encoded in the ordering of the values assigned to these constants.

>In order to do this with enums, we'd have to have enums at least as
>powerful as type 2.  There is a way we could do it with type 1 enums,
>but it would ask the ability to type set-literals of enums:

>For (greatly simiplified) example:

>Given the following tokens:

>    TYPE
>        token = (num, plus, minus, mult, div, rparen, lparen);
>    VAR
>        sym: token;

>Using type (2) enums we might write:

>    IF (sym >= plus) & (sym <= div) THEN
>        (* it's an operator... *)

>Using type (1) enums with set-literals, we could write:

>    IF sym IN {plus, minus, mult, div} THEN
>        (* it's an operator... *)

>which seems to me, clearer, since it doesn't require the reader to
>constantly refer back to the list of enums in the type declaration (way
>at the other end of the module) just to understand what's going on.

>Alternatively, one could give such a set a suggestive name:

>    CONST
>        operators = {plus, minus, mult, div};

>    IF sym IN operators THEN ....

>For such a set, defined as a constant, the compiler could, naturally
>coose to generate code using <= and >= as an optimization.  Efficiency
>need not be lost because of this notation.

>--




Fri, 20 Jul 2001 03:00:00 GMT  
 enumerations
On Mon, 01 Feb 1999 08:42:41 +0100, "B. Smith-Mannschott"

Quote:

>Hello Y'all greetings from the Oberon world. We've been having a
>disucssion over there on enumerated types (which are absent from
>Oberon.)  Since modula-2 has them, I thought it would be interested to
>hear your take on them. The debate seems to be tugging back and forth
>between compiler complexity and user convenience.

>----

Hmmm, if I may react as a Modula-2 user, definitely NOT a compiler
writer?

I use M2 mainly for a Javanese dictionary project (Javanese is an
Indonesian language with some 70 million native speakers, i.e it has
twice as many NATIVE speakers as Bahasa Indonesia, whic is the
official language of Indonesia.)

My morphological parser has to read a text and to find the
morphological stucture of each word, e.g.

  dibaleni from bali with prefix di- and suffix -ni and vowel change
(/i/ to /e/).

Javanese has over one hundred affixes (prefixes, infixes, suffixes and
'morphological processes' like sandhi).

The program is greatly simplified by creating an enumeration type
called AFFIX, which enumerates all these affixes.
A word then can be defined as a combination of a root word with a
given set of affixes (not every combination is possible of course).

If I need to, I can define subsets lieke PREFIX, SUFFIX etc.
The existence of enumeration types may make the comiler a little bit
more complex (but certainly not very??) but the programmer's task a
lot simpler.

The lack of enumeration types is for me the reason why I never
considered changing to Oberon.

Regards,

Rob van Albada



Fri, 20 Jul 2001 03:00:00 GMT  
 enumerations

Quote:

> Hello Y'all greetings from the Oberon world. We've been having a
> disucssion over there on enumerated types (which are absent from
> Oberon.)  Since modula-2 has them, I thought it would be interested to
> hear your take on them. The debate seems to be tugging back and forth
> between compiler complexity and user convenience.

 If that is the only issue, then user convienence ( and bug reduction )
should win hands down, surely ?

 The lack of Enum, and the 'shrink' of TYPES, were the reasons we never
gave Oberon more than a quick look.

<snip good enum examples >

Enums are also great for
- Fuzzy Logic implementations
- State engine decoders, like Sampled Quadrature counters.
- Typo protections, and default error instances.
  eg we usually CLEAR the Data RAM to 00H ( Takes 6 byte loop in C51 )
  and also make the First Enum, a default or Error value, depending on
  the code.

--
======= Manufacturers of Serious Design Tools for uC and PLD  =====
= Structured Text ( MOd51, IEC1131 ) Compilers for the 80x51
microcontrollers



Sat, 21 Jul 2001 03:00:00 GMT  
 
 [ 4 post ] 

 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

9. Enumerations - slow down a minute!

10. Enumerations in Eiffel

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

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

 

 
Powered by phpBB® Forum Software