From ... From: Erik Naggum Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant indentation? Date: 2000/08/28 Message-ID: <3176475011374927@naggum.net>#1/1 X-Deja-AN: 663571308 References: <3990E003.6EE78131@kurtz-fernhout.com> <874s48vvyg.fsf@piracy.red-bean.com> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 967487064 9152 195.0.192.66 (28 Aug 2000 18:24:24 GMT) Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601; http://naggum.no; http://naggum.net User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 Mime-Version: 1.0 NNTP-Posting-Date: 28 Aug 2000 18:24:24 GMT Newsgroups: comp.lang.lisp * 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. #:Erik -- If this is not what you expected, please alter your expectations.