Re: dual-language systems increase modularity

[Tom Lord <address@hidden>]

    > From: Shriram Krishnamurthi <sk@cs.brown.edu>

Overall, you claimed existence of an important distinction between
"glue" languages and "extensive" languages.

I don't disagree that there's a distinction, but I don't think you've
identified the distinction as well as it can be identified.  For
example:


    > Whereas an extensive scripting language often needs to have a
    > very specific application-sensitive flow-of-control.


Emacs was one of your examples of an "extensive scripting language"
and I'm trying to think through this purported difference in language
design ("glue" vs. "extensive" languages) as it applies to
flow-of-control in Emacs Lisp.

So far I came up with two examples:

	1) Provisions for interruption:

           All primitives that take a long time in emacs lisp
           are "interruptable" without hosing state so
           badly that the process just has to quit.

           CATCH, THROW, and UNWIND-PROTECT are provided to extend
           that interruptability safely to user code.


	2) Provisions for interaction:

	   Mostly I'm thinking of SIT-FOR (which can 
           be used to, for example, ensure that the 
           display gets updated).   I recall there are
           some finer-grained polling functions, too.


Is there something else you had in mind?   Emacs-the-program _does_
have carefully controlled flow of control but Emacs-Lisp-the-language
seems pretty generic to me.

(For that matter, Tcl, a fairly classic glue language, has fairly
close to isomorphic flow-of-control provisions to Emacs lisp.   And
some successful versions of Emacs have had languages much closer to 
Tcl than lisp (teco emacs, Gosling Emacs).)

I've always thought of the defining characteristic of "glue"
languages, as distinguished from "extensive" languages, as one of
implementation strategies, not the aspects you mentioned: the primary
constraint of traditional "glue" languages is that they be easy to
implement in C or C-like environments (hence, only strings in sh, only
scalars and associative arrays in awk and (old) perl, etc.).

I think the distinctions you cited are emergent effects of the
glue-means-simple-implement-in-C definition -- not something more (or
less) principled than that in language design.

As just a question of historical development, it looks like (perl and
python being good examples) people start with simple-to-implement glue
languages, then want to use them as extensive languages.  That results
in rather rapidly evolving language designs and (in those two examples
especially) recent efforts to completely rebuild the language from
the ground up, abandoning "simple-to-implement" in favor of things
like fancy VMs and meta-circular implementation.   I like to make the
joke that Python is (as the name suggests) a humorous production:  the
punch line is that it eventually turns into MIT Scheme.

I'd cut the design space this way:

* one axis: higher-level language implementation requirements

  glue: "easy" in C (e.g., no GC)
  extensive: general purpose languages (e.g. Emacs Lisp)


* another axis: application (not language) architecture

  typically gluish applications:  traditional unixy "software
  tools" style -- filters, finite-state daemons, "tiny language"
  interpreters ....

  typically extensive applications: actually, emacs is the only really
  good example i've seen (i've heard rumours about some CAD programs,
  too.)  The Emacs architecture might be described as "A REPL, minus
  the "P", but connected to what is the moral equivalent of a
  live-updating structure browser, where the "R" in the REPL is driven
  by a keystroke engine that receives feedback from the structure
  browser (as in, "oh, you clicked on the structure called `scrollbar'
  -- let's treat that as a SCROLLBAR keystroke").

Both axes are continuous rather than discreet.   You can get things
like Gimp which aren't organized around the REPL principle but then
do have "call outs" to extension programs for various subsets of their
functionality, for example.


-t