Grant Jacobs wrote:

Shifting this thread over from gpc@gnu.de... (excuse the length of this)

Shifting back the part of your mail that really isn't about documentation. ;-)

...

...

1. --interface-only -c doesn't (always) produce a .o as the docs

say,

Maybe you misunderstand the purpose of the option. It means to process only the interface part of a unit/module. Of course, you generally don't get a complete program without the implementation.

I sort-of got this right the first time around ;-)

The reason I went astray, was that I expected that compiling a unit would produce an object file, which would later be linked in when the main was compiled.

That's right -- but only for compiling a whole unit.

In practice, none of the units I've tried compile fully on their own.

Of course not.

You get complaints about undefined main, etc., which lead me to thinking that there much be some sort of compiler switch that'd tell it to not look for / create a main function, just create an object file 9library if that suits you better) to later be linked to a main program.

So, that's where the confusion seems to be. Compiling a unit never creates a `main' function (that's for the main program). What you seem to want is simply `-c' (compile the unit, but don't try to link it), whereas `--interface-only' really processes only the interface part and ignores the implementation part, so it can't create a (useful) object file.

This is why a description of how to compile units/modules would have helped...

Generally, just compile your main program with `--automake' and all units used will be compiled automatically when necessary.

...

...

if the file is untyped. It'd be nice if there was a 'silent default' so that existing programs work 'as is'. For example reset( infile, infname ) ; gives a syntax error and demands that a buffer size be added.

Yes, it's be nice, but BP stands in the way, as noted above. (AFAIK, the misdesign goes back to UCSD Pascal and the CPM file system ...) I think it would be too confusing to have two different silent defaults, depending on the dialect option.

But how about an explicit default by the user from the command-line?

So if someone forgets this option while compiling, the users get rather strange effects at runtime. I'd rather stay away from such obscurities ...

Easier than fiddling with their code (not that that's a terribly to do in this case)... low priority... its solvable if faintly irritating. if it was C, I'd use a macro to solve this, FWIW.

Well, if you reaaally like to, you can do this in GPC as well ... :-/

...

The only thing I could possibly imagine would be to make the difference clear in some other way, e.g. to have the file declared as `file of Void' or so (with a default of 1), whereas a simple `file' (as in BP) behaves as it does now.

Or redefine type File, doing which, err, must raise its own issues...

type file = file of void ;

I had suggested that, but I don't really like it. It looks like a "typed file" for which `Read' and `Write' rather than `BlockRead' and `BlockWrite' would apply.

{or} file = file[1] ; { ie file[<bufsize] }

Too close to EP's file index (`file [domain] of element-type').

{or assigning it, a la OOP in an initialisation section } file.bufsize = 1 ;

Too "magic" (making up a field of something not a record). If anything, one could think about using bindings (EP compliant) -- but then again, that wouldn't exactly be easier than adding one parameter in `Reset' ...

Hmm. Getting a bit fanciful, perhaps. What I'm trying to do is to tie the buffer size with the file handle, which does makes some sense.

I agree, but I don't see a reasonable way to do so.

I suspect fewe users would vary the buffer size from one reset/rewrite to another,

I suspect very few would ever use anything else than 1 ...

so in principle it could be associated with the file for most folk. But I can see the merits of sometimes needing to altering it.

Actually, I don't. For the very rare cases, it wouldn't be demanding to much having to declare another variable.

...

...

3. One of my enumerated types contains 'property' and 'operator'

which prove to be GPC reserved words of some sort as the compiler throws up a syntax error. I don't really want to have to alter these... are these keywords part of some new standard?

`property' is from Delphi, `operator' from PXSC.

Generally, if you don't want any extensions (which include a few new keywords, of course), try `--extended-pascal'.

The next GPC will also support `--disable-keyword=property,operator' (or `{$disable-keyword=property operator}' in the source).

Grr. Any ideas on how long its going to take for this to appear?

Uhm, last week. (IOW, sorry for the late reply. ;-)

I got the vague idea that part of the strategy of GPC was to allow keywords to be redefined so that older code won't bump into keywords from newer/different implementations of Pascal. So this isn't really in place yet?

Yes, but only where it's feasible to parse this. In some situations it's very hard to impossible to tell certain keywords from identifiers (i.e., it would require too much context, or maybe there would even be ambiguities). GPC does it in a number of cases, and probably some more can be done with more effort (volunteers welcome ...). But for the cases not recognized automatically, the new option is now available.

Frank