Frank Heckenbach wrote:

Adriaan van Os wrote:

...

I am adding a few notes about building on Mac OS X.

The following tools may be needed:

• sed 4.0.x

a too old version is installed with XCode or OS X (I use 4.0.5, but I assume later versions work also) ftp://ftp.gnu.org/gnu/sed/

Well, I have 3.02 here (very old) and didn't notice any problems.

I don't know what bizarre version of sed Apple distributes - the default system sed on Mac OS X doesn't have a version switch and gpc reports that it is "crippled".

Regards,

Adriaan van Os

Frank Heckenbach wrote:

...

Adriaan van Os wrote:

...

I am adding a few notes about building on Mac OS X.

The following tools may be needed:

• sed 4.0.x

a too old version is installed with XCode or OS X (I use 4.0.5, but I assume later versions work also) ftp://ftp.gnu.org/gnu/sed/

Well, I have 3.02 here (very old) and didn't notice any problems.

I don't know what bizarre version of sed Apple distributes - the default system sed on Mac OS X doesn't have a version switch and gpc reports that it is "crippled".

[G5:~] adriaan% strings `which sed-old` | grep Regents The Regents of the University of California. All rights reserved.

So, it's a FreeBSD sed (not a "too old version")

Regards,

Adriaan van Os

I would like to use the built-in Round() function, but its getting masked by the round() function if fp.pas in the Universal Interfaces, and they are not compatible (one returns a Integer, the other a double).

In the past, with other Pascal dialects, I have solved this by using System.Round() to get the built-in routine, but I don't believe this syntax is supported by GPC.

I could in theory arrange my uses clause to avoid using the fp unit, but as it turns out I only ever use Round() in routines that also require the fp unit's functions.

Is there a simple solution to this?

The simplest solution is to rename `round' from fp.pas on import like:

import fp (round => fp_round);

The `System.Round' syntax is supported, but ATM have different meaning: it requests `Round' form module `System'. In gpc `System' module does not export `Round' (and it have to be explicitly imported). Also, ATM gpc does not support exporting built-in indentifiers, so the best one can do is to make a little module like:

module gpcround; export gpcround = (RoundRealInt => Round); function RoundRealInt(r : Real): Integer; end; function RoundRealInt(r : Real): Integer; begin RoundRealInt := Round(r) end; end .

and then import `gpcround', for example like:

import qualified gpcround;

The second way requires gpc-20050217 (qualified indentifiers).

Which gives me another problem. I've never used 'import' before, just 'uses'. Looking at the GPC manual, 'import' can only be use in a program file not a unit/module. This is rather limiting for me, if true, as my problem code is spread around several units.

You mean:

: There must be at most one import part in a program.

That statement is wrong. Correct statement is:

There must be at most one import part at the begining of a block. Each module or function/procedure (and also main program) can have its own import part. Single import part can import arbitrarly many interfaces.

The point is that:

import unit1; import unit2;

is illegal, but:

import unit1; unit2;

is legal.

steven.borley wrote:

In ISO Pascal Trunc is a predefined function that returns an integer value. It is an error if the result value of Trunc doesn't exist in the Integer type. The fp.pas unit of Apple’s PInterfaces declares a trunc function that returns a value of type Double_t.

To solve this ambivalence, the trunc function in fp.pas has been renamed to truncd.

</quote>

So this looks like the same problem as I have with Round(), but with a different solution. So I'm now beginning to think think this is a GPCPInterfaces bug (or at least inconsistency). Should round() in fp.pas not have been renamed roundd() for the same reasons?

Yes, this was reported before - on the maccompiler mailing list. We decided to change "round" in fp.pas to "roundd". Then - we completely forgot about it. Peter, can we make a change in the interfaces script now, so that it will be included in the next release ?

Regards,

Adriaan van Os

Gale Paeper wrote:

"steven.borley" wrote:

...

On 20 Feb 2005, at 18:37, Waldek Hebisch wrote:

 The simplest solution is to rename `round' from fp.pas on
 import like:

 import fp (round => fp_round);

Yes, that works for a simple test program.

Which gives me another problem. I've never used 'import' before, just 'uses'. Looking at the GPC manual, 'import' can only be use in a program file not a unit/module. This is rather limiting for me, if true, as my problem code is spread around several units.

Although I haven't tested it with the latest versions of GPC, I have in the past used Extended Pascal's renaming feature in a uses clause so "uses (round => fp_round)" is alternative to try if you prefer uses clauses to import specifications.

This doesn't work anymore. It was removed because of syntactic conflicts. But `import' works for units as well, so you can use this instead.

Frank

I would like to use the built-in Round() function, but its getting masked by the round() function if fp.pas in the Universal Interfaces, and they are not compatible (one returns a Integer, the other a double).

In the past, with other Pascal dialects, I have solved this by using System.Round() to get the built-in routine, but I don't believe this syntax is supported by GPC.

Is there a simple solution to this?

One option would be to make a unit like:

unit SystemRoundUnit;

interface

function SystemRound( x: Real ): Integer;

implementation

function SystemRound( x: Real ): Integer; begin return Round( x ); end;

end.

(untried, untested, uncompiled)

At 10:03 PM +0000 20/2/05, steven.borley wrote:

Another thing. I noticed is that trunc() has been renamed to truncd() in fp.pas and there is a comment on the microbizz site (http://www.microbizz.nl/gpcdiffs.html) that says this...

So this looks like the same problem as I have with Round(), but with a different solution. So I'm now beginning to think think this is a GPCPInterfaces bug (or at least inconsistency). Should round() in fp.pas not have been renamed roundd() for the same reasons?

The argument could certainly made that this is inconsistent. I have no objections to the change, if Gale & Adriaan agree.

Enjoy, Peter.

Adriaan van Os wrote:

Waldek Hebisch wrote:

...

The second way requires gpc-20050217 (qualified indentifiers).

Do we have a way to qualify built-in routines, e.g. "program.round"

No, we don't (except by explicit wrappers, as others have described).

(as "system.round" refers to a "system" unit) ?

Yes, it refers to a `System' unit. But built-in identifiers are not declared in a `System' unit (which would violate EP where `System' is not a special name), but at "level 0" as Chuck calls it (I don't know if the standard has a term for it, I think it just talks of "required procedures and functions" and that they have a "defining­point not contained by the program­block").

One could consider whether to add such a facility, but especially for built-in routines with special syntax (such as `WriteLn') this will probably not be easy, so I don't really like the idea.

Frank

Russell Whitaker wrote:

On Mon, 21 Feb 2005, Frank Heckenbach wrote:

...

Adriaan van Os wrote:

...

Waldek Hebisch wrote:

...

The second way requires gpc-20050217 (qualified indentifiers).

Do we have a way to qualify built-in routines, e.g. "program.round"

No, we don't (except by explicit wrappers, as others have described).

...

(as "system.round" refers to a "system" unit) ?

Yes, it refers to a `System' unit. But built-in identifiers are not declared in a `System' unit (which would violate EP where `System' is not a special name), but at "level 0" as Chuck calls it (I don't know if the standard has a term for it, I think it just talks of "required procedures and functions" and that they have a "defining­point not contained by the program­block").

One could consider whether to add such a facility, but especially for built-in routines with special syntax (such as `WriteLn') this will probably not be easy, so I don't really like the idea.

Would it be easier to have the linker ignore the built-in round() if there was a library module containing round() on the command line?

Most built-ins are not plain functions at the linker level. `Round' is done with inline code, `WriteLn' expands to several calls, etc.

But that's not the point, actually -- overriding built-ins is already no problem. It's accessing them when they're shadowed which is not possible (in accordance with the standards).

Since Adriaan and Peter have already renamed their `Round', this particular problem is solved anyway.

Frank

Waldek Hebisch wrote:

Frank Heckenbach wrote:

...

Yes, it refers to a `System' unit. But built-in identifiers are not declared in a `System' unit (which would violate EP where `System' is not a special name), but at "level 0" as Chuck calls it (I don't know if the standard has a term for it, I think it just talks of "required procedures and functions" and that they have a "defining­point not contained by the program­block").

One could consider whether to add such a facility, but especially for built-in routines with special syntax (such as `WriteLn') this will probably not be easy, so I don't really like the idea.

Special syntax make this feature valuable: there is no way to emulate built-in syntax via wrappers. Also, it is one of biggest remaining BP incompatibilities.

Concerning implementation: I do not see how to do really nice implementation. But IMHO there are two reasonbly easy ways.

One is to check for "magic" module name in the lexer and then do a lookahead for dot and routine name.

BTW, not only routines, also constants such as `MaxInt', types such as `Integer' and variables such as `Output' (which is particularly strange given the standard properties of `Output', being a program parameter or imported from `StandardOutput').

If there is a match generate apropriate "builtin" token. Of course, one needs an extra state machine in the lexer to avoid false positives. And extra logic in the parser to reject such names in places were qualified names are not allowed

Or perhaps leave the last part to the parser, i.e. let the lexer return LEX_BUILTIN_MODULE (or whatever), and in the parser recognize `LEX_BUILTIN_MODULE '.' p_New' where `p_New' is allowed.

However, this would conflict with our use of a `System' unit (module) to define some really ugly BP stuff I don't want to build in.

Another way is to put GLR parser to an extreme: remove special treatment for builtins from the lexer and generate both normal parse and a parse as a builtion. Then use merge action to choose correct one.

As I write this yet another idea: parse everthing like `writeln' (it seem to be the most general form of a call)

Syntactically yes. But `New' and `Dispose' with object con-/destructors also require special handling while parsing(!) (since con-/destructor names must be made visible for the second argument, see current_structor_object_type).

`Addr' and `Assigned' do because they need to suppress function calls (though we might be able to get rid of this special case if we reorganize function calls as discussed recently).

And don't forget `System.Fail', `System.Continue', `System.Break' and `System.Exit'. (Yes, BP does allow these!) (Well, actually, the first three are implemented like normal built-ins in GPC, but `Exit' not because of new the UCSD/Mac Pascal syntax, also `Return' not (not BP compatible, but to be consequent ...)

AFAICS, these problems would also preclude the GLR suggestion since such things as `Addr' are syntactically the same. So one at best make two equivalent parse rules and "merge" them (which I'd consider almost an abuse of GLR).

And if, I think we'd have to use dprec rather than merge since merge first evalutes both variants which might lead to spurious errors.

and then check in sematic actions if the routine identifier resolve to built-in. If no then reject calls using extended syntax. Structured value constructors work in similar way. Such approach can even make the compiler simpler then it is now.

If we get rid of all the special cases I mentioned, perhaps, but ATM I don't see how we could.

Frank