🚀 go-pugleaf

In article <3526@csd4.milw.wisc.edu> markh@csd4.milw.wisc.edu (Mark William Hopkins) writes:

   Path: opus!lanl!hc!ames!mailrus!csd4.milw.wisc.edu!markh
   From: markh@csd4.milw.wisc.edu (Mark William Hopkins)
   Newsgroups: comp.lang.prolog
   Keywords: forth, forlog, foobar
   Date: 25 Jul 89 23:43:20 GMT
   References: <12746@well.UUCP>
   Sender: news@csd4.milw.wisc.edu
   Reply-To: markh@csd4.milw.wisc.edu (Mark William Hopkins)
   Organization: University of Wisconsin-Milwaukee
   Lines: 29

	... about writing a forth in prolog

   Yes it could!  Here's an outline:

   (1) Set up a LR(1) parser generator in Prolog.
   (2) Create a YACC-like front end, using Prolog's existing grammar
       notation and your parser generator.
   (3) Write a Forth compiler using the YACC-like parser generator (choose
       your favorite target language for efficiency)
   (4) Use the compiler to compile the said Forth program into the target
       language
   and
   (5) Run the executable code.

	... more drivel.

this posting demonstrates lamentable ignorance of both prolog and
forth.  in particular,

1) lr(1) parser generators don't have much more power than the
currently ubiquitous dcg systems.  the only real disadvantage of lr(1)
is the ability to use left-recursion.

2) forth doesn't even have a real parser or compiler, just a tokenizer
that directly dispatches to the definition of each word.  the
compilation is generally done by directly threading code, but
occasionally an compiler word actually does something very minor like
depositing the address of a literal handler into the code stream.

3) simulating forth which a list for the stack is going to abominably
slow.  we are talking 2 or more orders of magnitude disadvantage.



i don't want to discourage posters in general, but please check with
the real world before you post.
--
ted@nmsu.edu

This is the most beatiful place in the world.
					Edward Abbey, Desert Solitaire