Marco van de Voort wrote:
I do not think so. It is one thing to want to force one's code to adhere to a particular strict standard (e.g., EP or SP), and it is quite another, to turn on some features of one "standard", while turning off others. IMHO, if one is not coding to the strict requirements of EP or SP (or perhaps, when ready, ANSI OP), then one might as well just accept GPC's strength in supporting a wide variety of dialects, with the understanding that this might require (in the case of pre-existing code) some changes to the names of variables or data types that clash with keywords in the supported dialects.
Or, like FPC did, implement per "standard" a strict mode and a loose mode.
The strict for keeping legacy apps running, the loose mode for interoperability.
I don't see how this should solve Dave's problem. AFAIUH, he's using "all" of GPC's features (i.e., not restricted to a particular standard or dialect) and was only disturbed by a particular keyword.
Using a loose version of --borland-pascal or --extended-pascal would probably give him other restrictions -- let's say, `asmname' would be disabled because it's not a keyword there, and he's using `asmname', AFAIK.
--gnu-pascal (the default), OTOH, is already as loose as possible (i.e., all features activated), and making a stricter version of --gnu-pascal would raise the question what should be restricted (with probably twice as many answers as there are users ;-).
Besides, since we don't want to encourage the use of dialect options, anyway, I don't think it's worth the effort to create loose versions of them.
As I already said in other mails, I'd prefer some more options to fine-tune the dialect (like --disable-keywords), so one doesn't have to use a dialect option just because of one single issue (like in this case). (Besides, those options are probably quite a bit easier to implement than new dialect versions because they only affect specific parts of the compiler.)
Frank