Hello Allan!

Thursday March 28 1996 10:18, Allan Mertner wrote to Paul West:

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

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

IT's not supposed to, That's against the Pascal standard..  Relax syntax is
NOT good, Especially in a structured language. (IE, It works for C. not for
Pascal)

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

I don't see why this is a problem, and it could be fixed very easily..
(just with a search/replace and an extra function in the DOS unit)

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

And which version are you baseing this statement on.

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

Yes, And Virtual pascal is a Pseudo 32, Not true 32 bit compiler :)

 AM> Thanks for listening.  Virtual Pascal of course handles the above
 AM> mentioned issues, but that is beside the point.

some of which i would prefer NOT be handled..

 AM>  What I don't
 AM> understand is that some people actually seem to be happy with and can
 AM> get work done with Speed Pascal, in spite of the incompatibilities and
 AM> the non-existence of its debugger. Amazing stuff :)

The debugger exists, It works, It is the same as Turbo Pascal 7.0 has..
(nearly exactly) And it is better than what i'm USED to.... (Modula 2 for
Os/2 with no debugger, Debugging going on with Readln's and writeln's,
Forth with lots of . commands..  Etc)

With a well written compiler and a well structured language, There is less
need for a heavy duty debugger. With a heavily unstructured language you
run into major need for debugger (**C++,Basic**)

Not only that, but Speed pascal is oft better for porting things over to
OS/2 simply because the end product is more stable when you are finished,
In Virtual, Because it allows 16 bit ASM, Programs can be very unstable.
Also the MEM and ABSOLUTE stuff Virtual will NOT catch when porting from
Dos. They simply don't work.

All of my porting of DOS libraries i port to Speed pascal, Then over to
virtual, I tried it the other way, IT was very unstable in Virtual,
Wouldn't compile in Speed (speed caught all the bugs which were causing it
to be unstable in Virtual)

Speed fits my work quite well, The only code i havent' been able to get to
work just with 1-2 minor changes have been 16 bit ASM (Unstable) and
procedures relying on MEM and ABSOLUTE (done with VIO and DOS calls)

(And the fact that VP authors are always out bashing SP doesn't help my
opinion of vp.. :)

Keith

... I think so brain, But if we didn't have ears, We'd look like WEASELS!
--- GED/2 2.50 UNREG