[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: TAGBODY-CONTENTS (version 1)
- To: vanroggen%aitg.DEC@decwrl.dec.com
- Subject: Issue: TAGBODY-CONTENTS (version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 13 Sep 88 19:02 EDT
- Cc: CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: <8809131932.AA14180@decwrl.dec.com>
I generally support this TAGBODY-CONTENTS:RESTRICT, but have the following comments:
Cost to Implementors:
A few simple checks are probably all that's needed, and probably
most implementations (both interpreters and compilers) already perform them.
Actually, this should be "no cost" since you've only said this "is an error".
You've not required implementations to signal. With my portable-code-writer's hat
on, I'd applaud any attempts to make implementations really signal in this case,
but my guess is that most implementors (maybe even Symbolics itself) would boo me
on this and would regard this as an imposition of the same caliber as my IF-BODY
suggestion a while back.
Cost to Users:
Unlikely to affect any portable code. If there are implementations which
support other objects as tags (floats, for example), there may be simple
Again, no cost. Users already can't rely on anything more than what's in CLtL.
If they do, they're not writing CL code. Further, since you're not forcing
implementations to change, they are free to continue to rely on this non-portable
extension as long as implementors don't get overzealous and upgrade just for grins.
Bottom line: I don't think this proposal really restricts anything. I think it's
just a restatement of the status quo. If you think there's confusion, I accept that
statement as an existence proof that there is confusion and I'm happy to see it