Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
From: Gale Paeper
Subject: FourCharCode
Date: 6 Jul 2003, 02:03:05
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
Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.
Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.
This page was created by Crystal 0.999 (Linux 2.4.27/i686).