From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Tom Lord Newsgroups: gmane.lisp.guile.devel Subject: Re: new-model.text, please comment Date: Thu, 12 Sep 2002 15:48:43 -0700 (PDT) Sender: guile-devel-admin@gnu.org Message-ID: <200209122248.PAA27264@morrowfield.regexps.com> References: <871y80tn9r.fsf@zagadka.ping.de> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1031870773 2880 127.0.0.1 (12 Sep 2002 22:46:13 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 12 Sep 2002 22:46:13 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17pciy-0000kK-00 for ; Fri, 13 Sep 2002 00:46:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17pcj5-000398-00; Thu, 12 Sep 2002 18:46:19 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17pci9-00035i-00 for guile-devel@gnu.org; Thu, 12 Sep 2002 18:45:21 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17pci6-00035C-00 for guile-devel@gnu.org; Thu, 12 Sep 2002 18:45:20 -0400 Original-Received: from 1cust12.tnt14.sfo8.da.uu.net ([63.11.84.12] helo=morrowfield.regexps.com) by monty-python.gnu.org with esmtp (Exim 4.10) id 17pci5-00034z-00 for guile-devel@gnu.org; Thu, 12 Sep 2002 18:45:18 -0400 Original-Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id PAA27264; Thu, 12 Sep 2002 15:48:43 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Original-To: guile-devel@gnu.org In-reply-to: <871y80tn9r.fsf@zagadka.ping.de> (message from Marius Vollmer on 11 Sep 2002 20:05:36 +0200) Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1335 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1335 [ Author: mvo@zagadka.de; 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 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel