Re: XyBasic (re Robert's skepticism)

[Harry Binswanger hb@xxxxxxxx]

Robert wrote:
OTOH, it does seem to me that you're multiplying the erroneous zone by a
factor
of three: the Basic statements, the translator, and the XPL -- probably(?)
making it difficult to pinpoint where to debug when things go wrong.
I'll say. I usually plow through by putting in pauses with displays of
variables (I should have learned XRAY, but my one foray into it was a failure).
 I also
wonder how you code things that aren't comprehended by that old Basic, such as
InStrRev [the last occurrence of a substring within a string, e.g.
 InStrRev("abcdabcdabcd","a")
returns 9].
Offhand, I'd do a loop of INs for "a" and keep doing it until I got
minus-one, indicating that the next-to-last value (which I'd have to have
stored in a variable) was the right one. I hadn't known about InStrRev, so
I don't know when I'd have used it.
 I mean, its one thing to use a high-level language (Basic) to
generate a low-level language (zeros and ones), but to do it between two
high-level languages only exposes bugs. To each his own, of course. But...
I know. That's why I got Tim Baer's award for the best (or weirdest)
Xywrite-related program, if you remember that competition. But, in fact, I
almost never have problems with the translation itself, only with bad logic
in the pseudo-Basic source.
To me, it seems unnecessarily roundabout. The Methods, in the meaning of the
object-oriented language you seem to be constructing, are questionable, e.g.
the OUT.FIND.MAX.HIDDEN.TABS Method: where's the MAX object (as a distinct
object that you could apply anywhere in your Basic code),
I'm afraid you're talking over my head. Being frozen in the early 1980s, I
never caught on to object-language stuff. But in regard to the logic of
EXPAND.PGM, the thing I find in this kinda dumb way is the largest number
of "collapsed" and hidden tabs, which represents the number I must then
move the  out of. I guess you know that, though. But see
later on in this post, where I explain what EXPAND and COLLAPSE are for.
where's the HIDDEN object?
I'm probably talking again beneath you (not qua "object"), but the hidden
"object" is the largest number of hidden tabs at the start of any one line.
 And putting aside the use of extended Save/Gets that gobble memory,

mea culpa
 or of keystroke macros with saved temporary files
I rarely do that. I see that it is done in MID$, but I coded that before I
understood this issue, and I rarely use MID$. I use it *all* the time in
regular Basic, but maybe because XyWrite has the SEarch function, and
PARSE, I don't really find the need for it.
 when operations can be done
entirely in memory, of slow command line instructions instead of BlindExecute,
That must be the old code again (written before BX/Q2). I always use BX/Q2
in what I write (via COMX).
of this and that detail -- the *methods*, small m, are really very
prolix. For
example, for
 original$ = "abcdef"
 b$ = mid$(original$, 2, 3)
 'bc print b$
it's silly to do it in a window, moving the cursor around on actual text! You
can do it very pithily this way:

XPLeNCODE v2.0
b-gin [UNTITLED]
{<}SV01,abcdef{>}{<}SV02,2{>}{<}SV03,3{>};*;[cr|lf]{<}SX02,{<
}PV02{>}-1{>}{<}SV04,{027}X{>}{<}CUA,02{>}{<}XS01,04,,05,06{>
}{<}SX01,{<}IS06{>}{>}{<}LBA{>}{<}SV02,{>}{<}CUB,03{>}{<}XS01
,04,,05,06{>}{<}SX02,{<}IS02{>}+{<}IS05{>}{>}{<}SX01,{<}IS06{
>}{>}{<}LBB{>}{<}PR@02{>}{<}EX{>}[cr|lf][cr|lf]
-nd
XPLeNCODE

Aha. I see. In XyBasic that would be:

original$ = "abcdef"
start.match = 2
length.of.match = 3
any.char$ = "X" <=== the x in a red box
decr start.match ; move back to character before where start looking for match

for index = 1 to start.match
  parse original$, any.char$, head$, matched.char$, tail$
  original$ = tail$  ; actually this has become a truncated version of
original$
next index

result$ = ""  ; here you re-use the s/g used for start.match, saving a s/g.
for index =1 to length.of.match
  parse original$, any.char$, , matched.char$, tail$
  result$ = result$ + matched.char$
  original$ = tail$ ; now parse on only what's left
next index
prompt result$

That looks correct. If I had written it, I'd have to test it out several times.
Or if you wanted to pass all the variables at once, as
 original$ = "abcdef",2,3
you could do this (even briefer, and just four Save/Gets):

XPLeNCODE v2.0
b-gin [UNTITLED]
{<}SV01,abcdef,2,3{>}{<}SX02,{<}VA@01,1{>}{>}{<}SX03,{<}VA@01
,3{>}{>}{<}SX01,{<}VA@01,2{>}{>}{<}SX01,{<}PV01{>}-1{>};*;[cr
|lf]{<}SV04,{>}{<}CUA,01{>}{<}SX04,{<}IS04{>}+"{027}X"{>}{<}L
BA{>}{<}XS02,04,,04,01{>}{<}SV04,{>}{<}CUB,03{>}{<}SX04,{<}IS
04{>}+"{027}X"{>}{<}LBB{>}{<}XS01,04,,02,04{>}{<}PR@02{>}{<}E
X{>}[cr|lf]
-nd
XPLeNCODE

I'll take your word for it.
And I find very little "bliss", either in the code or in the contemplation of
doing it this way for 15 years, in the humongous EXPAND.BAS routine. I'm not
sure what you're trying to do with this, since you never actually say -- to
determine where the longest string of tabs appear in a file? Or how many tabs
constitutes the longest string in the file, up to max=9? Something like
that?
Manuel wanted a program to collapse and expand an outline. EXPAND.PGM and
its companion COLLAPSE.PGM, do that. It shifts around the --e.g, from:
 <==== hidden level of
outline

to:

{tab}{tab]3. One's life as the ultimate value .> <==== unhidden (expanded)
and, with COLLAPSE.PGM, back again. The challenge was that I couldn't use
wildcards, and do a simple Change Invisible, because Manuel wanted to have
maybe a page of text hide and unhide at a keystroke.
Or are you trying to *remove* the tabs? (And what is "hidden" about a tab,
anyway?

If it's inside an  it doesn't display.
 What does ")AY>" mean?
Er, um, it means I made a typo. I was supposed to use the keyword "OK" and
instead I used "OKAY" which left the "AY" hanging there. If I had used "OK"
it would have translated to:
)>
 Why all the func DBs when there is
no DeFined text to operate on?
I mentioned that I wanted the user to be able to expand or collapse only a
defined block within the outline, if he had DeFined one, but my code didn't
work, so I just left the attempt in but added an XD at the top.
 Also, "CLEARSGTS" will fail; it's CLEARSGT.)
That's not what I see in Xywwweb.inf. It says "ClearSgts" there. And here's
a paste from XYWWWEB.U2:
{{5DeclareSgts,DeclSgts,ClearSgts}}
You can answer the second question -- where are the most tabs? -- very simply:

XPLeNCODE v2.0
b-gin [UNTITLED]
[YD_][XD_][XP_][TF_][BX_]es 1[Q2_]{<}SX01,0{>}{<}LBA{>}[BX_]s
e/f [w9]{tab}[Q2_]{<}IF@NOT({<}ER{>}){>}[CR_][DF_][BX_]se [
w-]{tab}[Q2_][CL_][DF_]{<}SV02{>}[XD_]{<}SX02,{<}VA|02{>}{>}{
<}IF{<}PV02{>}>{<}PV01{>}{>}{<}SX01,{<}PV02{>}{>}{<}SX03,{<}C
P{>}-{<}PV02{>}{>}{<}EI{>}{<}GLA{>}{<}EI{>}{<}IF{<}PV01{>}>0{
>}[BX_]jmp {<}PV03{>}[Q2_]{<}EI{>}{<}EX{>}[cr|lf]
-nd
XPLeNCODE
Elegant. I see you used the "repeat n times" wildcard, set to 9. I haven't
ever used the repeat wildcard (I don't think it was in Xy III+). Then you
look for any string of tabs longer than your previous max. hand slapping head.>
You simply can't convince me that those 3 lines are more complex than
EXPAND.BAS, or that EXPAND.BAS with its 58 lines is somehow "friendlier".
Oh it's friendlier all right. At least to me. But I see that I got
confused: what I posted is not EXPAND.BAS and EXPAND.PGM but the longer
COLLAPSE.BAS and COLLAPSE.PGM. I mixed up the names.
Anyway, if we look at just the part you're talking about, and delete the
part about the user possibly having DeFined a block, all there is is:

sub cut.one.tab
 parse w.tabs$, 1tab$, head$, d$, tail$
 w.tabs$ = tail$
return
kiv$ = lft.g$ + "IV"
max.hidden.tabs = 9
1tab$ = "    "
w.tabs$ = "     " ; 9 tabs
find.max.hidden.tabs: ; find largest number of hidden tabs, from 9 down
 'tf comx "se /" kiv$ rt.g$ w.tabs$ "/" ; find string of tabs after cr.lf$
 if ok then goto out.find.max.hidden.tabs
 gosub cut.one.tab
 decr max.hidden.tabs
 goto find.max.hidden.tabs
out.find.max.hidden.tabs:
 Or that you're "gaining" anything by writing this in a
pseudo-language. On the
contrary. When you get into real complexity, your language, too, becomes very
dense, which strips away its primary appeal.
I guess "dense" depends on what you're used to. I don't find XyBasic dense
at all, but I do find XPL dense. Of course, I had done a ton of work in
Basic before I created XyBasic.

Thanks for giving this so much of your time and thought.


Harry Binswanger
hb@xxxxxxxx