[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