Hej Paul!

Monday March 11 1996, Paul West writes to Francois Thunus:

 FT>> 1.5 gamma-1 (march field test) is probably as close to the final
 FT>> release as you can get. The compatibility with Borland Pascal is
 FT>> almost perfect. Whatever gliches are left can be corrected in a

 PW> I've been playing around with the 1.5 Beta 5.  Is the gamma enough of an
 PW> improvement to get before purchasing the final product?

It is still quite incompatible with Borland Pascal and Delphi.  Some of the
bugs are fixable, whereas others just are impossible to address unless the
architecture of the compiler is changed drastically.  Someone posted this
list on CompuServe a week ago - for an alleged 99% compatible compiler in
v1.5 (This is bugs in the 1.5 release version), I think it's scary:

1) Nested if's with empty ELSE statements fail to compile:
  If x = 12 then
    if y = 23 then Writeln('Test')
    else  // Nothing
  else  Writeln('Test2');

2) IOResult is a variable, not a function.  InOutRes is undefined. 
IOResult should return the value of InOutRes and zero it...

3) Circular unit references in the implementation section are not allowed.
This makes SP almost useless for porting big libraries where such
dependencies are quite common.

4) {$I-} is not a compiler directive, but a statement.  Instead of
instructing the compiler to generate different code, it simply causes a
"RaiseIOError := True" statement to be inserted in the code. 
This means, that it cannot be used outside Begin..End blocks, for example
in the beginning of a unit.  It also means that the state of I/O checking
can be changed by Pascal code, as in the example:
  {$I-}
  Reset(f)
  ...
  If x = 0 then Exit;
  {$I+}

If x is 0, the I+ statement is never executed.  Sad.

5) The Comp datatype is not supported.  Real is equivalent to Double,
making it 8 bytes long instead of 6 bytes.  No way to read those old data
files...

6) Iterators in collections (For use with ForEach) must be local in Borland
Pascal.  In SP they must be global ?!?  This breaks heaps of old code :/

 PW> One thing that bugs me, and I can't find any documentation to tell me if
 PW> this restriction will be in the final release.  I can't seem to run the
 PW> EXE's on any machine that does not already have speed pascal loaded.  Is
 PW> there a runtime that has to be installed? or does the beta just check for
 PW> the compiler to prevent the beta from being used for real.

Text-mode apps written in SP require a 27kB DLL KBDVIO32.DLL to run. This
is because SP not supports thunking calls to 16-bit API functions - and all
of the text-mode Vio, Mou and Kbd calls are 16 bit.  The DLL is written in
C and cannot be written in Speed-Pascal.  If you want to access other
16-bit API calls, you need to write another thunking DLL for it - but not
in SP...

Thanks for listening.  Virtual Pascal of course handles the above mentioned
issues, but that is beside the point.  What I don't understand is that some
people actually seem to be happy with and can get work done with Speed
Pascal, in spite of the incompatibilities and the non-existence of its
debugger. Amazing stuff :)

Yours,
Allan

--- GoldED 2.50.A0531+