[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
- To: firstname.lastname@example.org (Sandra J Loosemore)
- Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
- From: Rob.MacLachlan@WB1.CS.CMU.EDU
- Date: Fri, 20 May 88 16:55:14 EDT
- Cc: email@example.com
- In-reply-to: Your message of Fri, 20 May 88 14:03:55 -0600. <8805202003.AA06503@cs.utah.edu>
From: firstname.lastname@example.org (Sandra J Loosemore)
Date: Fri, 20 May 88 14:03:55 MDT
Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
> Date: Fri, 20 May 88 15:09:45 EDT
> From: Rob.MacLachlan@WB1.CS.CMU.EDU
> Like Jonl, I favor saying that forms like DEFMACRO are actually truly,
> honest to God evaluated by the compiler.
[...] These two paragraphs seem mutually contradictory.
Well, not in my intent. I don't include DEFUN in "forms like DEFMACRO".
The "forms like DEFMACRO" are:
As a codification of current practice, the proposal is fine, but it doesn't
go nearly as far in specification as a good language design should.
Vagueness in specification is a powerful tool, but you shouldn't be vague
for no good reason. The main reason that current practice is so diverse is
that this stuff was never standardized on, and for most programs *it
doesn't matter* as long as it falls within the general range you outline.
The problem with not being definite is that it encourages non-portability,
since the few programs that do care will work differently on different
Having said that, I point out that I have no objection to this proposal
other than that it doesn't require the DEFCONSTANT value form to be
compile-time evaluable. In all other ways it is compatible with my
compiler cleanup proposal, since its definition is so inclusive.