Re: XyBasic

[wbass@xxxxxxxx]

Harry Binswanger wrote on Sun, 18 Jan 2009 17:36:10 -0800
>Wally Bass wrote on Sun, 18 Jan 2009 17:06:38 -0700

>>I did compile a couple of small cases to figure out if and
>>how you would handle them. Would you like a bug report? An
>>evaluation? Comments in general?

>Any or all. They might as well go the list (rather than
>being private).

Well, the exchanges in this series of are getting long, so let me just
summarize some observations by topic.

What I did is browse your spec (which I think is pretty good), looked at
the code generated for one of your examples, and then wrote about 10 lines
of code of my own where it wasn't obvious to me in advance what XyBasic
would generate for code. Mostly, verified that IN did as expected and I
was looking at the MID$ family.

XYBASIC BUGS

1. The LEN function, IN operator and the MID$ (and LEFT$ and RIGHT$)
functions don't seem to use a consistent unit of measure. The MID$ family
positions and counts off strings by executing and counting CR (Cursor
Right) operations for each count of a MID$ position/length arg, in a file
window context. But that really "counts off" 3 bytes for each MID$ "count"
of 1, for both 3 byte encoded data and 3 byte encoded functional
primitives.

LEN and IN, in contrast, work in terms of actual bytes. Using values
returned by LEN and IN to compute input counts to MID$ type operations is
therefore likely to be a disaster, when any 3 byte stuff is involved.

XYBASIC LANGUAGE FUNCTIONALITY

1. I couldn't find anything in XyBasic that gave me the the equivalent of
the XS XPL instruction, and I can't imagine surviving without XS. XS to me
was a key breakthrough in XyWrite's evolution, and particularly the
sophistication of XyWrite XPL programs.

2. So, I was looking at XyBasic's MID$ famility to see if they provided a
sufficient replacement for the XS functionality. The answer was a
resounding NO, in part because of the problem listed above in the BUGS
section. But worse yet (IMO) is the fact that EACH operation in the MID$
family is executed by doing FILE open/close level of operations, and then
doing the actual "extract" operation in a "temp file" "window." This
effectively makes the MID$ family of operations be things that occur at
I/O operation speeds and delays, when the programmer would be expecting
the operations to occur and CPU speeds and (virtually no) delay.

BASICXY/XYBASIC AS AN ENCODE/DECODE OR XYENC/XYDEC REPLACEMENT

1. Your claim, in your first post on this topic, was that XyBasic source
would be another solution to the "pure ASCII" requirements that U2 ENCODE
addresses itself at. That seems to me to just be plain false.

In you September 29, 2006 append to your spec, you are assigning keys
which jam 3 byte encoded "red pseudo-wildcard" stuff and the like directly
into XyBasic source strings. When that's required to represent a given
program, you are no longer talking about "pure ASCII." In your Sat, 17 Jan
2009 19:43:48 -0800 post, you also say "One can (and I do) drop XPL code
into the middle of the XyBasic code by
just enclosing the XPL part inside quotes." Again, if we're doing that, we
don't have something that is representing the associated aggregate program
"in pure (emailable) ASCII."

XYBASIC AS A BASIS FOR XYWWWEB.U2 CODE

Harry Binswanger wrote on Sat, 17 Jan 2009 19:43:48 -0800
>Wally Bass wrote on Sat, 17 Jan 2009 16:33:26 -0700

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

>I don't see why not.

1. I haven't read that much of the U2 code, but I don't think I've seen a
routine yet that didn't need and use XS extensively. You just don't have a
real replacement for that, at an acceptable performance level.

2. And, a significant amount of the XS code in U2, in my experience, is
code which is getting "inside" of three byte encodings, and "playing with"
the individual bytes of three byte encodings. Your MID$ family isn't able
to do that.

--------------------------------

Harry Binswanger wrote on Sat, 17 Jan 2009 19:43:48 -0800
>Wally Bass wrote on Sat, 17 Jan 2009 16:33:26 -0700

>>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 [BasicXy] is even possible?

>...

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

If we "put the really hairy stuff inside quote marks," and that "hairy
stuff" has 3 byte encoded content, then I would remind you that we haven't
converted to "pure ASCII" at all.

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

I've looked some at your XyBasic some amount. Please return the favor, and
look at the following three files in the XYENC094.ZIP distribution (at
basspad.com/xywrite/)

 ENCODE.PM  a program from XYWWWEB.U2
 ENCODE.ENC  an XYENC version of that same program.
        Generated "automatically" from the above,
        with a small amount of manual format tweaking
        in three places.
 QDF1.SRC   another program in XYENC format - actually
        generates the QDF1.PM XPL program.

and see if you think that the XYENC encodings there address any of the
problem that you speak about above.

Wally Bass