RE: LCOM's with FUNCTIONS?
Larry Masinter
LispWorks has the only Ansi-standard online reference I know of.
They have a very restrictive license. But it is good look there
CLHS: Function COMPILE-FILE (lispworks.com)
And even to the (almost Talmudic) commentary on the differences
CLHS: Issue PATHNAME-LOGICAL Writeup (lispworks.com)
I was thinking we might be able to negotiate a license to make a better format or API for Common Lisp users.
--
From: Ron Kaplan <ron.k...@post.harvard.edu>
Sent: Wednesday, May 5, 2021 2:11 PM
To: Nick Briggs <nicholas...@gmail.com>
Cc: Larry Masinter <L...@acm.org>
Subject: Re: LCOM's with FUNCTIONS?
I looked at compile-file in the Steele book (second edition). It doesn’t seem to say anything about the name of the output file.
On May 5, 2021, at 1:35 PM, Nick Briggs <nicholas...@gmail.com> wrote:
I have a feeling that the CommonLisp language spec says CL:COMPILE-FILE (on a file with a .LSP or .LISP extension) produces output with extension .*X*FASL where X depends on the system/cpu/whatever that it's running on (thus the .DFASL).
It should all work properly, though.
On May 5, 2021, at 1:20 PM, Ron Kaplan <ron.k...@post.harvard.edu> wrote:
I think the compiling interface needs work.
We shouldn’t have 2 file extensions, that just leads to confusion when a file that can be compiled in different ways is in fact compiled in different ways. Thinks get out of step.
The commonlisp compiler should produce LCOMs too.
There should be a little test function that returns the way a file was compiled by looking at the compiled file itself.
A single toplevel call to the compiler should do the right thing—look at the FILETYPE, look at whether it contains things that one compiler or another can’t compile, etc. Maybe 2 calls, one for recompile (which a particular compiler can ignore if it doesn’t support it).
Meanwhile, I have some files with FUNCTIONS that compile OK with FAKE-COMPILE-FILE but not with CL:COMPILE-FILE.
I’m trying to get through all of this external-format rationalization, to set the stage for an eventual switch to Unicode. I see lots of unnecessary inline calls to the basic macros (mostly \OUTCHAR) that should be replaced by close calls, to make this easier in the future.
As for Unicode fonts, there is an easy transition there too—keep fonts as XCCS encoding, but change the character printer to translate from a Unicode charcode to the corresponding XCCS. Longer term: move the glyphs around in the font files. But the font lookup doesn’t have to change.
On May 5, 2021, at 12:13 PM, Larry Masinter <L...@acm.org> wrote:
it looks like CMLMISCIO.LCOM was made with FAKE-COMPILE-FILE.
I suppose the next big task is getting "recompile everything" to work.
Or is there something else?
On Tue, May 4, 2021 at 4:35 PM Ron Kaplan <ron.k...@post.harvard.edu> wrote:
There is a function COMPILE-FILE? that MAKEFILE/CLEANUP uses to decide what the compiler to use, based on the FILETYPE property.
I fiddled with this a few months ago, to make it be accessible for some reason that I don’t now remember, maybe so that a SAMEDIR kind of thing could be done to prevent files from migrating.
But one of the values that gets returned is FAKE-COMPILE-FILE, which causes MAKEFILE1 to use a compiler named FAKE-COMPILE-FILE. Could that be what is producing LCOM’s for CL files?
Otherwise it goes to CL:COMPILE-FILE, which again I presume only produces DFASLs, and doesn’t do only partial recompiles.
> On May 4, 2021, at 1:17 PM, Ron Kaplan <ron.k...@post.harvard.edu> wrote:
>
> The compiled file is an .LCOM, which I believe means that it was compiled by a byte compiler, either BCOMPL or TCOMP. If it had been compiled by the commonlisp CL:COMPILE-FILE, it would have been a DFASL.
>
> The inherited file is an LCOM, and the FUNCTIONS are compiled.
>
> But when I do TCOMPL(CMLMISCIO), I get an LCOM where the FUNCTIONS are not compiled, just copied over as DEFUN’s.
>
> So my question is, is there an interface that does the right thing?
>
> Or maybe my understanding of the LCOM/DFASL distinction is incorrect. Does the CL:COMPILE-FILE also produce LCOM’s, so that the the extensions don’t discriminate?
>
> I used TCOMPL on this file because I saw that it was an LCOM.
>
>> On May 4, 2021, at 12:54 PM, Larry Masinter <L...@acm.org> wrote:
>>
>>> There are some files that contain FUNCTIONS but also have LCOM compiled
>>> files. When I look at the LCOMs, the functions are still there symbolically.
>>> And that was true in earlier versions.
>>>
>>> For example, look at CMLMISCIO.LCOM
>>>
>>> Are all the LCOMS for files that have FUNCTIONS screwed up in this way?
>>> Should all of these be recompiled as DFASL’s?
>>
>> ??
>>
>> I looked and didn't see -- all of the DEFUN looked compiled. The comment in the COMS about the FILETYPE property makes me wonder.
>>
>> GETD(CL:WRITE-STRING) => #<Compiled Function CL:WRITE-STRING....>
>>
>> "Arrange to use the proper compiler" ?
>>
>>
>
--
Ron Kaplan
--
You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lispcore/02bf01d741fc%24fd2ae5d0%24f780b170%24%40acm.org.
John Cowan
There are many copies of the Common Lisp Hyperspec on line: www.ai.mit.edu, clhs.lisp.se, dept-info.labri.fr, accela.net, lisphub.jc, etc. Anyone can display it (including us), but modification is forbidden. It is based on the ANS, and its special contents (the HTML formatting and some outlying pages) were made by Kent Pitman and are covered by Harlequin (now Lispworks) copyright. It is probably not possible to license the ANS itself, because the X3J13 committee is no longer functioning.But the underlying *draft* standard, dpANS X3.226 version 2, though technically in copyright, is generally treated as freely available (like other draft language specs). Copies of it can be downloaded in HTML from <https://mr.gy/ansi-common-lisp> and in TeX (the original format) from <https://github.com/xach/dpans>.You can find the changes between CLtL1 and CLtL2 by looking at the online copy of CLtL2 at <https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/clm.html> for references to the images "gif/change_begin.gif" and "gif/change_end.gif". A VERY PARTIAL list of changes from CLtL2 to the ANS can be found at <http://web.archive.org/web/20130807175341/http://bc.tech.coop/cltl2-ansi.htm>.
--