Gale Paeper wrote:
After examining some of the implementation mechanics in this area, I think there is a fundamental disconnect in the type system created when literal string constants of the one string-element form (e.g., 'c', '''', etc.) are classified as LEX_STRCONST in the lexer. (This probably applies to the Borland #20 and ^I character constant extensions also.)
The language rule distinguishing between char type and string type for literals is based solely upon lexical context.
For literals? String literals of length 1 are just the same as char literals, aren't they? (BP char literals are not governed by the standards, but it seems reasonable to treat them the same as those, and that seems to be what BP does.)
In discarding the distinguishment at the lexer level, the information necessary to distinguish between char-type and string-type classification for one char element entities is lost and there is no language rule available outside the lexical context which can reliably be used to reconstruct the lost information.
For literals, AFAICS, the condition length = 1 (or length <= 1 in EP) is all that's required.
In ISO 7185 with the limited constant declaration and string-type capabilities, one probably could deduce (based on the inferences in the constrained constant construction possibilities) the type based on string length outside the lexical context; however, this isn't possible in ISO 10206 since there are a multitude of ways to construct constant one char element entities of string-type which are not also char-types.
So the important difference is between literals and other string constants. In GPC, this is expressed by the flag `PASCAL_TREE_FRESH_CST' (maybe it would be reasonable to rename it to something with `LITERAL'), and that's in fact what I used in the latter fix. So a constant result of `SubStr' etc. now does not have this flag set, and `string_may_be_char' checks this flag.
(With the present GPC limitations in supporting some ISO 10206 constructs for constant declarations, I don't think I can construct working test cases to demonstrate (or check for) problems in this area so this is an observation based upon my inspection the compiler code. I don't profess to have a expert understanding of the compiler internals so I could be mistaken on the Pascal code effects.)
I suppose you mean thing like this (which doesn't work in the next GPC anymore):
program Foo; begin case 'x' of SubStr ('abc', 1, 1) .. 'z': end end.
But for non-constant expressions, things get easier, since it would appear strange if it wasn't known until runtime whether they were ordinal values and would have added a lot of checks (not only in Ord, also in Succ, Pred, High, Low, FillChar, Include, Exclude, Seek..., and perhaps more).
I wouldn't be too hasty in making generalizations of ord's argument type requirement being specified in expression terms. Although most of the ISO required functions' argument type requirements are specified in expression terms, there are some which are specified using terminology which opens up a route to applying type compatibility rules with char-type/string-type compatibility implications. With the ISO required procedures, it is even more of a mixed bag of requirements.
I did some checks recently. I found that `Pack' and `Unpack' allow for assignment-compatibility, and that's covered by the 2nd parameter of `string_may_be_char'.
[snip]
I'm not sending a patch now, because there were several changes, and I don't remember exactly which ones were necessary or might have broken other things I've fixed meanwhile. I hope it won't be too long till the next release.
Not a problem. In general, my preference in the fix department is to take the time necessary to ensure the fix is the correct means to rectify a problem. In the long term, a hasty fix may end up taking more time to get a correctly working solution than the time it would take if one spent the necessary time upfront to get it correct on the first try.
Agreed completely. Sometimes I send quick patches when the chances are good that they have no regressions (but sometimes that turns out wrong, as in the first gale1 patch).
It should be understood by anyone who tries them that such patches are to be used with caution and tested well. (A complete test run of the test suite and my own code base on various platforms takes 2-3 days, so I can only do it before releases).
Frank