[comp.lang.forth] POWERFUL SCRIPT PROCESSOR

ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/05/90)

 Date: 12-26-89 (21:06)              Number: 1501
   To: IAN GREEN                     Refer#: 1431
 From: DOJUN YOSHIKAMI                 Read: NO
 Subj: POWERFUL SCRIPT PROCESSOR     Status: PUBLIC MESSAGE

 Forth as a virtual machine........  not a bad idea, actually.  I
 currently have a special project which consists of writing an
 interpreter which uses the forth interpreter to traverse the syntax
 tree.  A couple things which may help:  with a little tweaking, the
 syntax tree that comes out of a parser can be modified such that it
 resembles the headerless dictionary.  Rather than being a syntax tree, I
 suppose we should call it a syntax DAG.  At any rate, once that is
 built, you can use the forth interpretr to directly execute the syntax
 tree.  Forth intrinsically lacks the nice memory heap utilities such as
 malloc and free (unles someone wrote them).  ALLOT and FORGET just
 aren't the same.  Thus I would forgo implementing the parser and scanner
 in forth.  The code generator and typechecker, however, could be put
 together nicely.  The inner interpretr is wonderful for traversing
 trees, the only trick you have to do is to make the contents of each
 node (or leaf) executable in some form.   It would not be bad practice
 to try writing your own forth interpreter to get some idea of how the
 innards work (or even look at Kelly and Spies's "Forth a Text and
 REference" particulary in the last chapters).  

 THe little project I have scratched to gether is on a UNIX box, so of
 course it is written in C.  C seems to buck every now and then,
 especially when squeezing pointers to functions all over the place.  I
 think what I am writing is some oddball flavour of subroutine-threaded
 code.  Perhaps token threading would be more appropriate: use one token
 table when traversing for type checking, use the other for execution. 
 (Even better, have a third token table for generating machine code).

 I would personally put forth as the back half of the analysis phase, and
 as the back end to the compiler.  Since I can't seem to find a nice
 whizz-bang parser generator/scanner generator in Forth (such as yacc or
 lex) I'd leave that part to some other language (for now).

 At any rate, what part of the compiler were you specifically thinking of
 targetting Forth for?

 D. YOshikami
-----
This message came from GEnie via willett through a semi-automated program.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'

ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/05/90)

 Date: 12-27-89 (14:30)              Number: 1507
   To: DOJUN YOSHIKAMI               Refer#: 1501
 From: IAN GREEN                       Read: NO
 Subj: POWERFUL SCRIPT PROCESSOR     Status: PUBLIC MESSAGE

    The ideas I am kicking call for a standard procedural language that 
 is compiled into a subset of Forth. To this end I am trying to gather up
 details about how Forths are themselves implemented. The compiler itself
 will be written in a procedural language (Modula-2) since I am most 
 familiar with the block structured style of programming techniques.
    You mentioned some things about parser generators like YACC. Alas I 
 have looked at PC versions of these programs and can find no 
 documentation whatsoever. They all refer to the Unix documenation.

 BTW today I bought a mouse so I will spend the next few days writing a 
 Module to support the rodent in my projects.

 NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886   
-----
This message came from GEnie via willett through a semi-automated program.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'