|Enumerated data types firstname.lastname@example.org (1990-08-23)|
|Re: Enumerated data types email@example.com (1990-08-24)|
|Re: Enumerated data types firstname.lastname@example.org (1990-08-15)|
|Re: Enumerated data types email@example.com (1990-08-24)|
|Re: Enumerated data types firstname.lastname@example.org.OZ.AU (1990-08-27)|
|Re: Enumerated data types email@example.com (1990-08-27)|
|Re: Enumerated data types firstname.lastname@example.org (1990-08-24)|
|Re: Enumerated data types email@example.com (1990-08-27)|
|Re: Enumerated data types grover@brahmand.Eng.Sun.COM (1990-08-28)|
|[4 later articles]|
|From:||firstname.lastname@example.org (Rich Skrenta)|
|Date:||Fri, 24 Aug 1990 16:21 EDT|
> car_colours = (red, blue, brown, black);
> bike_colours = (orange, red, green, white);
> suc (car_colour, red) = blue
> suc (bike_colour, red) = green
> Are there problems with this definition of enumerated data types?
> Could be there difficulties trying to specify the semantics of suc,
> pred and ord?, Any suggestion?
The problems aren't with suc() and pred(), but rather with determining
the type of "red" when the parser sees it in the source. Consider:
procedure foo (b: bike_colour)
In order to determine which type "red" is, we need to consult the definition
of "foo". Does Pascal do this for integer/real constants anyway?
procedure bar (r: real)
bar (12); /* sent in an integer */
Would the 12 be coerced to type real, or will a Pascal compiler flag this
as an error? If it does the coercion, I don't see a problem with overloading
enumerated type names.
If there was a problem, you could always lexically distinguish enumerated
type names. Although it takes some getting used to, you could write
instead of just "blue".
Return to the
Search the comp.compilers archives again.