dts@pyr.gatech.EDU (Danny Sharpe) (02/18/88)
I'm trying to find out if any version of Pascal running on any machine
supports I/O on enumerated data types. Example:
type dayofweek = (monday, tuesday, wednesday, ... sunday);
var day : dayofweek;
.
.
.
read(day);
I think I've heard of versions of Pascal that allow I/O on enumerated
types, but I can't for the life of me remember any specifics.
Do you know of any versions of Pascal that can do this?
If so,
Do you remember the name of the company/people who wrote the compiler?
What are the capabilities/limitations of the implementation?
Please E-Mail me if you have any information on this.
Thanks.
-Danny
----------
"Have you hugged your parents today?"
Danny Sharpe, Ga Tech Box 34832, Atlanta, GA, 30332
Internet: dts@pyr.gatech.edu
uucp: ...!{decvax,hplabs,ihnp4,linus,rutgers,seismo}!gatech!gitpyr!dtsjipping@frodo.cs.hope.EDU (Mike Jipping) (02/19/88)
> I'm trying to find out if any version of Pascal running on any machine > supports I/O on enumerated data types. Example: > ... > I think I've heard of versions of Pascal that allow I/O on enumerated > types, but I can't for the life of me remember any specifics. It seems to me that doing I/O on enumerated types goes against the grain of the concept. If you take a strict view of data typing, what does a compiler expect from input or print to output? Certainly not a sequence of characters -- for that would be a string (i.e., array of char), NOT an enumerated type. And certainly not a number (perhaps indicating the ordinal value...) for the same typing reasons. Perhaps this is why it isn't implemented. And why enum I/O is not defined in the Pascal standards. Maybe what is necessary is a "string-to-enum-type" function, taking a string and jumping on it to (somehow) give the enum type. However, allowing this type conversion string -> enum will most likely have to access the implementation of a specific type representation for a specific compiler. At best, not a portable solution... > Danny Sharpe, Ga Tech Box 34832, Atlanta, GA, 30332 > Internet: dts@pyr.gatech.edu > uucp: ...!{decvax,hplabs,ihnp4,linus,rutgers,seismo}!gatech!gitpyr!dts Mike Jipping Dept. of Computer Science Hope College jipping@cs.hope.edu
ok@quintus.UUCP (Richard A. O'Keefe) (02/20/88)
Danny Sharpe wrote: > > I'm trying to find out if any version of Pascal running on any machine > > supports I/O on enumerated data types. Example: > > ... > > I think I've heard of versions of Pascal that allow I/O on enumerated > > types, but I can't for the life of me remember any specifics. If you mean something like type foo = (......); var baz : file of foo; I believe it is required by the standard. "pc" on a SUN supports it. If you mean type foo = (.....); var ugh : foo; begin writeln(ugh); end this is not part of the standard, but there are several compilers that support it. The B6700 Pascal compiler from Arthur Sale's group at the University of Tasmania is such a compiler. If it comes to that, so is the SUN Pascal compiler. Here is a program: program main(input, output); type foo = (here, there, back, again); var ugh : foo; begin for ugh := here to again do writeln(ugh); end {main}. Here is its output: here there back again You can also read values of enumerated types from text files. In article <11903@brl-adm.ARPA>, jipping@frodo.cs.hope.EDU (Mike Jipping) writes: > It seems to me that doing I/O on enumerated types goes against the grain > of the concept. If you take a strict view of data typing, what does a > compiler expect from input or print to output? Certainly not a sequence of > characters -- for that would be a string (i.e., array of char), NOT an > enumerated type. And certainly not a number (perhaps indicating the ordinal > value...) for the same typing reasons. But a text file is precisely a sequence of characters (with some additional structure). And Pascal *does* provide text I/O on *one* enumerated type. It's absurd that text I/O IS allowed for Boolean, but not for other enums. > At best, not a portable solution... If text I/O of enumerated types had been part of the standard, it *would* have been portable. And it's such a simple feature to implement, too. What a pity.
drc@dbase.UUCP (Dennis Cohen) (02/21/88)
> I'm trying to find out if any version of Pascal running on any machine > supports I/O on enumerated data types. Example: > ... > I think I've heard of versions of Pascal that allow I/O on enumerated > types, but I can't for the life of me remember any specifics. > > Danny Sharpe, Ga Tech Box 34832, Atlanta, GA, 30332 The only one I've used that supports that is the University of Wisconsin Pascal compiler which runs on Univac 1100 series mainframes. It's a very nice implementation of the language with extensions for externals (unusual in a mainframe implementation) and a Modula-2 like set of extensions for libraries. The principal author at UW was Charles Fischer(sp?). By the way, it also has extensions for strings and other useful things. Dennis Cohen Ashton-Tate Macintosh Division dBASE Mac Development Team
abcscnuk@csuna.UUCP (Naoto Kimura) (02/22/88)
In article <673@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >.. >In article <11903@brl-adm.ARPA>, jipping@frodo.cs.hope.EDU (Mike Jipping) writes: >> It seems to me that doing I/O on enumerated types goes against the grain >> of the concept. If you take a strict view of data typing, what does a >> compiler expect from input or print to output? Certainly not a sequence of >> characters -- for that would be a string (i.e., array of char), NOT an >> enumerated type. And certainly not a number (perhaps indicating the ordinal >> value...) for the same typing reasons. > >But a text file is precisely a sequence of characters (with some additional >structure). And Pascal *does* provide text I/O on *one* enumerated type. >It's absurd that text I/O IS allowed for Boolean, but not for other enums. Pascal allows only output, not input of booleans. What would you suggest for input of boolean variables ? Are you going to have the compiler generated code to require 'TRUE' for TRUE on text input, or are you going to allow abbreviations of 'TRUE' like 'TR' ? Booleans can be written out as text, and truncated by using a field width, so why should you not be allowed using 'T' for 'TRUE' and 'F' for 'FALSE' ? Is the input going to be case-sensitive ? Some compilers are case-sensitive, while others are not. Is case-sensitivity going to be based on whether or not the compiler is case-sensitive ? That would mean that the behavior of a program will depend upon the compiler. Strings can be truncated on output to a text file too, but they have to be read in one character at a time from a text file. > >> At best, not a portable solution... >If text I/O of enumerated types had been part of the standard, >it *would* have been portable. And it's such a simple feature to >implement, too. What a pity. Ok, then go and implement a compiler that will allow input of enumerated types. Output I can see how it could be done, but input is another story. The compiler would have to have something like yacc or lex built into it. As someone has already stated, I/O of enumerated types is contradictory to the policy of strong typing. Output of boolean values was probably allowed because they are used quite often. And anyway, I wouldn't go classifying booleans as an enumerated type, as they behave differently. //-n-\\ Naoto Kimura _____---=======---_____ (csun!csuna!abcscnuk) ====____\ /.. ..\ /____==== // ---\__O__/--- \\ Enterprise... Surrender or we'll \_\ /_/ send back your *&^$% tribbles !!
ok@quintus.UUCP (Richard A. O'Keefe) (02/22/88)
In article <1077@csuna.UUCP>, abcscnuk@csuna.UUCP (Naoto Kimura) writes: > In article <673@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: > As someone has already stated, I/O of enumerated types is contradictory to > the policy of strong typing. Output of boolean values was probably allowed > because they are used quite often. And anyway, I wouldn't go classifying > booleans as an enumerated type, as they behave differently. (1) Booleans in Pascal are exactly the same as any other enumerated type, except for having some built-in operators. In fact, Boolean isn't a reserved word, it's just a type declared in the block surrounding the program. (2) I/O of enumerated types is contrary to the policy of strong typing? Sorry, I just can't see that. Forcing the programmer to work in terms of Ord() values, now *that* is contrary to the policy of string typing. I guess the designers of ADA agree with me and the original poster, because ADA provides a built-in package ENUMERATION_IO.
firth@sei.cmu.edu (Robert Firth) (02/22/88)
In article <1077@csuna.UUCP> abcscnuk@csuna.UUCP (Naoto Kimura) writes: >Ok, then go and implement a compiler that will allow input of enumerated types. >Output I can see how it could be done, but input is another story. The >compiler would have to have something like yacc or lex built into it. The Ada language requires both input and output of enumerated types. It is not really that hard. Consider type Day = (Sunday, Monday, Tuesday, ...); You build a string table in the order of the type values; simply index this table by the binary ordinal to get the display form. For input, you can use the same table if the number of values is small, searching it linearly; otherwise, build a true lookup table with the text values in alphabetical order, and search by binary chop. Or you can get really fancy, and use a hash table. It so happens I wrote this part of an Ada runtime support package, and it was less than a page of code for both translation procedures. To answer the usual silly questions (a) the language is not case sensitive, so you force to uniform case on both input and output. (b) otherwise, you emit, and recognise, exactly the names declared by the user, and no others (c) all such input can be read by a simple LR(1) scanner based on an FSM; the apparatus of 'lex' and 'yacc' (even supposing one would ever want to use them for anything) is not needed. (d) you read according to the lexis of an 'identifier'; you're required to skip leading white space, and of course you need a one-char lookahead or putback. (e) the error behaviour in Ada is to raise DATA_ERROR if there isn't an identifier to be read, or if the identifier read isn't a value of the type.
gareth@comp.lancs.ac.uk (Gareth Husk) (02/23/88)
>> I'm trying to find out if any version of Pascal running on any machine >> supports I/O on enumerated data types. Example: >> ... >> I think I've heard of versions of Pascal that allow I/O on enumerated >> types, but I can't for the life of me remember any specifics. >At best, not a portable solution... >> Danny Sharpe, Ga Tech Box 34832, Atlanta, GA, 30332 Certainly the Berkeley pc compiler allows the output of enumerated values as strings directly. However I have not been able to convince it to accept enumerated values without a conversion routine ie read string compare and assign an enumerated value. However the pc compiler allows all sorts of strange little things to happen, it doesn't do proper bounds checking and only produes an error if you try to assign a value to memory space assigned to a different base type. Thus arr1 : array[1..10]; ch : char int1 : integer ; ... i := 11 ; arr1[i] := 'x' ; { this works } i := 12 arr[i] := 'y' ; { this fails } Can you imagine the errors this produces when you are reading lots of text and one read goes wrong. -- " I am a doughnut " JFK UUCP: ...!seismo!mcvax!ukc!dcl-cs!gareth DARPA: gareth%lancs.comp@ucl-cs JANET: gareth@uk.ac.lancs.comp
djones@megatest.UUCP (Dave Jones) (02/24/88)
in article <1077@csuna.UUCP>, abcscnuk@csuna.UUCP (Naoto Kimura) says: > > In article <673@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>.. >>In article <11903@brl-adm.ARPA>, jipping@frodo.cs.hope.EDU (Mike Jipping) writes: >>> It seems to me that doing I/O on enumerated types goes against the grain >>> of the concept. [ Stuff about concepts and philosophy omited. ] > > Pascal allows only output, not input of booleans. What would you > suggest for input of boolean variables ? Are you going to have the > compiler generated code to require 'TRUE' for TRUE on text input? [ Lots of strident rhetorical questions omited. ] The Sun compiler "pc", and the Berkeley "pc" and "pi" on which it is based purportedly allow for both reading and writing enumerated types, including boolean. You will get a warning, saying that the feature is non-standard , if you don't use the -w flag. The canonical spelling for reading *true* is "true" and the canonical spelling for reading *false* is "false". But don't expect it really to work. It's buggy. Dave Jones Megatest Corp. 880 Fox Lane San Jose, CA. 95131 (408) 437-9700 Ext 3227 UUCP: ucbvax!sun!megatest!djones ARPA: megatest!djones@riacs.ARPA NO ROT
djones@megatest.UUCP (Dave Jones) (02/24/88)
in article <1077@csuna.UUCP>, abcscnuk@csuna.UUCP (Naoto Kimura) says: > > In article <673@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: > Output I can see how it could be done, but input is another story. The > compiler would have to have something like yacc or lex built into it. > We implemented it here at Megatest without breathing hard. (Actually just debugged the Berkeley implementation.) Instead of yacc and lex we used, TA TA!, getchar(). (It used to be scanf().) > As someone has already stated, I/O of enumerated types is contradictory to > the policy of strong typing. Huh? Yours truly, Dave Jones Megatest Corp. 880 Fox Lane San Jose, CA. 95131 (408) 437-9700 Ext 3227 UUCP: ucbvax!sun!megatest!djones ARPA: megatest!djones@riacs.ARPA NO ROT WHATSOEVER.
Messenger.SBDERX@Xerox.COM (02/25/88)
> [..] The canonical spelling for reading *true* is > "true" and the canonical spelling for reading *false* is "false". What's wrong with T and NIL ? :-) -- Hugh (SETQ ROT NIL)
conway@hplb29a.HPL.HP.COM (Daniel F. Conway) (02/25/88)
Hewlett-Packard's Pascal on their series 9000 model 300 workstations (6800 based) supports I/O of enumerated types. Dan Conway conway@hplabs.hp.com
ok@quintus.UUCP (Richard A. O'Keefe) (02/25/88)
In article <284@goofy.megatest.UUCP>, djones@megatest.UUCP (Dave Jones) writes: : in article <1077@csuna.UUCP>, abcscnuk@csuna.UUCP (Naoto Kimura) says: : > : > In article <673@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: : : > Output I can see how it could be done, but input is another story. The : > compiler would have to have something like yacc or lex built into it. : > : > As someone has already stated, I/O of enumerated types is contradictory to : > the policy of strong typing. : : Huh? Just in case it confused you as much as it confused me, the embedded quotation actually contains no text from me. I am *for* I/O of enumerated data-types, think it is easy to do (I haven't done it for Pascal, but I have done it for another language, and yes, getc()/putc() are all you need; lex is not for serious players), and do not see why anyone would think it went against strong typing. In fact, NOT doing it goes against strong typing.
zifrony@TAURUS.BITNET (02/26/88)
In reply to Danny Sharpe's question about a Pascal which knows to I/O enumerated
types, I would like to mention the HP 200, HP 300 series computers, and their
Pascal v3.0 or later system.
This is an extended Pascal having a lot of nice features, including I/O
of enumerated types. Note that this is the Pascal under the Pascal operating
system, and not the pc compiler under HP/UX of whom I do not know.
Doron Zifrony - zifrony@MATH.Tau.Ac.IL