[comp.lang.forth] Purity of essence

wmb@MITCH.ENG.SUN.COM (07/31/90)

> You really have to see [ a line editor ] done right before condeming them
> outright.  ... if you are counting keystrokes you can't beat them.  Just
> think about it the next time you are moving the cursor down to the bottom
> of the screen in your favorite screen editor.  Count how many times the
> arrow key repeats and compare that to the job of typing F followed by the
> string you moved the cursor to, or T to the line number.

Apparently the author has never seen a screen editor done right.  In my
favorite screen editor (EMACS), one can move to the bottom of the screen
in 2 keystrokes.  "Find a particular string" takes 1 keystroke, plus you
don't have to think about how much of the string you need to type to make
it unique; just start typing the search string and the editor starts to
search for matches on whatever partial string you have typed so far.  Stop
when the cursor is on the right one.

> I would say that poor editors have contributed to the bad
> rap the block files have gotten

True only if you accept the proposition that it is the editor's job to
paper-over the deficiencies of BLOCKs.  Even a super-duper editor won't
correct the major deficiency of BLOCKs, which is that they make Forth into
an island in itself, preventing easy interoperability with all the
thousands of file-based programs available outside of the Forth world.

> I.e.  HEX 0315 VOCABULARY ASSEMBLER DECIMAL
>
> defines the assembler vocabulary that searches thread 5 (assembler
> definitions), then thread 1 (forth defs) and finally 3 (editor).
> The threads are not specifically defined ...

Yow!  What a user interface.


> In other words, VOCABULARY does not define
> new threads, but search orders into the existing threads.

Now perhaps people will begin to see why the word VOCABULARY had to
be renamed to WORDSET for ANS Forth.


> In 16 bit polyFORTH, you typically can have 8 threads (only odd 4
> bit numbers are used), but I've rarely had need for more.

This may be a case of the tool influencing the programming style.

In developing an implementation strategy, one learns to quickly
discard possibilities that are not well supported by the language
implementation at hand.

Forth vocabularies have the potential to be an extraordinarily powerful
tool, but this potential is not realized in most systems, because the
vocabulary mechanism has not been generalized.  In its general form, a
vocabulary is a mapping between strings and actions; a sort of "super
symbol table" or "associative memory".  Unfortunately, there are important
omissions from most Forth standards in this area:
	a) No standard way to programmatically enumerate the words in
	   a vocabulary (i.e. the primitives you need to build VLIST
	   or WORDS)
	b) No standard way to save and restore the search order.
	c) No standard way to selectively remove a single word from a
	   vocabulary.
	d) No standard way to search just one vocabulary.

Mitch

dwp@willett.UUCP (Doug Philips) (08/02/90)

In <9007310619.AA15045@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM writes:

> True only if you accept the proposition that it is the editor's job to
> paper-over the deficiencies of BLOCKs.  Even a super-duper editor won't
> correct the major deficiency of BLOCKs, which is that they make Forth into
> an island in itself, preventing easy interoperability with all the
> thousands of file-based programs available outside of the Forth world.

This leads me to a side point.  Which is more fundamental?  That is
which is more appropriately "built from" the other?

	A sequence of 1024 byte blocks, or
	A stream of bytes.
	
Conceptually, the stream of bytes seems more fundamental because it is more
general.  Practically, blocks seem better matched to the underlying media.
Of course, that is only an ephemeral match that will last so long as the
media technologies are like they are now.

>                                         Unfortunately, there are important
> omissions from most Forth standards in this area [Vocabularies]:
> 	a) No standard way to programmatically enumerate the words in
> 	   a vocabulary (i.e. the primitives you need to build VLIST
> 	   or WORDS)
> 	b) No standard way to save and restore the search order.
> 	c) No standard way to selectively remove a single word from a
> 	   vocabulary.
> 	d) No standard way to search just one vocabulary.

I'm curious if anyone knows of a system that does these things?  Would
it still be Forth as we know it?  Are vocabularies *really* part of
Forth, or something that is added on on top of it?  Not dictionaries,
vocabularies.

-Doug

---
Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp
Daily: ...!{uunet,nfsun}!willett!dwp   [in a pinch: dwp@vega.fac.cs.cmu.edu]