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: <chip.674492719@soi> <1991May18.045823.9174@Think.COM> <chip.674746246@soi>
Date: Tue, 21 May 91 02:31:34 GMT

In article <chip.674746246@soi> 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
