> Eugene's statement was that Forth and Scheme both "[let] you define
> application languages". Perl does as well, IMHO; for instance, the
More than just "define application language" -- offer efficient
tools to create steep abstraction gradients -- especially by allowing
to routinely modify parser/compiler. Noise (Forth primitives) tends to
disappear from well written word definitions very quickly as you
scroll down the source.
You can't do this in any other language other than Forth/Lisp
derivates because both the mechanisms are not there and the complexity
of the parser/compiler makes just modifications prohibitively
difficult. I thought Perl was written in compiled C and not mostly in
itself.
> standard Mailtools package provides, in effect, an embedded little
> language for manipulating email messages (reading them in, tweaking
> headers, sending them off), which allows you to write, say, a
> rough-and-ready autoresponder script in about a dozen lines of code:
Very nice, but I'd like to see the implementation of that particular
application language.
For the record, I don't think Forth is particularly viable outside of
dedicated hardware ( http://www.cs.cmu.edu/~koopman/stack.html ). Of
course, if one wants to go wafer-scale integration with recent
embedded RAM processes, one would want to reduce grain size as much as
possible to increase the good die yield on the wafer. Compact code
(threaded code) and a small-footprint OS are crucial there. So Forth
might have its day yet.
I'm not sure how compact a Scheme evaluator can become, but I doubt
that much can be done with Lisp in under 128 kByte grains.