Re: New XYENC 1/13/09 release

[wbass@xxxxxxxx]

Harry Binswanger wrote on 15 Jan 2009 at 12:12 -0800
>Wally Bass wrote on 15 Jan 2009 at 10:29 -0700

≫   'BC
≫   ~~>
≫   ~~>
≫   ~
≫     in_1st_if___
≫     ~
≫       in_2nd_if___
≫       ~
≫     past_1st_ei_
≫     ~
≫   past_2nd_ei_
≫   ~
≫   ~Z

>...

>In other words, all your squiggles, the < ~ etc., are
>redundant. They're just clutter. XyEnc, like XyBasic,
>could be set to interpret any IF as ≪IF or, in your
>version, ~So here's my XyBasic version of your your encoded XPL. It's
>case insenstive, but I prefer lower case for ease of typing

>'bc
>first = inkey$
>second = inkey$
>if first > 0 then
>  print "in first if"
>  if second > 0 then
>    print "in second if"
>  endif
>  print "past first endif"
>endif
>print "past second endif"
>exit

Then,

Harry Binswanger wrote on Fri, 16 Jan 2009 12:58 -0800
>Wally Bass wrote on Fri, 16 Jan 2009 03:45:33 -0700

≫... it's not about inventing a "better" language. XPL is
≫what WE HAVE to work with, and what things like U2 are
≫written in. XyWrite doesn't support XyBasic,

>I think you have a misconception about XyBasic. "XyBasic"
>is the name I gave to the whole idea; the actual
>translation is done by my DOS program, XyComp.exe, which
>"compiles" the Basic-like text to XPL.

I don't really have much conception at all of XyBasic, I suppose. Is there
any documentation?

>Think of XyBasic as a "front end" for composing XPL. I
>write all my XyWrite programs in the form of XyBasic, and
>then run XyComp.exe on it to translate or "decode" it to
>XPL. It ain't perfect, but it's 99%. In debugging, I do
>have to look at the XPL--mainly to see where my syntax
>error was.

I "get" that. But I think that most everything depends on what "99%"
really means.

In my view, XPL programs start getting interesting and powerful when I
start seeing variables (S/Gs) that are being set to "string" values which
are hairy mixes (no pun intended) of simple characters, primitive function
calls, 3 byte encoded characters, and perhaps a guillemet bracketed
command or two -- and then when the part-data/part-command S/G strings are
"PV"ed, causing some hairy mix of primitive execution, command execution,
and data injection to occur. With XPL, every string is really also a mini
XPL program, and many strings within a program can be significant in that
regard.

IMO, being able to mix that kind of content within a "string" is a major
part of XPL is all about. But mixing that kind of content within a string,
and being able to later tease it apart, requires that XyWrite have a
certain amount of "encoding" or "escape sequence" strategy and logic, to
differentiate the primitives and embedded commands from simple data.
XyWrite itself uses two "triggers" for its "escape sequences" -- the 0FFh
byte of the 3 byte encodings, and the the left guillemet of embedded
commands.

The contempt (or whatever) that you expressed above for the "squiggles"
and "clutter" (which are essentially a reflection of the escape
sequence/encoding problem) leads me to believe that you really don't have
that much appreciation for the potentially complex nature of such
part-data/part-command "strings" that occur in XPL. So, not having
information to the contrary, and just looking at the nature of your
XyBasic sample, I would expect that XyBasic doesn't have much capability
for creating these mixed, complex strings the make up the soul of XPL.
But, that's only my impression -- at this point I don't have enough
information to know.

If XyBasic does support such things, you haven't given me a clue as to how
it does so. If the language doesn't support such things, then IMO XyBasic
"robs" the XyBasic user of so much of the intrinsic power of XPL that it's
not a "99%" thing at all, it's more like a "50%" thing at best. It may
look like 99% to the XyBasic user who has allowed XyBasic to define and
limit his view of what XPL is all about, but it really isn't 99% at all,
IMO.

So, specifically, for example, it would help to know:

 1. Is there a spec? Is it reasonably precise/complete?

 2. Could everything that's in xywwweb.u2 be written in
  XyBasic? If not, what percent of xywwweb.u2 would you
  guess could be written in XyBasic?

 3. How does XyBasic deal with the question of when 3 byte
  encoded data is or needs to be included in strings?

 4. How does XyBasic deal with the question of when function
  codes are mixed with data in strings?

 5. How does XyBasic deal with the question of variable
  allocation to actual S/Gs, particularly when the
  allocation has to be coordinated with S/G assignments in
  other programs?

You can point me to a document, if that makes it easier to answer the above.

>Suppose I wrote an inverse program, call it BasicXy, to
>translate XPL into XyBasic language, wouldn't the pair be
>doing exactly what your pair is doing?

In some respects, it might be. But your supposition makes an implicit
assumption as to what is possible that is probably not true. It's simply
not a given that a given language, and it's translator, will be even close
to being capable of outputting arbitrarily sophisticated XPL programs.

So, before we can even go there, I need to ask some more questions:

 1. Do you have reason to believe that writing such a
  program is even possible? It is, of course, NOT possible
  unless the XyBasic language is capable and expressive
  enough to be used as a generator for virtually every
  possible XPL program, or at least the vast majority of
  existing XPL program. Without seeing some description of
  how XyBasic deals with all of the issues raised in my
  first set of questions, I have no reason to believe that
  writing such a program is possible. Or even close.

 2. Why haven't you done it? Certainly, folks have been
  after that kind of functionality for some time, even if
  only to address the XPL "emailing" problem. Presumably,
  that's why U2's ENCODE program exists -- but again, it
  seems to me that your approch would produce much "nicer"
  output, if it was doable.

XYDEC (the XYENC package's program corresponding to XyBasic) CAN generate
any XPL program. Decomposition (XYENC) and recomposition (XYDEC) of the
entire xywwweb.u2 library is about my first test case, and the
recomposition is a perfect match, for that entire body of work. And note
that xywwweb.u2 includes some code where 3 byte primitive functions and 3
byte data encodings are intentionally coded in erroneous (nonstandard)
ways -- ways that XyWrite will accept, but will not itself generate (with
many of these miscodings being critical to correct functioning of the XPL
code). All of this makes it through XYENC/XYDEC just fine.

I don't believe that U2's ENCODE program can match that. You'll have to
tell me how close the BasicXy you envision, in conjunction with by your
XyBasic encoder, would come.

>Think of XyBasic as a "front end" for composing XPL. I
>write all my XyWrite programs in the form of XyBasic, and
>then run XyComp.exe on it to translate or "decode" it to
>XPL.

I can appreciate that as a methodology for some programs, but certainly
not for all. For example, significant segments of many of my XPL programs
are generated by my keyboard macro recorder, when I am simply recording
some complex and extensive editing sequence that I'm doing, as I do that
sequence on sample data. I think that a development methodology must allow
for such "macro recorded" sequences to be glued into an XPL program being
written, and it seems to me that you can't do that in XyBasic without
having the "BasicXy" component available to turn such "recordings" into
"source." So, in my view, both of the programs in the "pair" are necessary
before you have even the beginnings of a real toolset.

Anyway, I'd appreciate answers to some of the above questions, so that I
have a little more appreciation for what XyBasic really can do.

Wally Bass