🚀 go-pugleaf

We have been using Logitech's compiler for a few years now. I looked at
the JPI compiler and was quite impressed with it, at first. The things 
that made us stay with Logitech:
	Logitech used library modules that were quite similar to the ones
in Wirth's book. The JPI compiler "improved" the modules, using different
names for modules and procedures in modules. Some of the otherwise
identical procedures had the order of the arguements changed. JPI supplied
their CORE library, which defined modules with the same names (and with the
same procedures) as Logitech's. They didn't include FileSystem.

	Converting our Logitech code would have been a major pain.

	I wrote some assembly modules. These would have had to be changed
to match up with the segment and module names used by Logitech. There isn't
anything wrong with the way that JPI did these things, it just wasn't
worthwhile redoing the existing code to fit the new system.

	We found an odd implementation error in JPI's VAL statement. VAL
should always give you either a good conversion or a runtime error. JPI's
would happily convert a negative integer into a large cardinal without
warning. It also seemed to give you some 16 bit chunk out of a real when
you did a VAL from real to cardinal.

	They may have fixed all of these things by now. Unfortunately,
we have written even more Logitech code, making the conversion even harder...

	We don't mind the speed of the Logitech compiler system. The compiled
code is acceptably quick for our applications. I like the point editor a
*** LOT *** better than the wordstar clone in JPI.

	The people at JPI are very nice and the compiler isn't bad, but we'll
be sticking to Logitech until something comes along that is so much better
that it is worthwhile changing. Stony Brook looks good so far and our programs
seem to port easier. We're still looking.

		Chris