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

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




> From: "Shriram Krishnamurthi" <sk@cs.brown.edu>
> Date: Wed, 15 Aug 2001 23:48:25 -0400
> 
> [Oops -- I just discovered, much to my chagrin, what Ctrl-Enter does
>  in Outlook.  What a dumb binding.]
> 
> > 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; + adds strings that contain
> only digits; 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 can indicate what
> operator you meant to use, and even synthesize the code that automatically
> performs the coercion: eg,
> 
>   (append (+ S "2") "y")
>   ->
>   (string-append (number->string (+ (string->number S)
>                                     (string->number "2")))
>                  "y")
> 
> under the right circumstances.
> 
> For programs that don't live on, programmers get to write very concise
> descriptions, and their minor infractions are forgiven.  But the scripting
> language level should provide no programming-in-the-medium features --
> no modules or units or classes, for instance.  The moment you want to
> make your script reusable, you must go through Scripting Spidey and clean
> up your act to upgrade your code into a mature fragment.
> 
> Shriram
> 
> 

The thing I worry about is that users who are used to the scripting level
will get very confused when things that worked there break at the
non-scripting level.  However, what you say is analogous to the perl "use
strict" pragmas where you can say "this works in the normal language but we
are deliberately saying we're not going to do it that way here", so there
is some precedent for it at least (but do we want to be getting inspiration
from perl? ;-)).

I think a bigger issue is not easy coercions; I personally *hate* all
coercions (except trivial ones like int->real) because I'm at the mercy of
whatever the language designer thought a "reasonable" coercion was.  Coerce
"1" to 1?  Sure, makes sense!  However, you can't do that in python, and
it's a perfectly reasonable scripting language, and people don't have
problems with it.

Instead, the "scripting" issue (to the extent that there is one) is largely
that people don't like having to put lots of type annotations in their
code, whereas as an application grows and matures, they *do* like those
annotations for the extra security.  One of my beefs about scheme is that
there is no type language that allows me to do this (I haven't looked into
soft typing schemes, though).  If there were, you could imagine having
pragmas that say one of:

-- no type annotations in this module; everything is dynamically typed
-- some type annotations; functions with them are statically typed
-- everything in this module must be statically typed

This would be the normal progression from "scripting" to a larger, more
mature (and maybe less flexible) application.  This would really rock.
Of course, for me to be _really_ happy I'd like to see the type language
able to handle ML-style parametric polymorphism etc., but one wish at a
time :-)

Mike