Re: XyBasic

[Harry Binswanger hb@xxxxxxxx]

Wally:

Thanks for the feedback. If I follow you correctly, you have three objections:

1. MID$-type facility is inadequate. Yep.
2. Doesn't encode to pure ASCII. Yep.
3. XS not included. No, it is included.

The two actual issues can be fixed (see below). Anything else?

--Harry


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

As I recall, the MID$ family is the one set that is rather poor and
unreliable. I should instead have XyBasic call U2's string parsing
functions (which didn't exist in 1990 when I wrote XyBasic).


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

Yes, that's a failure. Again, I wouldn't use the MID$ type functions. I
should substitute the U2 frames automatically, but it's a little difficult
for me to revise XyComp.exe because to do so I need to use a FAT 16 file
structure. I can do that by going back and forth between my Mac and my
Windows machine, but it's a pain in the neck.

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

 From XyBasic.txt:
"PARSE = XS   (e.g.: PARSE a$,b$,c$,d$,e$)"

You can also use just XS: e.g., XS a$,b$,c$,d$,e$


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

Again, I agree that MID$ is kludgey, and I myself don't use that.


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

Do you mean because one has to use non-ASCII for stuff (other than PFUNCs)
that you have to put inside quotes? Wouldn't it be simple to add an
ENCODE/DECODE to cover them to ASCII? Or do you think this would be so
frequent as to defeat using XyBasic for that purpose? I didn't write
XyBasic as a way of ensuring pure ASCII, but as a way of writing readable
source code with informative variable names (e.g., "AmountPaid" and
"FirstName$" rather than 01 and 02).


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

Point taken. But I could pretty easily, I *think*, add a facility to make
the red CR-LF something like [FF][C0][9B].


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

XS (or PARSE) *is* XS. XyComp.exe simply replaces either XS or PARSE with
the regular XPL syntax.


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

Right, but a call to U2 (or a rewrite of MID$ type code) could 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/)

Okay, I've downloaded the ZIP file. Will look them over anon.


>  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


Harry Binswanger
hb@alum.mit.edu