Enumerations - slow down a minute! 
Author Message
 Enumerations - slow down a minute!

Let's pause for breath a moment in this discussion...

There seem to be two main kinds of extended enumerations
being proposed here.

The simpler one behaves as follows: Given an enumerated
type T and another one T1 which extends T, then:

        T can always be assigned to T1
        T1 can be assigned to T subject to run-time checking

and, if T2 also extends T, then T1 and T2 can never be
assigned to one another.

This would be very simple to implement and would not lead
to any problems with incompatibilities between different
extensions, since a value of type T1 (but not T) can never
be used in a context where a value of type T2 is expected.
So, each extension can just take up numbering where its
base type left off.

The more complicated one allows a value of type T2 to
masquerade as a value of type T. Implementing this seems
to require a system of type tags similar to that for
extensible records, or something equally cumbersome.

I'm still not sure how one would use such a facility.
The case of error codes has been cited as an example.
Let's explore this for a moment.

Suppose we call a procedure and get back an enumerated
type Error. We know about the values declared for this
type in the base module where it is defined, but it
could take any number of other values declared in
unknown modules which have made unknown extensions to
it.

What can we *do* with such a value? If it's a value we
know about, we may be able to take some corrective action
and try again. If not, we presumably want to present some
informative message to the user about what went wrong.
But only the module where the value we have was defined
knows what message is appropriate, and we have no idea
which module that is or how to deal with it.

Seems to me it would be better for Error to be a (pointer
to a) record. Then it can have a field or method which
yields an appropriate error message, and whatever else
is needed that is specific to that kind of error.
Then the existing record extension facilities can be
used.

I suspect that many other applications for extended
enumerations would be served as well as, or even better
by, instances of extended records.

What do others think about this?

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



Tue, 01 Apr 1997 08:30:27 GMT  
 Enumerations - slow down a minute!

Quote:

>Let's pause for breath a moment in this discussion...

>There seem to be two main kinds of extended enumerations
>being proposed here.

>The simpler one behaves as follows: Given an enumerated
>type T and another one T1 which extends T, then:

>    T can always be assigned to T1
>    T1 can be assigned to T subject to run-time checking

>and, if T2 also extends T, then T1 and T2 can never be
>assigned to one another.

>This would be very simple to implement and would not lead
>to any problems with incompatibilities between different
>extensions, since a value of type T1 (but not T) can never
>be used in a context where a value of type T2 is expected.
>So, each extension can just take up numbering where its
>base type left off.

>The more complicated one allows a value of type T2 to
>masquerade as a value of type T. Implementing this seems
>to require a system of type tags similar to that for
>extensible records, or something equally cumbersome.

>I'm still not sure how one would use such a facility.
>The case of error codes has been cited as an example.
>Let's explore this for a moment.

>Suppose we call a procedure and get back an enumerated
>type Error. We know about the values declared for this
>type in the base module where it is defined, but it
>could take any number of other values declared in
>unknown modules which have made unknown extensions to
>it.

>What can we *do* with such a value? If it's a value we
>know about, we may be able to take some corrective action
>and try again. If not, we presumably want to present some
>informative message to the user about what went wrong.
>But only the module where the value we have was defined
>knows what message is appropriate, and we have no idea
>which module that is or how to deal with it.

>Seems to me it would be better for Error to be a (pointer
>to a) record. Then it can have a field or method which
>yields an appropriate error message, and whatever else
>is needed that is specific to that kind of error.
>Then the existing record extension facilities can be
>used.

>I suspect that many other applications for extended
>enumerations would be served as well as, or even better
>by, instances of extended records.

>What do others think about this?

Exactly; finally someone figured out one of the problems.
In essence, adding enumerations as they wish is opening up new
limitations which must be fixed by further extensions.

Taylor Hutt
Windows 95: An operating system or artificial life form?



Wed, 02 Apr 1997 22:26:41 GMT  
 Enumerations - slow down a minute!

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?



Wed, 02 Apr 1997 02:43:00 GMT  
 Enumerations - slow down a minute!

Quote:
> There seem to be two main kinds of extended enumerations
> being proposed here.

> The simpler one behaves as follows: Given an enumerated
> type T and another one T1 which extends T, then:

>    T can always be assigned to T1
>    T1 can be assigned to T subject to run-time checking

> and, if T2 also extends T, then T1 and T2 can never be
> assigned to one another.

Given a choice, let's do as Wirth did, keep with the simpler method
outlined above.

Quote:
> I suspect that many other applications for extended
> enumerations would be served as well as, or even better
> by, instances of extended records.

I gather, on reflection, you've snuck in a third alternative which says
that we don't need _extended_ enumerations after all?  I would rather
take a middle road which keeps the simpler enumeration extension (as
described above) and then whoever extends the original enumeration also
provides overriding methods that work with the extension.  It's a bit
neater than having procedure variables (possibly unassigned) floating
around.  

Mike Griebling



Tue, 01 Apr 1997 19:00:33 GMT  
 Enumerations - slow down a minute!

|>
|> I gather, on reflection, you've snuck in a third alternative which says
|> that we don't need _extended_ enumerations after all?

Essentially, yes. I think we should have at *least* the
old, familiar enumerations that we all know and love.
If someone can find a way of making them extensible in
some sense without things getting too hairy, well and
good. But I can't see the logic in removing them
altogether just because they're not extensible.

|> Mike Griebling

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



Fri, 04 Apr 1997 08:17:31 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Can you slow the scan rate of VI Logger scans per minute

2. vw2.5 sometimes slows down when large

3. MTIMER slows PB down

4. global floating windows slow down graphics?

5. Slow down utility ???

6. Super security slows down

7. Topspeed DB - Record Filter slow down ?!?

8. Slowing down/freezing until user interrupt & proceed

9. Bizzare slowing down in forms ...

10. Report process slow down when...

11. program slows down

12. Citrix time() slow down.

 

 
Powered by phpBB® Forum Software