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

[Matthias Felleisen <matthias@ccs.neu.edu>]

  > From: "Shriram Krishnamurthi" <sk@cs.brown.edu>
  > Date: Wed, 15 Aug 2001 23:37:45 -0400
  > Content-Type: text/plain;
  > 	charset="iso-8859-1"
  > X-Priority: 3 (Normal)
  > X-MSMail-Priority: Normal
  > Importance: Normal
  > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
  > 
  > > 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.
  > 
  > I disagree with the implication of this.  The implication is that, when a
  > programmer reasons incorrectly about their types, they should get slapped
  > on the hand -- whether as a static rejection, a la ML, or as a dynamic check
  > failure, a la Scheme, is irrelevant.
  > 
  > I believe there is a very useful way of relaxing this restriction to capture
  > the essence of scripting, while still recovering it when programs grow to
  > engineer software.  PLT Scheme needs a "scripting" language level, where
  > operators coerce heavily: APPEND consumes strings as well as lists; FIRST
  > works on vectors, not just pairs; and so on.
  > MrSpidey then needs a scripting analysis level, where it flags these coerced
  > uses in ultra-special-red, meaning "this may have worked for you earlier,
  > but
  > it sure won't work now".  Based on the coercions
  > 

It plain doesn't matter what your types are as long as you have types. 
Typing append in some overloaded manner is okay. 

Saying that (/ 1 0) is 5 is not okay. Saying that (5 10) is 22 is not
okay. And (car '()) = '() is probably counter-productive in any context
even though some Lisps implemented exactly that. 

-- Matthias