Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!mips!decwrl!ucbvax!bloom-beacon!mitech.COM!gjc
From: gjc@mitech.COM
Newsgroups: comp.lang.scheme
Subject: extension languages can be darn small, yet still powerfull
Message-ID: <9008220403.AA03028@schizo>
Date: 22 Aug 90 02:25:36 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: gjc@mitech.com
Organization: The Internet
Lines: 105

Don't ever forget, Extension languages can be darned small and
still extremely powerful IF they are lisp (scheme).

Couple cases in point:
(1) PDP-10 MACLISP. A language so small many young folks today might
be ignorant enough to call it a joke. But what can be written in it?
 (a) MACSYMA, (b) SCHEME (pick your flavor), (c) FORTRAN COMPILERS,
 (d) LISP COMPILERS, (e) SCHEME COMPILERS, (f) FORTRAN RTL
 (g) PROLOG, (h) tons of highly original AI languages and implementations
(2) GNU EMACS LISP. Another real small one. No bignums, doesn't even
    have floating point numbers. No lexical scoping even.
    Shudder, no character objects! 
    (a) a darn good text editor
    (b) even a small symbolic algebra system, with bignums, floats,
        display formatters, parsers, differentiation, integration,
        and numerical analysis procedures.

On the other hand I agree 100% with the need for a standard Scheme
language that has enough stuff in it to be fun to use, modern looking,
and allow porting of various programs. And R^3.x doesn't have to be
big, I figure even SIOD would only need to triple in size with an
optional file to be linked in if you wanted the whole show.

Although, we have to be careful here! For one thing just the
machinery for recognizing and parsing the NUMBER SYNTAX alone
(not to mention printing it optimally) could very easily be
the size of the ENTIRE SIOD version 1.3 implementation!

And, if I was implementing something like Macsyma I would *not*
use the complex/rational and other number constructs provided
native in SCHEME R^3.x or COMMON LISP. Nice but no cigar, basically.
Just doesn't buy me much when I have to deal with extensions to
symbolic (datatypes) and other algebraic domains. Writing special
case code to utilize that functionality in special case is probably
not worth it, a lot of work to call what is probably inferior quality
code. I would probably rather write special case code to call into the
native FORTRAN runtime library, on a particular machine.

------------------------------
OK NOW: HOW TO KILL a language.
------------------------------

Change of pace. My humble observation on what properties of
implementation (driven or not driven by language specification requirements)
tend to hurt terribly the usability of a programming language in that
"larger world" we all have to deal with at some time.

(1) not being unable to take code in language X and compile it somehow into
    a subroutine library that can be called by a program in language
    Y, or Z.

(2) strict requirements on environment and placement in virtual memory
    of datastructures. i.e. lack of relocatability. (see 1 above).

(3) requirements of its own special toplevel loop.

(4) strange and/or undocumented data structures.

(5) restrictions with respect to native interrupt and condition handling.

(6) language constructs tied to special machine models, e.g.
    MEMORY/REGISTER, that might not work out so well in newer hardware
    implementations optimized for languages such as C.

These all lead to basically the same thing. Example: Most commercial
lisps have what they call (killer terminology) a "foreign" procedure
call interfaces. So big deal. If you write in language C then LISP
can call YOU, but:
 (1) don't expect for you to be able to call LISP outside of the
     LISP enviroment. The LISP is the master language here, all others
     bow down.
 (2) don't expect to use your standard C-debugger in the context
     of the lisp environment. only fully debugged C programs should
     be called from LISP!


I would point out that fully general CALL/CC is one of those
things that flies in the face even the extremely general
VAX/VMS model of runtime-language support.

Why? One reason is that CONDITION-HANDLING, the ability to undo side-effects
while unwinding the stack, and the ability to dynamically scope the
handling of machine and software generated exception cases, including
instruction emulation, is very important to the workings of things.

If you have a call sequence like:
  C->SCHEME->C->SCHEME->FORTRAN->PASCAL->SCHEME
  1    2     3    4       5        6       7
you are up shits creek if you think that you can return a fully
general lexical catch construct from level 7 back up to level 2
and then expect to re-enter the damn thing.

So a good way to KILL a language is to require the implementation
to be unworkable with respect to integration with the rest of
the known universe.

But ah, then there are all the dangers and politics of language
subsetting. The problem is that the dynamic-only CALL/CC language
will allow the inclusion of useful constructs which are too confusing/dangerous
to live in the standard environment of a language with full CALL/CC.

But wait, maybe we can get all the hardware manufacturers to change
the way they ... oops I forgot, we tried that one already.

-gjc