Re: New XYENC 1/13/09 release

[Harry Binswanger hb@xxxxxxxx]

Wally wrote:



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

any documentation?


Yes, I'll send it to you privately.





>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.


Good point. I don't know quite how to answer that. I don't myself find
the 1% of the time that it doesn't work to be a problem--I just go into
the XPL and set things the way they should be. In using XyBasic, you're
not "trapped" in any way because it simply translates the
English-like text version to HBL, which you can then work with as you're
already doing. So you don't get into any bad situations. It's a
dispensable aid, not a replacement for anything.





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.


One can (and I do) drop XPL code into the middle of the XyBasic code by
just enclosing the XPL part inside quotes.





IMO, being able to mix that kind of content
within a "string" is a major

part of XPL is all about. 


If you're interested, send me a bit of such code and I'll see whether it
is any problem for XyBasic.



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.


You could well be right. I don't write Carl-level or Robert-level code. I
do write *very* long XPL programs in XyBasic, which I find to be much
easier to understand and maintain than regular XPL. For one thing, you
can format it using any amount of tabs and blank lines, and comments are
accepted after a semi-colon (Xy4 allows comments with *;* as you probably
know).



 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. 


It is basically a lot of find-and-replace functions. It takes Basic-like
English-text and translates it to XPL. XyComp.exe is written in the old
CBASIC language and compiled to a DOS .exe program.



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?


I'll send you the docs.





 2. Could everything that's in xywwweb.u2
be written in

    XyBasic? 


I don't see why not. But that's maybe my ignorance.



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?


Just plunk it in, surrounded by quotes. All the PFUNCs are automatically
translated to three-byters. E.g., the BC pfunc, FF 81 1F is written in
the "source" code as: 'bc (case-insensitive). Then when you run
XyComp.exe on it, it comes out in the XPL as it should.





 4. How does XyBasic deal with the
question of when function

    codes are mixed with data in
strings?


Can you give me an example?





 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 mean the numbering of the S/Gs?  XyBasic gives you a choice: if
you choose to declare the variable, which should be done at the top of
your "source" code, you assign it a number. DEFSTR for strings
DEFINT for integers--e.g.,



Defint MyVariable = 01

Defstr MyString = 24



That initializes them at the top of the produced XPL:







Or, if you don't want to assign a particular number, XyComp goes in order
from 01 to 02 etc. And, of course, the automatic numbering skips any
numbers assigned by DEFINT or DEFSTR.





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.


I can't speak to that. Thinking more about the idea of XPL to XyBasic
translation, the program would have to assign arbitrary variable names.
VARIABLE1, VARIABLE$24, etc. I suppose I could have it accept the inverse
of declarations, so that you could give the variables more informative
names:







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.


"They said it couldn't be done." You could be right, because I
don't know how intricate the XPL code is going to get. I've been using
XyBasic for about 20 years, but then I'm not doing the sophisticated kind
of things you're talking about. Still, I wonder if there's any real
problem here, given the ability to put in whatever hairy stuff you have
in mind inside quote marks.





 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.


I haven't done it only because: a) it would be rather hard; it took about
2 months of almost full-time work to do XyComp.exe, b) I'm the only
person in the known universe who uses XyBasic, and I don't really need
it.





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.


Let's see what you think when you read the 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.



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.


Point taken.





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.


I'm sending you the documentation privately. Give it a look. In fact,
I'll also send you XyComp.exe. Then you can throw at it whatever you
want.







Harry Binswanger
hb@xxxxxxxx