Message-ID: <3B6EAEE2.84ACA9E4@csi.com>
Date: Mon, 06 Aug 2001 10:51:14 -0400
From: John Colagioia <JColagioia@csi.com>
Organization: No Conspiracy Here...
X-Mailer: Mozilla 4.77 [en] (Win98; U)
X-Accept-Language: en,fr,ru,es,it,ga,de,ja,gd,eu
MIME-Version: 1.0
Newsgroups: rec.arts.int-fiction
Subject: Re: Hardware z-machine?
References: <RjZ87.42028$SK6.5071866@news6-win.server.ntlworld.com>    <spZ87.42060$SK6.5078952@news6-win.server.ntlworld.com>    <Knf97.3527$WD1.226504@e420r-atl2.usenetserver.com>    <328b5b3b.0107302035.5c84bf60@posting.google.com>    <dvB97.53133$UH6.9096587@news02.optonline.net> <5hj8k9.m8s.ln@127.0.0.1> <Wu_97.67633$UH6.11223098@news02.optonline.net> <3b6bde57_2@excalibur.gbmtech.net> <XYVa7.22449$uj2.3806588@news02.optonline.net> <3b6d3af1_1@excalibur.gbmtech.net> <Mkdb7.30844$uj2.5515219@news02.optonline.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 208.34.37.104
X-Original-NNTP-Posting-Host: 208.34.37.104
X-Trace: excalibur.gbmtech.net 997108996 208.34.37.104 (6 Aug 2001 10:43:16 EST)
Lines: 200
X-Authenticated-User: jnc
X-Original-NNTP-Posting-Host: 127.0.0.1
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!howland.erols.net!portc.blue.aol.com.MISMATCH!portc01.blue.aol.com!uunet!dca.uu.net!ash.uu.net!excalibur.gbmtech.net
Xref: news.duke.edu rec.arts.int-fiction:90722

Larry Smith wrote:

> "John Colagioia" <JColagioia@csi.com> wrote in message
> news:3b6d3af1_1@excalibur.gbmtech.net...
> > >Yes, you can. APL can definitely do string manipulation.
> > Oh, well, that would presumably make parsing even easier.
> String manipulation isn't usually too hard (OK, regular expressions are a
> quantum leap up).

Well, unless you're doing "rewriting regular expressions" (which no language, as
yet, does, as far as I can tell), that's not really string manipulation,
technically.  Though the string manip people like to think it is...


> But parsing is a whole different issue. There's actually a
> large body of formal computer science (as opposed to mere programming) on
> parsing. And string manipulation is the least of it. It's overkill for
> relatively simple things like an IF game, but if you're interested in the
> topic in general, try searching for, oh, YACC, Lex, Bison, Flex, Antlr,
> LR(k), LALR(k). That should get you started.

Oh, I'm sorry.  I never introduced myself "formally."  In addition to fiddling
around with Inform and playing IF, I'm also the Programming Languages and
Compilers (and Client/Server, and Operating Systems) instructor (well, adjunct
only--I'm a "normal" programmer during the day) at my local university.  And
I've written a dozen or so "toy" compilers and interpreters (as well as one or
two "production" items that nobody will be likely to encounter).  So, yeah.  I
know a little bit about parsing in the general sense.  I just haven't tried it
in APL.


> > >And I thought of
> > >this when I wrote my original statement that APL wouldn't be that handy for
>
> > >IF. But what I also realized is that most string manipulation is done in
> the
> > >library routines (especially the parser), and that once these were written,
>
> > >the main work would be done. I don't think that most IF authors do a whole
> > >lot of complex string manipulation in their games.
> > Oh, I didn't mean, "APL can manipulate strings, ergo it can do IF easily."
> > Rather, I meant that the major stumbling block--parsing--is reasonably
> > surmountable.  Decent IF could presumably be written, and lots of the
> > niftier APL bits would go unused, but the parts that worked should lend
> > themselves rather well.
> Actually, the part of APL that I'd find most useful in this context is
> dynamic storage allocation, garbage collection and recursion.

Careful...Allocation and GC are part of the "standard environment," rather than
the language.  C would be the same language with garbage collection, for
example.  It's just that the run-time would be more complex.


> Blithely
> skipping over what I said above that parsing is (or at least, can be) a very
> sophisticated process, imagine doing the following: Take in a string.
> Tokenize it, so that you wind up with a vector of strings, one for each word
> (and possibly punctuation) in the sentence to be analyzed. Then delete all
> the noise words ("the", "a", etc), just for simplicity. Then break things up
> into a Verb string (probably just one word, say "Open"), an Object string
> (e.g. "door"), a prepositional clause ("under the red idol") and another
> prepositional clause ("with the golden key"). You could then attack each of
> these in turn, perhaps recursively. The point here is that having the
> freedom to allocate chunks of data, dynamically resize them, but not have to
> worry (much) about running out of space, are what can make things like
> parsing (and many other things) much easier. But if you don't have such
> facilities, you're often doomed to try to do everything "in place", and futz
> around with trying to juggle the gory details yourself.

Mmmm...Depends.  Recursive-descent parsing isn't too bad, even without recursion
(I've done it in BASIC, in case you were wondering--I needed a C compiler on an
8080 machine, and didn't have an 8080 reference on me when I started).

I haven't done NLP, but then I don't think normal parsing quite works for
natural language unless you limit the grammar somehow (as the Inform library
does, by assuming the first word to be a verb, for example).


> I'm pretty sure someone's written dynamic storage allocation routines for
> Inform (remember Inform? This is a newsgroup about Inform et al).

No, no.  This is a "writing IF" newsgroup, language-independant.  We're talking
about (purely hypothetically, I'll grant you) attempting to write IF in APL,
therefore it's quite on-topic, if weird.

If you're uncomfortable carrying this on here, though, I'd be happy to continue
this in personal e-mail, since we do appear to be the only ones out on this end
of the thread.


> > For example, one problem that's a horror to code (for me, anyway) is "is
> > Object-X within N rooms of Object-Y."  My Inform code for this is always
> > nightmarish, trying all exits and fumbling with whether the exit is a
> > string, routine, or room, and trying to actually extract the room from the
> > routine without printing a string (almost doomed to failure if the result is
>
> > random and you don't rewrite), and so on.  It seems that, if one could
> > cleverly build the rooms into a matrix, this would be pretty darn easy to
> > do.
> Well, here's an idea off the top of my head, involving recursion (I'll
> assume your IF language of choice supports it). Start with your current
> room. Go through all the doors,

See, there's the failure-point in the algorithm.  Doors don't necessarily lead
directly into a room.  Most of mine, in fact, either print specialized "You
can't go that way" strings or are routines that print commentary and return the
value (little messages to support the feeling of movement, basically).  In
special cases, I don't even return a deterministic value, which makes this a
little more complex.

Starting to see the problem...?


> calling yourself recursively for each,
> incrementing a "distance" parameter each time. If the counter becomes too
> large (e.g. the room is more than, say, 4 rooms away), then return. Else
> process the room (e.g. drop shrapnel from the bomb that just exploded
> several rooms away, or perhaps add it to a static vector of nearby rooms, if
> you need to have an explicit list for later), and recurse again. You'll want
> to set a flag in each room to say it's been processed, so that you don't
> deduce incorrectly that Room A is two rooms away from itself because you've
> found the path A->B->A! (And don't forget to clear the flag for *all* rooms
> each time before you start the scan!)

Yep.  Ignoring my "special needs" above, a depth-first search (or...actually,
this might be breadth-first, depending on the exact implementation) would work
fine.

However, even "finer" would be "take this matrix and give me the matrix N
elements in any direction from the given index.  My more complicated problems
could be fairly easily resolved by increasing the dimensionality of the matrix.

[...]

> Some might argue that it's grotesque, but an early use of APL was to
> formally describe the architecture of the then-new IBM System/360 mainframe
> computers.

Let's see...using a linear algebra notation to describe hardware that operates
on arrays of bits.  Maybe I'm just perverse, too, but that sounds fairly
straightforward to me.  Again, lots of APL would probably go unused, but...


> I'm not sure if the article is online (you might try IBM's site),
> but you can try to find "Falkoff, A.D., K.E. Iverson, and E.H. Sussenguth, A
> Formal Description of System/360, IBM Systems Journal, Volume 3, Number 3,
> 1964, Table 1, page 200-201." It's in Iverson notation (from the original
> 1962 book,  not the transliteration used in the subsequent implementation).

Hm.  I can't find a copy, but I think I might just know someone who would have
one...


> For the terminally curious, you can also check out
> http://cseng.aw.com/book/toc/0%2C3830%2C0201105578%2C00.html, which uses APL
> (not Iverson notation) to also describe aspects of machine architecture.

You know, had I known about this book at the time, I might have taken the school
up on its offer and taught their architecture course.  It looks much better than
the book they were planning to saddle me with...

Well, off to see who'll sell it to me cheaply...

Great.  And I was planning on doing productive things with my day, too.  Thanks,
Larry...


> BTW, IBM's program was *not* called "APL/360", but actually "APL\360". I
> assume you know enough APL to be able to read the latter as "APL Expands
> 360". Yep, it's a pun.

Ah.  I always wondered about that.


> > >> However, it occurs to me that, with dynamically-calculated jump
> statements
> > >> (for "message dispatching"), about all I can't see is a pointer type to
> > >> simulate objects.  But, then, that's not the point of the exercise...
> > >I agree that APL doesn't have objects. Could I kludge up pointers? Yeah,
> > >maybe. Many interpreted languages have an "eval" function, that takes a
> > >character string in their language, and parses and executes it. APL's
> > >function is called "execute". If I were absolutely desperate, I suppose I
> > >could pass in, not a pointer, but a string with the name of a variable. If
> > >you typed in (with suitable transliteration) <foo = execute("goo")>, then
> > >foo would have the value of goo, and would give you a kind of indirection
> > >effect that pointers provide.
> > Hm.  OK.  You win.  You're sicker than I am...that's not something I would
> > have thought of...
> Sicker than you are? I'll take that as a compliment! ;-)

Well, I meant it that way.  I'm the one with aspirations of writing textbooks on
Befunge and INTERCAL, after all...


> But I admit I've
> been at it for many years. What was that slogan? "Practice makes imperfect"?

Heh.  Works for me!


