Re: new-model.text, please comment

[Marius Vollmer <mvo@zagadka.ping.de>]

Tom Lord <lord@regexps.com> writes:

> TB, at least, is always there to yank on my leash :-)

:-)

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

Right.

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

Yes, the interfaces of what I try to describe to the rest of the
'system' needs to be better specified.  That would mostly be the macro
expander and the module system.  Also, some useful declarations need
to be specified.

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

Yeah, that needs to be done, and I hope I have a small first step.

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

The alternative would be a 'fool-proof' system where you can't
possibly make a mistake.  Such a system will be no joy to use, I'm
afraid.

Anyway, I actually try to avoid a discussion about what kind of module
system we want, whether it should allow incremental, interactive
modifications, or whether it must allow closed-world compilation ala
Stalin.

I hope that the model allows both.

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

Would one just ave the option of locking a module, or would all
modules be locked?

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

I don't think we should have the rule that the compiler can assume by
default that a variable will never be assigned to when it is not being
assigned to in the file where it is defined.

We should probably have declarations for the file as well as for
variables, and with them, the 'new-model' can allow block-compilation.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel