Yes, there is no point in making existing XPL pgm's obsolete.
In an earlier email I wondered aloud whether it would be possible to write an XPL interpreter that would read XPL and feed
functionally equivalent output to a widely-available (perhaps even open source) text editor. So XPL code would then make this other editor do things to text that the XPL made XyWrite do.
But this is impossible without simply programming a Xy clone from the ground up. I get the impression that a lot of editors out there use character and screen manipulation routines provided by widely-used libraries from Microsoft, Apple or other
tall people. Those libraries may not provide the low-level access or control that XPL has to Editor.exe, and so XPL's way of doing many things may not map neatly onto these other libraries.
Myron
On Apr 12, 2018, at 10:01 PM, Carl Distefano mailto:cld@xxxxxxxx wrote:
Reply to note from Myron Gochnauer mailto:goch@xxxxxxxx Thu, 12 Apr 2018
14:02:00 +0000 Myron, Can anyone explain the 'nature' of XPL? That is: It's been described as BASIC-like, but of course it looks nothing like BASIC or any other language (though in its terseness it reminds me of APL). The essential nature of XPL lies in its complete integration with Editor.exe, its ability to execute the atomic tasks (represented by the 3-byte functions) that are at the heart of Editor. Of course, it would be possible to substitute a different scripting syntax that has the same degree of integration, but if the result is to make 3.5 decades of existing code obsolete, surely that would defeat the purpose of the current exercise. For this dream -- um, project -- to make sense, XPL has got to remain viable. -- Carl Distefano mailto:cld@xxxxxxxx |