Re: XyBasic (re Robert's skepticism)

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Harry Binswanger  on Sun, 20 Nov 2005
23:59:19 -0500

Harry, I'm impressed by the lengths to which you've taken your XyBasic
translator. It's really quite elaborate now, and deeper than I knew (I hadn't
seen any actual code since the mid-90s). It manages some seriously complex
statements. And I certainly concur that it's nice to use words rather than
numbers; that's a very rebarbative aspect of XPL, offputting to many I'm sure
(and the impetus for frame NAME2NUMBER back in 1996: to convert code written
with words rather than numbers, but to keep the construction within the one
arena of XPL, and simultaneously teach the Save/Get-averse user how XPL works).

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

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), where's the HIDDEN
object? And putting aside the use of extended Save/Gets that gobble memory, or
of keystroke macros with saved temporary files when operations can be done
entirely in memory, of slow command line instructions instead of BlindExecute,
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

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

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?
Or are you trying to *remove* the tabs? (And what is "hidden" about a tab,
anyway? What does ")AY>" mean? Why all the func DBs when there is
no DeFined text to operate on? Also, "CLEARSGTS" will fail; it's CLEARSGT.)

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

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