Frank Heckenbach wrote:

I think it's only "conditionally reserved" (like many keywords from various dialects are). E.g., `var Class: Integer;' seems to work. But I'm not sure in which situations it works and in which it doesn't (optimally, in all those situations where it can't be confused with a class type declaration).

Exactly. `class' is switched on as a keyword at the beginning of a `type' definition block, and switched off again afterwards. (It is intended to be used in about the same way as `record'.)

Since GPC does not yet have enough compatibility options ;-) we could introduce a compiler switch to permanently switch off specific keywords - in addition to the dialect used. What do you think?

Peter

Hi!

Eike Lange wrote:

IMHO, we should enable/disable "class" with the already existing switch --delphi.

`--delphi' does disable some non-Delphi keywords, but it does not affect `class' which is enabled in the Delphi dialect.

We intentionally do not want the `--foo-pascal' switches (including `--delphi') to _enable_ something; reasonable code should always compile without them.

You can, however, disable `class' with `--standard-pascal' or `--borland-pascal'.

The question is whether a separate switch, specifically for enabling/disabling keywords, makes sense.

Peter

Eike Lange wrote:

You mean something like --no-class ?

No, I mean something like `--disable-keyword="Class"'.

"Class" is a thing only used by Delphi (please correct me, if its not true).

It's also used in ANSI Object Pascal.

What do you think about --no-delphi which disables Delphi dialect support without affecting the rest for this special purpose?

No, thanks. ;-) Right now, it's already terribly complicated to handle restrictions to certain Pascal dialects everywhere. You do not really want to know how many places will have to be changed in the compiler in order to make GPC accept everything which is either in ISO Extended Pascal or in Borland's Delphi, but not the stuff from Borland Pascal 7.0 with the exception of the UCSD Pascal extensions, which should be accepted ...

I think that GPC's behaviour to accept a mixture of _everything_ by default with switches to restrict it to certain dialects and more switches for dialect-independent fine-tuning is quite reasonable.

Peter

On 8 Mar 01, at 16:12, Peter Gerwinski wrote:

The question is whether a separate switch, specifically for enabling/disabling keywords, makes sense.

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.

Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) Author of: Chief's Installer Pro for Win32 http://www.bigfoot.com/~African_Chief/chief32.htm Email: African_Chief@bigfoot.com

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