Re: Threaded Interpretive Languages

"Julian V. Noble" <jvn@fermi.clas.virginia.edu> writes:


      The prototypical TIL is FORTH.
      [... a great deal more about Forth...]


My Master's thesis was an integrated Forth environment with a
"Smalltalk-like" code browser, tree-structured dictionary, incremental
compilation, debugger, etc... Basically made a tight edit-compile-debug
cycle even tighter. I compiled to "subroutine-threaded" code instead of
threaded interpretive; twice as big code size but runs twice as fast. My
compiler also did *some* peephole optimization. It was used to write a
Postscript clone (a large software project). Here are my pro & cons.


Pros:
      Very fast edit/compile/debug cycle: basically you could edit & run, no
      matter what or how much you changed - the incremental compiler was invoked
      automatically, and was too fast to see. Even for 350K lines of code.


      Mini-languages: you can easily (trivially?) write mini-parsers to handle
      repeated-but-mildly-different problems. We used this to write mini-
      languagues for specifying Postscript operator function types.


      You can debug subroutines as stand-alones: after defining a routine, you
      can immediately invoke it with some parameters. Really nice for testing
      stuff piece-meal. Of course, modern debuggers can do this as well, but
      you gotta compile/link/load-debugger before you can test this way.


Cons:
      Stack programming can be gotton used to, but it's not as fast or as
      natural (especially for scientific formulas) as infix.


      NO STATIC TYPE-CHECKING. This sucks on large projects, where the
      compiler's type-checking is your friend. Many stupid bugs can be
      caught by the compiler, that instead you have to sweat out (with the
      nice debugger). No dynamic type-checking. But then neither C nor
      Fortran do either.


      Lousy code quality: symptomatic of fast incremental compilation. Small
      scientific kernels can have amazing transformations done to them to get
      speed out of modern micros (software pipelining, blocking for cache, etc).
      But just your plan vanilla constant-propagation, dead-code-elimination,
      strength-reduction stuff are not commonly available (duck&cover: I have
      heard of standalone Forth compilers that do this stuff).


      Inconvenient structured variables, object-oriented stuff, local variables.
      All these can be cobbled into the language, but the "syntactic sugar" is
      missing. Structures and objects are a darned sight easier in C++ and
      Smalltalk.


      How do you do source-code-control reasonably well?
      (How do the Smalltalk folks do it?)


Summary:
      Still nice for embedded systems work, or the lone hacker.
      Avoid for large projects, unless you already got a bunch of Forth'ers.


      If I was to do my thesis again, I'd have:
          a statically typed language (with an ML style type-checker),
          objects,
          revision control built-in,
          integrated with what was already there:
          edit, compile, link, debug, make, help, libraries.
--
cliffc@cs.rice.edu -- Massively Scalar Compiler Group, Rice University
--

Return to the comp.compilers page.
Search the comp.compilers archives again.