Frank Heckenbach wrote:
Gale Paeper wrote:
To clarify, you are questioning the legality of just ord(substr((s),1,1))?
Yes (my reference was unclear, indeed).
[snip]
Given the mixture of error results, I was in the process of determining exactly what should be legal according to standard requirements when I saw the fix patch posting which in essense said problem solved so I didn't pursue the legality question any further.
At that time I thought it was ok. When dealing with string constants, it's known at compile time whether or not they have length 1 (i.e., whether or not they could, apparently, be a Char value), so all seemed well. With the clarifications below, this part actually gets more difficult, since there are string constants of length 1 that can or cannot be Char values ...
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. 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. 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.
I think if one investigates all the Pascal language constructs where constants of ordinal-type are required (and constant string-type usage is illegal), there will be a quite a few "difficult parts" in the compiler as long as constants of char-type are categorized as constants of string-type at the lex level. A simple search on "string_may_be_char" turns up quite a few instances which look like they may have problems in the constant char-type versus constant string-type area - case constants, subrange types, set type constructors to name a few. (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.)
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. (For the non-ISO required procedure/function extensions, that is a whole different bucket of worms with imprecise teminology/non-authoritive documentation and mismatches between implementation and documentation thrown in to make the bucket more "interesting".)
[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.
Please check if the test programs seem alright now.
The test programs, gale1[abcd].pas, look alright.
Gale Paeper gpaeper@empirenet.com