🚀 go-pugleaf

In article <ROCKWELL.94Oct27194455@nova.umd.edu>,
Raul Deluth Miller <rockwell@nova.umd.edu> wrote:
>I merely wish to point out that some of these criticisms are unjust,
>and, to put it bluntly, flame bait.

Hm.  That went well.  8-(  Lets see if I can do better this time.

Raul has a point... my commentary came out much harsher than intended.
Lance, I hope you weren't offended.  It was not intended as flame or bait.
These are my opinions, not absolute facts, and do not reflect, etc, etc.

For context, I began using forth in the late 70s.  It and its variants (such
as stoic) do indeed make useful glue languages... but for internal projects.
Forth is a very good tool-building language.  Too good.  I would be reluctant
to give access to the core forth language to an end-user.  It's too easy to
crash existing implementations, and too hard to figure out why.  Writing a
more rugged extension language in it would make more sense, but the end-user
wouldn't "see" the forth core and the safer extensions would be slower.

The languages that I had most fun using have been forth, icon, and lisp...

>John Lundin:
>.   It is also less suited for large projects than TCL, and for all of
>.   the same reasons.  (Forth enthusiasts: please flame by email.)
>Not the same reasons -- for example, TCL is typically about 100-200
>times slower than Forth.  TCL spends a lot of the time doing symbol...

We can argue the speed business offline if you like.  It's true enough.
Large projects being slow is a familiar complaint about forth interpreters.
The same was true of lisp, maybe more so.  I would expect to hear it of tcl.
Remedies can be implemented.  My feeling is that lisp has more remedies now.

I'm curious about your 100-200 times figure.  What were your benchmarks?  My
experience has been that once you start doing similar glue-type things, the
string handling and calls mask out a lot of language speed differences.

Tell you what.  Most dictionaries are linked lists of pointers to words.  Why
not go one step further and use "link threading" so that each word pointer is
followed by a link to the next word pointer in order?  This at most doubles
your dictionary size, but you can reclaim some if you use a secondary space
for your string area and keep separate headers, as some other forths do.  The
linking adds some inner interpreter overhead, say, about as much as token
threading, and gives you even more flexibility in rearranging the dictionary.
What you wind up with looks a lot like a primitive lisp interpreter.  (grin)

The design goal, as stated, calls for something that you can implement lisp
and tcl in efficiently.  Thanks to language similarity and rush, this is true
of scheme.  I have seen (and written) lisp interpreters in forth, but they
were slow and I have not seen any equivalent compiler projects.  Yet.

>. - It has a much smaller user base.  The language is less publicised
>Smaller than what?  How measured?

(blink) I assumed this was obvious.  Smaller than lisp's.  Emacs alone should
take care of that.  Most CS departments teach some lisp, but forth?  Compare
sales of books, amount of code, available software using the language, etc.

>>...Have you seen a good, fast, free, portable and C-based forth? ...
>Try Will Baden's "ThisForth" ... no GUI yet...  it wouldn't be hard to add
>TK.  [And there are plenty of forths with GUIs -- I won't bore you...]

I will.  And please bore me with that list.  Email preferred.

>None of which is an endorsement for Forth as an extension language --

Really?  I'd endorse it as "an" extension language.       -john

John Lundin Jr  lundin@urvax.urich.edu   "A pentagram approaches a circle for
U of Richmond   lundin@boojum.urich.edu   sufficiently large values of five."