Re: Xy III & Faulty Memory?

["..." yesss@xxxxxxxx]

≪ Use backward, not forward, references--that's a no-no
with interpreted languages [...] When I say "interpreted",
I simply mean as opposed to "compiled". In the 80s, the
"no forward reference" rule was often mentioned (especially
in connection with "structured programming" as opposed to
spaghetti code) ≫

I guess things like are what gave rise to the school that
holds that knowing BASIC disqualifies one from ever being a
good C programmer. Proponents would recoil in horror at xpl.

≪ in almost all cases, even if my method appears prolix, it
_will_ be faster; indeed, I can't think of any method which
is slower than using LaBels in code architecture!) Nested
"IF ...ENDIF"s and SUbs--separately introduced into Xy3 at
different stages of its evolution--made structured
programming more possible (in recent years, I've tried to
avoid LaBels altogether, and just use nested conditionals
wherever possible). There were, as I recall, two empirical
proofs. And there are really two issues here, not always
easy to separate. One is speed of execution, the other is
memory consumption. ≫

An xpl if/else statement we'll never see would eliminate
the prob in the example we were discussing. Of course nested
conditionals are a giant step forward--no help, however,
to v3 programmers and difficult to follow even in xyW4 code
without the formatting conventions that clarify program flow
in other languages. Penalizing the use of white space may
be xpl's most self-defeating flaw. I did devise procedures
for v3 xpl pseudo while, do/while, and for loops (documented
in !xyWise programming notes), but the learning curve is steep.

≪ When I ran Xy3 on a DOS machine, [...] a DOS utility
called MEMWALK [...] showed _two_ copies of any program
in memory. One copy was the whole program, as written; the
other was a tokenized version of the code that had executed,
up to the point of termination (including pointers to
current values of Save/Gets, etc). You could branch out
of a program in the midst of it, shell to DOS, and call
MEMWALK to examine the (currently suspended) memory state
of the of the parent program. I learned an amazing amount
about how XyWrite worked from MEMWALK, e.g. the codes written
to the screen--but invisible--that triggered various on-screen
video modes like BO or UL (all 6-bytes long, & beginning
with Ascii-252). ≫

Yeah, that's how programs work, with code and data both
in memory. It must be fascinating to be able to peek
anytime during a run at what's going on. I gotta ask:
Do you remember where MEMWALK came from? Sounds like
a Byte or Z-D giveaway.

≪ And I played a lot with disassemblers, as a learning
tool. ≫

I used to be tempted, never really got close.

≪ [...] What can we conclude [from a test with Carl's
Iterate]? [...I]n jumping from LBA to LBB, the program does
not waste time reading unnecessary LaBels C through Z.
Jumping from LBA to LBM or to LBZ simply extends the time by
the precisely predictable amount that it takes to read
additional LaBels. Second, when we compare the last two
tests, we see proof that in jumping from LBA to LBZ and then
to LBB _or_ LBY, EDITOR goes back to the _top_ of the code
block a second time and reads all the bloody LaBels from the
very beginning to the end again, until it hits LBB or LBY.
≫

That test was very illuminating--and discouraging to me
since I use short explanatory labels (without GLs), and
EDITOR must dutifully examine each more often than I want
to know. Luckily for me, however, I don't place the high
value you do on shedding every possible xpl nanosecond.
In v3, the priority usually must be optimizing memory.
I just code as tightly as I can, impose as much structure
as xpl allows (using runtime function libraries, etc, just
like bigtime languages), and trust EDITOR and a Pentium
122 CPU to put an end to it as quickly as possible.

≪ A compiled or tokenized program would simply make
the jump, near or far, to a pre-compiled location in
memory. XPL does not do that. This is the behavior of
an interpreted language. ≫

Compiled with BASIC? Sophisticated compiled and (actual)
interpreted languages--e.g., Java and PostScript--don't use
labels. Clean conditionals and libraries of functions written
to memory at runtime eliminate the need. You may have one
such runtime library, in ascii, in your xyW directory; look
at a PS driver's fb<: that's it (more readable if you load
the driver and tyf but comprehensible only if you know some
PS). C and C++ do in fact have a goto statement; if you
searched 500,000 examples of source code you'd be unlikely
to find it once. It can be but *never* is used to eject
from deeply nested loops. That probably applies too to
Pascal and Delphi. BASIC and script languages use labels.

≪ All of which is to say, that what appears "economical"
in terms of language may in fact be terribly costly in terms
of parsing and execution. People who like to use lower case
in things like  may simply be wasting processor time
because EDITOR has to convert it to upper case. ≫

That's one tax I'm more than willing to pay. Tests since
time immemorial have shown consistently that caps are much
harder to grasp than c/lc. If that weren't true you can be
sure you'd see capped heds on every page of tabloids where
you see them only in three- or four-word page 1 heds. xpl
is tough enough to follow without forcing programmers
to read it as caps. When I found that xyW4 stores xpl code
as caps I wrote a kbd macro that on opening a file lc's
code so I can read it.

≪ People who think ==0> is tidier than
<1> may not realize that it is far easier for an
interpreter to reach greater-than or less-than decisions
than to resolve equivalence, which always raises questions
for a computer about degrees of precision (there is no
such thing as absolute equivalence for computers). ≫

That's reasonable. I aim for {if{pv01}<1} and {if{pv01}>0}
tests simply because they're a char shorter. ... Ciao. 	--a

======================================= adpFisher  nyc
http://www.escape.com/%7Eyesss/_xypro.html ===========================