Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!SUN.COM!wmb
From: wmb@SUN.COM
Newsgroups: comp.lang.forth
Subject: Re: interactive control structures
Message-ID: <9001050440.AA25729@jade.berkeley.edu>
Date: 5 Jan 90 01:32:35 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Forth Interest Group International List <FIGI-L%SCFVM.bitnet@jade.berkeley.edu>
Organization: The Internet
Lines: 67

Antero Taivalsaari writes:
> my Fifth system never executes a word immediately (unless it is
> an immediate word), but it always keeps on compiling, until a
> special compilation ending word ... is encountered. Normally pressing
> the return key has the effect of the pipe word, too.

I experimented with this kind of a scheme several years ago, and it
had some nice properties and also some interesting side effects.

For instance, you end up needing to make HEX and DECIMAL immediate,
otherwise you couldn't write, for instance:

    HEX 1234

Instead you would have to use:

    HEX
    1234

Or:

    HEX | 1234


Of course, Forth really ought to have some way of explicitly declaring
the radix of an individual number.  At the last ANSI meeting, I proposed
that number syntax should allow the prefixes H# , D# , O# , and B# for
entering explicit hex, decimal, octal, and binary numbers, without
permanently altering the value of BASE .  Thus you could write
H#12a4 or D#5478 and get what you wanted regardless of the current BASE .
There was general agreement that this facility was worthwhile, but
there was some objection to making this a syntactic.  The consensus
was that I should amend the proposal to instead define Forth words
H# and D# , which would be followed by a space and the number.
We'll see how this amended proposal fares.

But, back to the discussion of the temporal aspects of interpretation
and compilation:  I see three possibilites:

1) The traditional Forth model:  A line of input is collected, then
   the words on that line are executed one-at-a-time

2) The "compile-a-line-model": A line of input is collected, compiled
   as a unit, and then executed.  (As in Antero Taivalsaari's system)

3) The LaForth model: The system reads a word from the input device,
   executes it, reads the next word, executes it, etc.

   (LaForth was a Forth variant written by LaFarr Stewart at about the
   same time as FIG Forth.  It has a number of interesting features.)

Analysis:

(3) appeals to me from an intellectual standpoint; the basic execution
unit of Forth is a word, so why should the unit of input be a line?

LaForth handled typos very nicely; since the system "wakes up" on every
space, if you mistype a word, the system doesn't abort; it just erases
the word (or part of it) and beeps at you; then you type it right.

On the other hand, this scheme takes a bit of getting used to;
"line-at-a-time" typing habits are pretty ingrained.  I discovered this
when I wrote the schematic editor macro language that I alluded to in
a previous message.  It used the LaForth "word-at-a-time" model, and
using it comfortably required unlearning some old habits.  It just felt
wierd to have things happen as soon as I typed a space.  The feedback
just seems a little too frequent.