Frank D. Engel wrote (by private mail, but from the content I suppose it was meant for the list; excuse me if I'm wrong):
How about addition, since in 'subclassing' we would be adding fields:
TYPE base = NIL + RECORD i : INTEGER; j : INTEGER END;
child = base + RECORD x : REAL; y : REAL END; otherchild = base + NIL; hotdog = NIL + (x : INTEGER; y : REAL); cheesedog = hotdog + (t, q : CHAR);Or something similar (prob. the first three preferred; the latter two are a wild shortcut idea).
At first sight, it's certainly a little strange ...
BTW, apart from the syntax, the topic reminds me of another thing. For some time, I've had the idea of extensible enum types (unlike with records, there's currently no alternative in GPC, except using integer constants, of course). Even if you have no "forks", that would be useful across modules (where you can't always declare the largest type first, and the other ones as subranges).
The situation would be a little different from records -- you could assign a value of a small type to a larger one, not vice versa. You wouldn't need `is' and `as', simple comparisons and assignments will do.
I don't know if any dialect has something like this. If not, and we'd make up something new, maybe we could use a common (or similar) syntax with extensible records ...
Frank
Yes, this was meant for the list; I have had another message come to me as well that was intended for the list, but got sent to only the one person who wrote the original msg.
It seems that 'REPLY' does not work for this list?
--- Frank Heckenbach frank@g-n-u.de wrote:
Frank D. Engel wrote (by private mail, but from the content I suppose it was meant for the list; excuse me if I'm wrong):
How about addition, since in 'subclassing' we would be adding
fields:
TYPE base = NIL + RECORD i : INTEGER; j : INTEGER END;
child = base + RECORD x : REAL; y : REAL END; otherchild = base + NIL; hotdog = NIL + (x : INTEGER; y : REAL); cheesedog = hotdog + (t, q : CHAR);Or something similar (prob. the first three preferred; the latter
two
are a wild shortcut idea).
At first sight, it's certainly a little strange ...
BTW, apart from the syntax, the topic reminds me of another thing. For some time, I've had the idea of extensible enum types (unlike with records, there's currently no alternative in GPC, except using integer constants, of course). Even if you have no "forks", that would be useful across modules (where you can't always declare the largest type first, and the other ones as subranges).
The situation would be a little different from records -- you could assign a value of a small type to a larger one, not vice versa. You wouldn't need `is' and `as', simple comparisons and assignments will do.
I don't know if any dialect has something like this. If not, and we'd make up something new, maybe we could use a common (or similar) syntax with extensible records ...
Frank
-- Frank Heckenbach, frank@g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
===== ======= Frank D. Engel, Jr.
__________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Frank D. Engel, Jr. wrote:
Yes, this was meant for the list; I have had another message come to me as well that was intended for the list, but got sent to only the one person who wrote the original msg.
It seems that 'REPLY' does not work for this list?
By default, the list doesn't set a `Reply-To' header, so "normal" replies go to the sender, and list/group replies (i.e., replies to the sender and all receipients, a function that most MUAs have) go to the list (also).
You can change your personal settings to get a `Reply-To' header (send a help message to majordomo@gnu.de to find out how).
Frank
Frank Heckenbach wrote:
BTW, apart from the syntax, the topic reminds me of another thing. For some time, I've had the idea of extensible enum types (unlike with records, there's currently no alternative in GPC, except using integer constants, of course). Even if you have no "forks", that would be useful across modules (where you can't always declare the largest type first, and the other ones as subranges).
Something like this ?
TYPE Enum0 = (e0, e1, e2); Enum1 = (( Enum0) e3, e4)
So, if we have two variables:
VAR V0: Enum0; V1: Emum1;
the rules of compatibilty would allow the assignment
V0:=V1
but the compiler would have to do a (optional) range check to be sure that a actual value of V1 is within the range of Enum0 ?
I like the idea.
I don't know if any dialect has something like this. If not, and we'd make up something new, maybe we could use a common (or similar) syntax with extensible records ...
Frank suggested Record (), which has the right style and serves the purpose:
T = RECORD () x, y: INTEGER END; T0 = RECORD (T) z: REAL END; T1 = RECORD (T) w: LONGREAL END;
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
BTW, apart from the syntax, the topic reminds me of another thing. For some time, I've had the idea of extensible enum types (unlike with records, there's currently no alternative in GPC, except using integer constants, of course). Even if you have no "forks", that would be useful across modules (where you can't always declare the largest type first, and the other ones as subranges).
Something like this ?
TYPE Enum0 = (e0, e1, e2); Enum1 = (( Enum0) e3, e4)
Perhaps, though I find the nested parentheses a little strange. At least I'd add a comma:
Enum1 = ((Enum0), e3, e4)
But actually, both seem to be very hard to parse (consider a subrange `((Enum0)) .. Foo', so the parser would have to read ahead until after the first `)' to find the difference).
BTW, the following (which might look "natural" at first sight) would not work at all:
Enum1 = (Enum0, e3, e4)
because it would be ambiguous if Enum0 is defined as an enum type in an outer scope (so it could mean an extension, or a new local enum value).
This might be easier to parse (would have to check) and perhaps look "nicer", but it wouldn't fit to the records:
Enum1 = Enum0, (e3, e4)
So, if we have two variables:
VAR V0: Enum0; V1: Emum1;
the rules of compatibilty would allow the assignment
V0:=V1
but the compiler would have to do a (optional) range check to be sure that a actual value of V1 is within the range of Enum0 ?
Exactly. Just the same as when Enum1 was declared first, and then Enum0 as a subrange of Enum1.
I like the idea.
I don't know if any dialect has something like this. If not, and we'd make up something new, maybe we could use a common (or similar) syntax with extensible records ...
Frank suggested Record (), which has the right style and serves the purpose:
T = RECORD () x, y: INTEGER END; T0 = RECORD (T) z: REAL END; T1 = RECORD (T) w: LONGREAL END;
The more I think about it, the more it seems logical to me (though empty parentheses in general look strange to me) ...
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
BTW, apart from the syntax, the topic reminds me of another thing. For some time, I've had the idea of extensible enum types (unlike with records, there's currently no alternative in GPC, except using integer constants, of course). Even if you have no "forks", that would be useful across modules (where you can't always declare the largest type first, and the other ones as subranges).
Something like this ?
TYPE Enum0 = (e0, e1, e2); Enum1 = (( Enum0) e3, e4)
Perhaps, though I find the nested parentheses a little strange. At least I'd add a comma:
Enum1 = ((Enum0), e3, e4)But actually, both seem to be very hard to parse (consider a subrange `((Enum0)) .. Foo', so the parser would have to read ahead until after the first `)' to find the difference).
I think such extensions to Pascal are not likely to become generally adopted, and will create many more problems than they solve. Over 20 years ago PascalP included the extension syntax:
arraytype[initindex FOR length]
to describe a subarray. This has been especially noticeable by being totally ignored by the community, although it is a very useful (and compilable and checkable) construct. This was Bob Fraleys idea, and if it survives anywhere else it would probably be in HPs Pascal implementation.
As far as the enums above are concerned, what is wrong with:
TYPE Enum1 = (e0, e1, e2, e3, e4); Enum0 = e0 .. e2;
CBFalconer wrote:
I think such extensions to Pascal are not likely to become generally adopted, and will create many more problems than they solve. Over 20 years ago PascalP included the extension syntax:
arraytype[initindex FOR length]to describe a subarray. This has been especially noticeable by being totally ignored by the community, although it is a very useful (and compilable and checkable) construct. This was Bob Fraleys idea, and if it survives anywhere else it would probably be in HPs Pascal implementation.
AFAICS, this is equivalent to the EP mechanism `arraytype[initindex .. initindex + length - 1]'.
I don't know why EP chose that syntax (perhaps some other compiler(s) had that already?), but since both seem to provide the same functionality, it seems alright to have only one in the standard.
As far as the enums above are concerned, what is wrong with:
TYPE Enum1 = (e0, e1, e2, e3, e4); Enum0 = e0 .. e2;
As I wrote in another mail, that's not possible if the extension is in another module than the base type. (E.g., I define some identifying codes for some things in one module, and want to add some more in another one. The only way to do it currently (AFAICS) is to use integer constants and care for non-overlapping numbering myself.)
Of course, this issue didn't arise in the original standard which had no modules, so Wirth didn't have to consider it, and we can only guess if he'd have considered such an extension ...
Frank
On 11 Dec 2002 at 3:13, Frank Heckenbach wrote:
`arraytype[initindex .. initindex + length - 1]'.
I don't know why EP chose that syntax (perhaps some other compiler(s) had that already?)...
Ada uses this notation (called "array slices"). But the form goes back at least to various BASICs of the 1970s, where substring variable accesses were specified in this manner (with slight syntactic variations).
-- Dave
-
Adriaan van Os -
CBFalconer -
Frank D. Engel, Jr. -
Frank Heckenbach -
J. David Bryan