[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new-model.text, please comment
Re: new-model.text, please comment
Thu, 12 Sep 2002 15:48:43 -0700 (PDT)
[ Author: address@hidden; Status: very preliminary. ]
Ok... I've read it a couple of times.
Let me put my reply in some context. I _think_ I'm a bit more
experienced (in some sense) in these areas than you. Therefore, I
will _pretend_ that I'm qualified to reply as a pedant and, in that
light, trash your document. TB, at least, is always there to yank on
my leash :-)
Before I do that, a few qualifications:
Thanks for writing this. Gosh, I wish you'd done this "way back when"
when I was the maintainer. You're addressing important issues and
clearly have a deep enough mental model of those issues to be
qualified to do so. Yay!
Ok, let's talk trash:
1) The form of this document is all wrong.
I was hoping to read this from the perspective of a Scheme compiler
implementor who knows nothing about Guile. Probably that wasn't
your intended audience. Nevertheless, it's too informal a mixture of
ideas, in which you try to point out some important abstract
semantics via a mixture of vaguely descriptive statements and
I would advocate for something really ambitious. For example, start
with the semantics in RnRS and try to extend those for modules and
compilation. Try to also write an operational semantics (e.g. a
mapping of some of the formal semantics into a stable C API).
Taking this route has the potential to subject you to the nearly
boundless abuse of many Scheme experts -- but it also has the
_potential_ to lead to a very useful and influential document and
2) Compilation isn't special.
You seem too ready to distinguish "compile time" from "eval time".
Please don't do that. That's lisp, not Scheme.
For example, you write:
Some attributes of whatever is found when an identifier is
looked up are expected to carry over to the run-time
environment. Whether this is indeed the case should be
checked when the compiled form is executed and a warning
should be emitted when a violation is found, or an error when
there is no way to continue.
Bleh. What a cheap, bletcherous hack you advocate there. Of what
use is such a warning other than as a notice to the programmer that
"you lose"? (And, such a warning may not actually come until
certain code paths are reached -- possibly well after deployment).
I'd rather have a system in which some code simply can't be usefully
compiled (i.e, no significant performance benefit), but in which,
all compiled code behaves _exactly_ like loading the source into the
interpreter. I recognize that this may require some tweaks to the
interpreted language (e.g. to enable "locked up" modules).
Rather than defining a semantic "compile time", I'd rather see a
list of rules that code has to follow if it wants to permit a
compiler to optimize.
Here's an example of what I happen to think compilers are good for.
Suppose I write:
(define x (lambda (a b) (+ (* a a) (* b b))))
and, in the same file, a call to the (never assigned to) `x' for
which it is easy to infer that the arguments are small integers.
I expect some really tight code for that.
With such a compiler, as an app writer, I can take special care to
code performance critical sections in a compiler-friendly way. If
that worked well, I wouldn't care too much how significantly more
complicated code was handled.
As always: nothing _is_ false,
- new-model.text, please comment, Marius Vollmer, 2002/09/11
- Re: new-model.text, please comment,
Tom Lord <=
- Re: new-model.text, please comment, Rob Browning, 2002/09/12
- Re: new-model.text, please comment, Neil Jerram, 2002/09/13