Re: new-model.text, please comment

[Tom Lord]

        [ 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
  implementation-techniques-with-semantic-implications.

  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
  Guile.


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,
-t