Newsgroups: comp.lang.scheme Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!barmar From: barmar@think.com (Barry Margolin) Subject: Re: Why memq vs memv vs member, etc.? Message-ID: <1991May21.023134.19824@Think.COM> Sender: news@Think.COM Reply-To: barmar@think.com Organization: Thinking Machines Corporation, Cambridge MA, USA References: <1991May18.045823.9174@Think.COM> Date: Tue, 21 May 91 02:31:34 GMT In article chip@soi.UUCP (Chip Morris) writes: >Of course, all bets are off after calls to LOAD or EVAL. However, I >found it not too hard to write a rather large program without ever >mentioning either. I sure would like to have reasonable analyzers. But the static analyzer has no way of knowing what will be done prior to loading the file it is analyzing. This leads into your later point.... >Part of the problem is that people seem to advocate an all-or-nothing >solution. The existence of LOAD or EVAL is first used to pooh-pooh >the idea of analysis tools to guarantee certain invariants about a >program. But maybe I'm willing to write to coding standards >(statically verifiable?) that permit such tools to work. Shouldn't we >permit, if not encourage, such practice? Certainly we should. In the ANSI CL standard, we're including explicit specifications that permit compilers to make enough assumptions that a reasonable level of static analysis can be done. We disallow users from redefining symbols specified in the standard. We define a set of assumptions the compiler is permitted to make about the relationship between the compilation environment and the runtime environment, which permit a certain amount of intrafile optimization (e.g. many implementations' "block compilation" facilities). Making these things explicit causes the standard to be more complex, but we think it's worth it. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar