|Re: Enumerated data types. world.std.com!inmos.com!mph (Mike Harrison) (1990-08-31)|
|From:||Mike Harrison <world.std.com!inmos.com!mph>|
|Date:||Fri, 31 Aug 90 14:12:00 BST|
dik t. winter (email@example.com) wrote:
>In article <1990Aug23.firstname.lastname@example.org> email@example.com (Luis Mandel) writes:
>> Now my question is: anybody knows if there are languages that allows
>> anything like
>> car_colours = (red, blue, brown, black);
>> bike_colours = (orange, red, green, white);
>> and have these functions defined with an extra parameter, for example:
>> suc (car_colour, red) = blue
>> suc (bike_colour, red) = green
>No extra parameter is required in Ada. The reason is that overload
>resolution (the two functions suc overload each other) is not only done
>on the type of parameter but also on the required type of the result.
> ford_colour := suc(red)
>it is known that ford_colour is of type car_colour and so it is known
>that suc is the function on type car_colour.
This is not true, because 'suc' is neither a function nor an operator in Ada,
it is an attribute.
Thus (translating Luis Mandel's example into Ada) we have:
type CAR_COLOURS is (RED, BLUE, BROWN, BLACK);
type BIKE_COLOURS is (ORANGE, RED, GREEN, WHITE);
CAR_COLOURS'SUCC(RED) = BLUE
BIKE_COLOURS'SUCC(RED) = GREEN
This shows that the SUCC attribute (whose value is a function) must be
qualified by the type (or subtype) of value to which it is to be applied.
Dik's other comments about the resolution of expressions containing
enumeration values are quite correct.
Michael P. Harrison - Software Group - Inmos Ltd. UK.
UK : firstname.lastname@example.org, US : email@example.com
Return to the
Search the comp.compilers archives again.