Faux Code

["Carl L. Distefano" 70154.3452@xxxxxxxx]

Robert:

I haven't tried XPLeNCODE, but if it'll "textify" anything with
no manual editing required, I for one will gladly adopt it. I'd
request a few modifications as to the conventions, however. One,
jettison "{<}" "{>}" for open and close guillemets; "{" and "}" are much easier
on the eye (perhaps you were trying to highlight the
"readability" problem?) and avoid confusion with the "greater
than" and "less than" signs. Two, for functions, I prefer the
trailing underscore (BC_) to brackets
([BC]), because it mirrors the 3-position display of embedded
funcs and avoids another set of open and close marks in a syntax
that's already rife with them. Three, a comprehensive utility
should translate the extended Speedo character set to the
appropriate bracketed numbers
([256] and up); I'd use brackets for Ascii 0-255, too. Four, it
should be able to convert either way, XPL to text *and* vice
versa -- a feature that I stand by in FAUXCODE, it being
understood that it's the author's responsibility to flag
additions to the conversion table that will be necessary for
conversion of a given code segment to work.

Aside from a few esthetic quibbles, I'm not at all bothered by
the readability of your pseudo-code. The "[255+x+y]" syntax is
transparent to anyone who knows how a 3-byte character is
constructed and, in one way, conveys more information than the
WYSIWYG character itself! And, while one of the standard
utilities is still the way to go for delivering XPL applications,
a comprehensive XPL utility will allow conversions without
leaving XyWrite -- always a desideratum -- and will, perhaps not
so incidentally, stand as yet another demonstration of the power
of XPL.

So, how about it? Assuming we get general agreement as to the
conventions, are you amenable to producing the goods? No one is
better positioned to do so.

--------------
Carl Distefano
70154.3452@xxxxxxxx