Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!usc!apple!snorkelwacker!spdcc!ima!esegue!compilers-sender
From: skrenta@amix.commodore.com (Rich Skrenta)
Newsgroups: comp.compilers
Subject: Re: Enumerated data types
Keywords: types, design
Message-ID: <651529289.AA2305@amix.commodore.com>
Date: 24 Aug 90 20:21:00 GMT
References: <1990Aug23.134826.2865@forwiss.uni-passau.de>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: skrenta@amix.commodore.com (Rich Skrenta)
Organization: Compilers Central
Lines: 40
Approved: compilers@esegue.segue.boston.ma.us

>	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)

	foo(red);

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

	bike_color(blue)

instead of just "blue".

Rich
--
skrenta@blekko.commodore.com
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{ima | spdcc | world}!esegue.  Meta-mail to compilers-request@esegue.