abcscagz@csuna.csun.edu (Jeff Boeing) (06/01/89)
I couldn't find this anywhere in Wirth's book (4th edition), so here goes:
How do you convert from a cardinal or integer type to an enumerated type?
I would like very much to keep a particular enumerated type in a program I'm
writing, but this program requires that some data of that type be written to
and read from a file. If x is of my enumerated type, it's easy enough to save
it to a file by saying "WriteInt (ORD(x))" (after redirecting output, of
course), but how do I read that value back in?
Enquiring minds want to know!
--
Jeff Boeing: ...!csun.edu!csuna!abcscagz (formerly tracer@stb.UUCP)
----------------------------------------------------------------------------
"Let's split up -- we can do more damage that way."
-- Gh0stbustersfransvo@maestro.htsa.aha.nl (Frans van Otten) (06/01/89)
Jeff Boeing writes: >I couldn't find this anywhere in Wirth's book (4th edition), so here goes: > >How do you convert from a cardinal or integer type to an enumerated type? >I would like very much to keep a particular enumerated type in a program I'm >writing, but this program requires that some data of that type be written to >and read from a file. If x is of my enumerated type, it's easy enough to save >it to a file by saying "WriteInt (ORD(x))" (after redirecting output, of >course), but how do I read that value back in? I don't know about the 4th edition, but in the 3rd edition such a procedure is described. In paragraph 10.2, "Standard procedures", on page 162: VAL(T, x) The value with ordinal number x and with type T. T is any enumeration type, or CHAR, INTEGER, or CARDINAL. VAL(T, ORD(x)) = x, if x is of type T. ( Does anybody know why I never see anything about LONGINT or LONGREAL, except in the paragraph about basic types ? ) -- Frans van Otten | fransvo@maestro.htsa.aha.nl or Algemene Hogeschool Amsterdam | fransvo@htsa.uucp or Technische en Maritieme Faculteit | [[...!]backbone!]htsa!fransvo
soper@xenna.UUCP (Pete Soper,,,) (06/01/89)
From article <2027@csuna.csun.edu>, by abcscagz@csuna.csun.edu (Jeff Boeing): > and read from a file. If x is of my enumerated type, it's easy enough to save > it to a file by saying "WriteInt (ORD(x))" (after redirecting output, of > course), but how do I read that value back in? Read the ordinal and use it as an index to an array whose elements contain the corresponding enumeration values. It is tiresome but portable since you are the one doing the mapping. ---------------------------------------------------------------------- Pete Soper +1 919 481 3730 arpa: soper@encore.com uucp: {bu-cs,decvax,necntc}!encore!soper Encore Computer Corp, 901 Kildaire Farm Rd, bldg D, Cary, NC 27511 USA
djsalomon@watdragon.waterloo.edu (Daniel J. Salomon) (06/02/89)
In article <2027@csuna.csun.edu> abcscagz@csuna.csun.edu (Jeff Boeing) writes: > >I couldn't find this anywhere in Wirth's book (4th edition), so here goes: > >How do you convert from a cardinal or integer type to an enumerated type? > ... If x is of my enumerated type, it's easy enough to save >it to a file by saying "WriteInt (ORD(x))" (after redirecting output, of >course), but how do I read that value back in? > Use the standard procedure VAL. E.g. ReadInt (i); enumvar := VAL (enumtype, i); See section 10.2 of "Programming in Modula-2" by Niklaus Wirth. A better book (clearer and a lot shorter) is "Modula-2 for Pascal Programmers" by Richard Gleaves, section 11.6. This book has a usable index, not like Wirth's book.
soper@xenna.UUCP (Pete Soper,,,) (06/02/89)
From article <14226@watdragon.waterloo.edu>, by djsalomon@watdragon.waterloo.edu (Daniel J. Salomon): > > Use the standard procedure VAL. E.g. Which standard? Many implementations do not have VAL as it came along with the 3rd edition of the Wirth book and the single pass compiler. Also, I suggest Wiener and Ford as an alternative to the Wirth book. ---------------------------------------------------------------------- Pete Soper +1 919 481 3730 arpa: soper@encore.com uucp: {bu-cs,decvax,necntc}!encore!soper Encore Computer Corp, 901 Kildaire Farm Rd, bldg D, Cary, NC 27511 USA
hal@pur-phy (Hal Chambers) (06/02/89)
>> Use the standard procedure VAL. E.g. In article <7465@xenna.Encore.COM> soper@xenna.UUCP (Pete Soper,,,) writes: > Which standard? Many implementations do not have VAL as it came along with >the 3rd edition of the Wirth book and the single pass compiler. VAL is in the 1982 (1st?) Edition; page 158 of the Report. -- Hal Chambers hal@newton.physics.purdue.edu hal@physics-newton.arpa
soper@xenna.UUCP (Pete Soper,,,) (06/03/89)
From article <2295@pur-phy>, by hal@pur-phy (Hal Chambers): >>> Use the standard procedure VAL. E.g. > > In article <7465@xenna.Encore.COM> soper@xenna.UUCP (Pete Soper,,,) writes: >> Which standard? Many implementations do not have VAL as it came along with >>the 3rd edition of the Wirth book and the single pass compiler. > > VAL is in the 1982 (1st?) Edition; page 158 of the Report. It's on that page in the 2nd edition (1982) and I stand corrected and apologize for my bad information. The various editions of the Wirth book have such good indexes and tables of contents, with such coherent organization that I don't know how I missed this. I still would not depend on VAL for an instant however. If someone who has the 1st edition could look this up it would be useful (to complete my embarrassment if nothing else). ---------------------------------------------------------------------- Pete Soper +1 919 481 3730 arpa: soper@encore.com uucp: {bu-cs,decvax,necntc}!encore!soper Encore Computer Corp, 901 Kildaire Farm Rd, bldg D, Cary, NC 27511 USA
randy@m2xenix.UUCP (Randy Bush) (06/04/89)
In article <7465@xenna.Encore.COM> soper@xenna.UUCP (Pete Soper,,,) writes: > Which standard? Many implementations do not have VAL as it came along with > the 3rd edition of the Wirth book and the single pass compiler. VAL is in the yellow book circa 1980 (bottom of p22), PIM-1 (p158), PIM-2 (p158), PIM-3 (p162), and PIM-4 (p150). In some versions of the single pass, type transfer was moved to SYSTEM and called SYSTEM.VAL. > Also, I suggest Wiener and Ford as an alternative to the Wirth book. Try K King or P Terry. They are far superior and much later. King is a good reference, Terry a good tutorial. -- { mcvax!uunet!oresoft, tektronix!percival!qiclab } !m2xenix!randy Randy Bush
randy@m2xenix.UUCP (Randy Bush) (06/09/89)
In article <7515@xenna.Encore.COM> soper@xenna.UUCP (Pete Soper,,,) writes: > If someone who has the 1st edition could look this up it would be useful Pete, I think I bludgeoned this to death in a previously posting. My apologies, but having had to fight long and hard for the retention of VAL, I get a tad defensive on the issue. Apologies. It may cheer you to learn that the ISO draft describes a VAL that should be able to be safely used for all reasonable conversions. Type transfers (aka casts) are now SYSTEM.CAST, but the old form TypeName(object) is considered 'deprecated'. -- { mcvax!uunet!oresoft, tektronix!percival!qiclab } !m2xenix!randy Randy Bush
alan@oz.nm.paradyne.com (Alan Lovejoy) (06/14/89)
In article <7465@xenna.Encore.COM> soper@xenna.UUCP (Pete Soper,,,) writes: >From article <14226@watdragon.waterloo.edu>, > by djsalomon@watdragon.waterloo.edu (Daniel J. Salomon): >> >> Use the standard procedure VAL. E.g. > > Which standard? Many implementations do not have VAL as it came along with >the 3rd edition of the Wirth book and the single pass compiler. Also, I >suggest Wiener and Ford as an alternative to the Wirth book. VAL has always been in the language. Where did you get the idea that it first appeared in PIM2v3? The problem with both VAL and "type transfer functions" (e.g., TYPENAME(x)) is that many compiler writers seem unable or unwilling to implement them correctly. VAL is supposed to perform MEANING-PRESERVING conversions that may require changing the number and/or value of bits. Type-transfer functions are supposed to perfrom BIT-PATTERN-PRESERVING conversions which may change the meaning of a value (e.g., CARDINAL(-1)). But many implementations do not conform to this specification. And PIM2v3 never clearly stated the compatibility rules of the LONG types, so of course every implementation adopts its own policy as it sees fit (if it even HAS long types). The other favorite misinterpretation of the definition of the language is the nutty idea that providing set types which can contain more elements than the number of bits in a WORD is "nonstandard." It is NOT!!!! PIM2 says only that implementations are not REQUIRED to support set types which can contain more elements than the number of bits in a WORD. But they are NOT FORBIDDEN from doing so. Any implementation that does not support SET OF CHAR is useless for most purposes. SETs are almost never used for anything except SET OF CHAR. One of the best things about the coming ISO standard for Modula-2 is that it promises to fix this intolerable situation. Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL. Disclaimer: I do not speak for AT&T Paradyne. They do not speak for me. ______________________________Down with Li Peng!________________________________ Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.
drc@claris.com (Dennis Cohen) (06/15/89)
In article <6187@pdn.paradyne.com> alan@oz.paradyne.com (Alan Lovejoy) writes: ... <other topics not germane to this followup> > >The other favorite misinterpretation of the definition of the language is >the nutty idea that providing set types which can contain more elements >than the number of bits in a WORD is "nonstandard." It is NOT!!!! PIM2 >says only that implementations are not REQUIRED to support set types which >can contain more elements than the number of bits in a WORD. But they are NOT >FORBIDDEN from doing so. Any implementation that does not support SET OF CHAR >is useless for most purposes. SETs are almost never used for anything except >SET OF CHAR. > ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This last sentence is the one with which I wish to differ. I used to think this way when the only systems I programmed were character-oriented; however, programming systems like the Mac has changed that perception. I almost never use SETs for anything other than WORD and LONGWORD operations anymore, the exception being an occasional foray into something like a keyboard mapping. Just because most pedagogical exercises involving SET-oriented operations revolve around SET OF CHAR doesn't mean that the practical application of SETs is going to do so. -- Dennis Cohen Claris Corp. ------------ Disclaimer: Any opinions expressed above are _MINE_!
fransvo@maestro.htsa.aha.nl (Frans van Otten) (06/16/89)
Alan Lovejoy writes:
=The other favorite misinterpretation of the definition of the language is
=the nutty idea that providing set types which can contain more elements
=than the number of bits in a WORD is "nonstandard." It is NOT!!!! PIM2
=says only that implementations are not REQUIRED to support set types which
=can contain more elements than the number of bits in a WORD. But they are NOT
=FORBIDDEN from doing so. Any implementation that does not support SET OF CHAR
=is useless for most purposes. SETs are almost never used for anything except
=SET OF CHAR.
Niklaus Wirth writes (in pim3, the report, chapter 6.6):
=6.6. Set types
=
=A set type defined as SET OF T comprises all sets of values of its
=base type T. This must be a subrange of the integers between 0 and
=N-1, or a (subrange of an) enumeration type with at most N values,
=where N is a small constant determined by the implementation, usually
=the computer's wordsize or a small multiple thereof.
=
=$ SetType = SET OF type
=
=The standard type BITSET is defined as follows, where W is a constant
=defined by the implementation, usually the wordsize of the computer.
=
= BITSET = SET OF [0 .. W-1]
____________________________Down with Li Peng!______________________________
--
Frans van Otten | fransvo@maestro.htsa.aha.nl or
Algemene Hogeschool Amsterdam | fransvo@htsa.uucp or
Technische en Maritieme Faculteit | [[...!]backbone!]htsa!fransvorandy@m2xenix.UUCP (Randy Bush) (06/20/89)
You and others may be pleased to know that the emerging draft standard
specifies that a SET should minimaly be able to handle SET OF CHAR. Now,
what this means when CHAR is drawn from a large character set is fun as
well.
--
{ mcvax!uunet!oresoft, tektronix!percival!qiclab } !m2xenix!randy Randy Bushalan@oz.nm.paradyne.com (Alan Lovejoy) (07/22/89)
In article <985@maestro.htsa.aha.nl< fransvo@htsa.UUCP (Frans van Otten) writes:
<Niklaus Wirth writes (in pim3, the report, chapter 6.6):
<=6.6. Set types
<=
<=A set type defined as SET OF T comprises all sets of values of its
<=base type T. This must be a subrange of the integers between 0 and
<=N-1, or a (subrange of an) enumeration type with at most N values,
<=where N is a small constant determined by the implementation, usually
<=the computer's wordsize or a small multiple thereof.
<=
<=$ SetType = SET OF type
<=
<=The standard type BITSET is defined as follows, where W is a constant
<=defined by the implementation, usually the wordsize of the computer.
<=
<= BITSET = SET OF [0 .. W-1]
Like I said: "N is a small constant DETERMINED BY THE IMPLEMENTATION, usually
the computer's wordsize OR A SMALL MULTIPLE THEREOF." So the fact that a
compiler supports SET OF CHAR does not make it nonstandard, because 256
is a small multiple of 32, namely 8. And also because the maximum size
is ultimately TO BE DETERMINED BY THE IMPLEMENTATION. Compilers which
implement small maximum set sizes do so solely at the whim of the implementors.
They are not forced to do this in order to conform to the standard. And I
am not forced to purchase such compilers--and I will refuse to do so.
Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL.
Disclaimer: I do not speak for AT&T Paradyne. They do not speak for me.
______________________________Down with Li Peng!________________________________
Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.randy@m2xenix.UUCP (Randy Bush) (08/05/89)
In article <6197@pdn.paradyne.com> alan@oz.paradyne.com (Alan Lovejoy) writes: > Compilers which implement small maximum set sizes do so solely at the whim of > the implementors. They are not forced to do this in order to conform to the > standard. ^yet I believe that the WG13 position is that at least SET OF CHAR shall be supported. This includes when ORD(MAX(CHAR)) is largish. -- uunet!tektronix ----\ sun!nosun --------- qiclab ---- m2xenix!randy or randy@m2xenix.uucp uunet!oresoft ------------------/