Re: Destructive Functions

On 24 Dec 2005 01:24:07 -0500, jayessay wrote:

> Barry Margolin <barmar@xxxxxxxxxxxx> writes:
>> > I believe you are thinking of coalescing here. Literals (objects) in
>> > COMPILEd code are required to reference (as in eql) the literals
>> > (objects) in the source code. So, if a literal in the source is
>> > already "coalesced", say by the reader, then the COMPILEd code will
>> > refer to only one such object for that literal. So, the thrust of
>> > what Pascal is saying here still stands.
>>
>> The reader is not allowed to coalesce constants, AFAIK. Only the
>> file-compiler can.

> Hence the "scare-quotes". To coalesce literals X and Y from some
> source code would mean that they must start out not eql, but their
> corresponding objects in the compiled code are eql. But if (eql X Y)
> is true, then their corresponding objects in the compiled code of a
> COMPILE must also be eql. So, if '(1 2 3) shows up as a literal in
> two pieces of some source, and these map to the same object, then they

The literal '(1 2 3) appearing twice (in two pieces of source) can't
"map to the same object", since the list has to be built up at read
time. (Unless you mean something like using #n# notation to put the
same object in two places)

>> in-core compiler seems like a wart. As a result, it's likely that the
>> following simple function will behave differently depending on whether
>> it's compiled by COMPILE or COMPILE-FILE:
>>
>> (defun compile-file-p ()
>> "Should return NIL when COMPILEd, may return T when COMPILE-FILEd."
>> (eq '(nil) '(nil)))

> Interesting. I would have thought otherwise. Here's some data on this:

> CL-USER(1): (defun foo () (eq '(1 2 3) '(1 2 3)))
> FOO
> CL-USER(2): (foo)
> NIL ;; !!! a bit odd to me.

Evaluating (QUOTE x) returns x -- the very same value that occurs in
the QUOTE form, not some "similar" value. The list (1 2 3) in the
first QUOTE form is obviously a different list than the one in the
second QUOTE form, so they /can't/ be EQ.

> CL-USER(3): (compile 'foo)
> FOO
> NIL
> NIL
> CL-USER(4): (foo)
> T ;;; More like it to my mind, but still odd given the interpreter results

Eh? What implementation is this? I'd call that a bug.


--
Quid enim est stultius quam incerta pro certis habere, falsa pro veris?
-- Cicero
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))
.

Relevant Pages

  • Re: a little confused about packages...
    ... seem to take care of this on its own. ... a console are the same errors that I get in the ide... ... You have all the source code files in the "src" directory, ... use the "classes" directory for the compiled code. ...
    (comp.lang.java.help)
  • Re: Are they obligued to give me the source code?
    ... Michael Schnell a écrit: ... Thus if the compiled code can be downloaded the source code needs to be downloadable from the same site. ... Did you get that from the German ruling? ...
    (comp.os.linux.embedded)
  • Re: Problems creating subform
    ... The result is that the next time you run the file, the source code is re-compiled, while you have gotten rid of any executable code rubbish that were left behind during development (deleting the source code for a procedure, or a whole module, doesn't remove its compiled code, I believe). ...
    (microsoft.public.access.forms)
  • Re: Paging Mr. Rettig [ws Re: Explanation of macros; Haskellmacros]
    ... I don't recall if there is a compiled code ... >>source code that was being evaluated. ... I don't think MIT Scheme tracks macro expansions. ... > line in the definition of bar which invokes baz, ...
    (comp.lang.lisp)
  • Re: Paging Mr. Rettig [ws Re: Explanation of macros; Haskellmacros]
    ... I don't recall if there is a compiled code ... >>source code that was being evaluated. ... I don't think MIT Scheme tracks macro expansions. ... > line in the definition of bar which invokes baz, ...
    (comp.lang.python)