Pascaline checkoff list

[Scott Franco]

Here is the near term Pascaline checkoff list.

This is the same order as the sections of the Pascaline manual.

6.1 New word symbols: Done
6.2 Special symbols: Done/no change required.
6.3 Comments: Done
6.4 Identifiers: Done
6.5 Labels: Done
6.6 Numeric constants: Done
6.7 Constant expressions: Done
6.8 Boolean integer operations: Done
6.9 View and out parameters: Done
6.10 Extended case statements: Done
6.11 Variant record case ranges: Done
6.12 Array type shorthand: Done
6.13 Container arrays: Done
6.14 Parameterized variables: Done
6.15 Extended write/writeln statements: Done
6.16 Extended read/readln statements: Done
6.17 Type converters/restrictors: Done
6.18 Fixed types: Done
6.19 Extended file procedures and functions: Done
6.20 Added program header standard bindings: Done
6.21 Redeclaration of forwarded procedures and functions: Done
6.22 Anonymous function result: Done
6.23 Extended function results: Done
6.24 Halt procedure: Done
6.25 Overloading of procedures and functions: Done
6.26 Operator overloads: Done
6.27 Static procedures and functions: Done (its a no-op)
6.28 Relaxation of declaration order: Done
6.29 Exception handling: Done
6.30 Assert procedure: Done
6.31 Extended range types: Done (equates to integer)
6.32 Extended real types: Done (equates to real)
6.33 Real limit deternination: Done
6.34 Character limit determination: Done
6.35 Matrix mathematics:
6.36 Properties:
6.37 Modularity: Done
6.38 Channels:
6.39 Classes:
Annex C: Undefined program parameter binding: Done
Annex E: Character escapes: Done

[Scott Franco]

Problems with GPC file handler modes:

First, GPC assumes whole integer file output, even on things that seem to have less size:

type byte = 0..255;
bytfil = packed file of byte;

Outputs whole 32 bit words to the output file (its actually a standard Pascal FAQ). This is not the first compiler I have seen do this. Its annoying. The result is inability to read any real files that weren't created by Pascal itself. Its rather easy for the compiler to assume bytes are, well, byte sized.

When I had this issue before I solved it by converting to and from char representations, which have the correct size.

The other issues are that the file I/O procedures are poorly or completely undocumented, including with "???" and "to be improved" markups. Some of the procedures in the documentation don't actually work. In the documentation, it says that many things from Borland Pascal are implemented, and that is sometimes true (despite total absense from the documentation). However, the things I found from Borland "by accident" have odd working characteristics that make them unusable, or at least require a lot of work to find out what they are doing.

As a result, the GPC version of file handling does not do much more than open a file by name, seek within it, find its length or current position, etc.

Hopefully FPC will be better.

[Scott Franco]

Annnnddddd Scotty figures out the trick with GPC.

Step 1: Ignore the manual :-)

Not kidding. The answer was to just use the underlying routines in the C library. This works:

program test(output);

var r: integer;

function remove(fn: Cstring): integer; external name 'remove';

begin

r := remove('junk');
writeln('Result is: ', r);

end.

Thus you can do pretty much anything you want. That fixes the problem with GPC I/O. Will check in a fix for this.

[Scott Franco]

Update: That checkoff list has been going down rapidly.

Because of that, I am going to put off tickets #1 and #4 and go for %100 Pascaline implementation.
My plan is to put out a version 0.1 in Feb that is fully functional before moving on. One advantage is there is quite a bit of Pascaline support software that I can pull in from other projects, even if P6 is still interpreter only.

Cheers.

Scott Franco

[Scott Franco]

Leftovers

With the implementation list likely to close in this quarter (apr-jun) its worth looking at what does NOT get closed with the completion of the list.

1. Unsigned/linteger/lcardinal/lreal/sreal support. I looked at this, there is no reason that this could not be done in the current interpreter, since the hosts support those types as well (gpc/fpc/gcc--yes, gcc is a host now). I didn't do it because it is not necessary to have before creating a code generator.

2. Unicode support. gcc supports this, fpc appears to, gpc appears not to. Again, not necessary to a code generator.

3. Pascaline standard libraries. Actually some of these are just automatic. IP Pascal has some of them, but others perhaps not. I don't mind moving them over. What does "perhaps not" mean? Well, most of the implementation libraries exist because they cover system dependencies. For example, most of the IP Pascal implementation libraries rely on Windows implementation details.

It was for this reason that I started the Petit-ami project. The idea of that is that it is:

A. Written in C, and thus useful to a larger audience.
B. Written to use standard porting packages like curses and GTK.

That is a ways into the future, but I expect that I'll decide how that goes at that time.