Re: another take on hackers and painters

[Matt Hellige <address@hidden>]

[mcguire@cs.utexas.edu]
> 
> Matt Hellige <matt@immute.net> wrote:
>  >Here's another big one: reflection and dynamic evaluation.
> 
> Aha!  That is a big one.  I suppose the other alternative is to write
> your own "eval-string" including parser, type checker, and so forth. :-)
> 

As pointed out by many, this is actually even harder than just
rewriting the interpreter...

In any case, this reminds me of another of my favorite soap box
topics: I really believe that all languages ought to provide a
standard way of parsing themselves and internally
representing/manipulating parsed program fragments. This is one thing
that Lisp did perfectly, but it applies to languages with more syntax
as well. 

It's particularly important in languages that *do* provide some kind
of eval. Anyone who's used eval in a language like Python probably
knows the pain that comes with only being able to eval a black-box
string. It's very difficult to correctly construct, inspect or
manipulate correct code fragments (using string operations, no less,
especially in a significant-whitespace language like Python) without
some built-in support. 

But even in languages without eval, it still happens all the time.
It is axiomatic that sooner or later a programmer will want to write
programs to manipulate other programs. If the issue is addressed
up-front, there are several benefits:
  1. Implementations will be more modular and interoperable, since
     there are well-defined data structures (with appropriate operations)
     for programs. This means syntactic extensions, program
     transformations, and so on have clean abstraction layers.
  2. Any problems will come up sooner. Anybody who's been following
     the development of Template-Haskell appreciates the difficulty of
     retro-fitting a clean, understandable data structure to a mature
     programming language. If the representation and syntax had
     evolved together, my suspicion is that this could have been
     avoided.
  3. Programmers who want to do these things will be less turned off
     by your language, and the usual idiom of your language will
     include these tools from the beginning... This is in contrast to,
     say, Java, where programmers tend not to think in these terms,
     and tend to limit possible solutions to those that avoid
     "complicated" things like, for example, program generation or
     manipulation... Even while they'll happily subject themselves to
     the perdition of manipulating complex XML documents programatically
     through the DOM.
  4. When the time does come to consider adding macros, templates, an
     eval facility, or any other meta-programming facilities (and I
     believe that time will always come), this is one huge hurdle that
     will already have been overcome.

Anyway, I'll stop ranting now...

Matt

-- 
Matt Hellige                  matt@immute.net
http://matt.immute.net