Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
From: Erik Naggum <>
Date: 2000/08/28
Newsgroups: comp.lang.lisp
Message-ID: <>

* Chris Page <>
| I thought he was talking about writing programs that create or
| transform programs, producing new source code that is maintained
| apart from the original input to the macro-/pre-processor.

  Why would _maintaining_ the code be a requirement for it to be a
  program written by a program?  In my view, the whole point with
  writing in a more abstract/powerful/whatever language would be to
  _avoid_ maintaining the result.

| I hate to keep asking, but can you provide an example of a
| transformation that I could actually see my self wanting to perform?

  This is a valid request, but impossible to fulfill.  I think this is
  one of those situations where if you haven't had the need for it, it
  would be nigh impossible to explain, except in the abstract.

| I'm just trying to understand why this is such an important activity
| for you -- why you say you use this frequently.

  One of the things I do all the time is to extract prototypes from C
  source code and stuff them in header files.  I used to hack C code
  with Emacs Lisp code, but various tools now exist to do this for me.
  (Of course, it's a ridiculous task -- the C system should be able to
  do this automatically and not rely on duplication of declarations.)
  The result is not maintained -- in the case of a change in the
  source files, the header files are automatically renegerated.

  If you consider makefiles to be programs, consider the boring task
  of keeping the dependencies intact.  Much of this job is done by
  tools that extract header file dependencies, understand how using a
  header file means using an object file, which means using a library.

  A long time ago, before I figured out that I didn't have to use C, I
  spent a lot of time writing Emacs Lisp code to help me figure out
  which header file to include if I wanted a particular function, and
  then automatically insert the right rules in the makefile.  Pretty
  pathetic stuff, really, when a decent programming system should have
  been able to figure out _all_ of this on its own, but, hey, that's
  Unix for you.

  Another case of software writing software is revision control
  systems that actually produce source files according to a bunch of
  criteria that are far from obvious.  Of course, this applies to
  _text_ files, not source code qua code, but I think it's worth
  mentioning because it might broaden the context enough that you find
  that you also keep doing some of this program-writing-programs stuff.

| In my experience this kind of task is extremely rare in commercial
| software development.

  Well, I'd hate to see a moderately large project maintain makefiles
  by hand, for instance.

  Incidentally, defsystems are somewhat easier to maintain than
  makefiles, but still cry out for automatic tools.  I wrote a small
  function a long time ago that helps me put together defpackage forms
  for my files, too.  No need to maintain the old code -- just discard
  the old form and recompute the new.

| But rather than perhaps require all future programming languages to
| make easy transformation a priority language feature, I can imagine
| tools for performing transformations that make it possible to
| describe the transformations in a simple and deterministic fashion.

  Hm.  I used to hear this from SGML people back in the early 1990's.
  It'll never happen.  Such tools become enormously complex if they
  are complete, and if they are complete, impossible to use, too.
  That's really why I use Common Lisp syntax for _everything_: No need
  to write (or (still) wait for, in the case of SGML, HTML, XML).  I
  think transformablity _should_ be a priority language feature.

| Which is to say I favor a future where computers do more of the work in
| programming, as they have done for word-processing and bookkeeping.

  This is interesting, because computers do _much_ less of the work in
  today's word-processing than people were actually _using_, not to
  mention working on, prior to the advent of WYSIWYG tools.

  (Accounting and book-keeping never should have involved humans in
  the first place.)

| I think you're saying something similar when you say you want to be
| able to transform programs programmatically. However, I think
| perhaps I am expecting computers to make it easy for you to write
| the transforming programs for more complex target languages, whereas
| you would rather keep target languages simple so that the
| transforming programs can be written without much help from the
| computer.

  That's just the issue: Writing the transformation program should be
  easier than doing it yourself.  The more complex and multifaceted
  the syntax, the harder that program becomes to write, and the more
  needs to be specified.  And worse, with a complex syntax, some
  transformations won't even be possible unless it had been thought of
  to begin with.  Simple, regular syntax avoids all of these problems.

  If this is not what you expected, please alter your expectations.