[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bytecode unification for scripting (and other!) languages




After an intensive workshop on Scheme and FP for high school teachers, I
have been catching up with my email and have been especially "amused" by
the discussion on scripting languages, etc. Fortunately, Shriram has
replaced me both in spirit and in energetic character, so I won't have to
say much :).

Shriram has boiled the discussion down to type systems for scripting.
That's mostly correct. What "amuses" me is the lack of knowledge about
history. When I flamed away in the 80s and early 90s at Schemers on cls, I
found the level of knowledge lacking, esp on the side of certain East
Coasters :). I eventually stopped posting because I couldn't handle their
lack of respect for the research literature. So here it goes. 

1. As Michael finally pointed out, types don't require typing
   (keyboarding). A programming environment can elaborate surface syntax to
   explicitly typed syntax for sufficiently interesting language and type
   language designs. 

2. Having said that, I believe that programmers should actually think about
   their types, in all situations. As Michael also points out, if you
   understand the types of your program well, you avoid many mistakes. Many
   errors manifest themselves in violations of data invariants, and that's
   what these simple proof systems called type systems are good at. 

3. Still, when I write one-line scripts, I don't want to write down types,
   because the typing of my program is so obvious that it just slows me
   down. Then again, some scripts contain some really hairy pieces of code,
   and perhaps I should write down types right there so that *I* the
   scripter can figure out what I mean. 

4. Because many scripts evolve into "real" programs, that means scripting
   languages need a (partial) type reconstructing environments.

5. The problem with ML's version of this idea is that it is too rigid. It
   is about a system of disjoint types (claims about value flow) and in our
   daily experience of script programming, we need more. We also need more
   because we tend to extend the data sets of programs over time, and ML
   won't let us do this without major editing. 

6. This reasoning led Cartwright, Fagan and myself to a discussion of soft
   typing -- in 1988. Over the following 13 years, Cartwright and I
   supervised three dissertations on this topic. I believe in working
   systems and we produced two distinct soft typers with different
   interfaces and different underlying mechanisms. If you don't know, take
   a look at PLT's publication site 

     http://www.cs.rice.edu/CS/PLT/Publications/

   Look for our PDLI 96 paper (lead author: Cormac Flanagan). Even
   flame-throwing theory eaters will be able to read this introductory
   paper. There is more there, and I am willing to report on my
   experiences, if there is interest, because I am by far the most diligent
   user of all these soft typing systems over the past 13 years. 

PLT is returning to this topic. Stay tuned. -- Matthias