[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue "Eliminate forced consing" re-visited
- To: firstname.lastname@example.org, pierson <@multimax.arpa:pierson@mist>
- Subject: Re: Issue "Eliminate forced consing" re-visited
- From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Date: Tue, 23 Aug 88 18:59:01 BST
- Cc: email@example.com
> Date: Tue, 23 Aug 88 11:20:52 EDT
> From: "Dan L. Pierson" <firstname.lastname@example.org>
> However, the form of the proposal needs some more work.
> - The proposal text should be rewritten as if it were the new parts
> of the manual/standards document. I'd certainly understand some
> abbreviation to keep from having to rewrite the whole sequence
> chapter and a large part of the list chapter.
Really? Do we supposedly even know what the format is yet?
> All-in-all, this has moved from what I remember as more a philosophical
> statement than a cleanup proposal to something that I think we can,
> and should, pass unless we are prepared to "depreciate" the sequence
> functions entirely.
I think that is going a bit far. Surely the sequence functions are
not nearly useless without this change. (Recall, for example, that
some of them just search.)
I would be interested in an informed opinion on how much of the
excess allocation can be eliminated by soemthing like OSS and how
much still requires destructive operations. I also wonder whether
OSS-like optimizations could be added to ordinary CL compilers for
some class of operations involving the normal sequence functions.
> The main objection to this proposal seems to be Scott's belief that
> LOOP can and will replace the sequence functions for most purposes.
I do not thing LOOP will really do this. Think of concatenation.
It's much easier to call CONCATENATE than to write the loop, so
one would probably end up writing a destructive procedure with
LOOP inside it rather than using LOOP directly.
BTW, one useful weapon in the war against C would be the ability to
read n characters into a buffer (string?, array?, I don't care).
It's a pain to scan a file allocating a string for every READ-LINE.
Destructive READ-LINE might do, I suppose. It also would be useful
(as was suggested in the proposal) to be able to refer to a
subsequence without actually extracting it. DESIGNATE-SUBSEQ
can probably be written in CL (sort of like locatives are written
in T), but not efficiently (and you couldn't have the normal
sequence functions work on them (except maybe via CLOS)).