CLHS 18.2.11 maphash:
"...The consequences are unspecified if any attempt is made to add or
remove an entry from the hash-table while a maphash is in progress, with
two exceptions: the /function/ can...use remhash to remove that entry."
Or am I confusing "remove" with "remove"? The italic emphasis on
"function" is in the CLHS (ie, not added by me) so must be a clue. But
what other application code runs "while a maphash is in progress"? I
doubt they mean the remhash must appear lexically...nah.
puzzled.
kxo
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
From: Zach Beane
Subject: Re: What Part of Unspecified Does Kenny Not Understand?
Date:
Message-ID: <m3r6c65qg6.fsf@unnamed.xach.com>
Ken Tilton <···········@optonline.net> writes:
> CLHS 18.2.11 maphash:
> "...The consequences are unspecified if any attempt is made to add or
> remove an entry from the hash-table while a maphash is in progress,
> with two exceptions: the /function/ can...use remhash to remove that
> entry."
>
> Or am I confusing "remove" with "remove"? The italic emphasis on
> "function" is in the CLHS (ie, not added by me) so must be a clue. But
> what other application code runs "while a maphash is in progress"? I
> doubt they mean the remhash must appear lexically...nah.
I think the italic emphasis is just part of the style to display
function arguments, and for maphash those are /function/ and
/hash-table/. For example, the first paragraph says:
Iterates over all entries in the /hash-table/. For each entry, the
/function/ is called...
I don't think any other special emphasis is intended in the part you're
citing.
Zach
Ken Tilton <···········@optonline.net> writes:
> CLHS 18.2.11 maphash:
> "...The consequences are unspecified if any attempt is made to add or
> remove an entry from the hash-table while a maphash is in progress,
> with two exceptions: the /function/ can...use remhash to remove that
> entry."
>
> Or am I confusing "remove" with "remove"?
The difference is between "an entry" and "that entry". You may remove
the key that the function was called with, you may not remove any
other keys.
--
Juho Snellman
Juho Snellman wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>CLHS 18.2.11 maphash:
>>"...The consequences are unspecified if any attempt is made to add or
>>remove an entry from the hash-table while a maphash is in progress,
>>with two exceptions: the /function/ can...use remhash to remove that
>>entry."
>>
>>Or am I confusing "remove" with "remove"?
>
>
> The difference is between "an entry" and "that entry". You may remove
> the key that the function was called with, you may not remove any
> other keys.
>
Ah! Very good, thx.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: What Part of Unspecified Does Kenny Not Understand?
Date:
Message-ID: <rem-2008may13-006@yahoo.com>
> > CLHS 18.2.11 maphash:
> > "...The consequences are unspecified if any attempt is made to add or
> > remove an entry from the hash-table while a maphash is in progress,
> > with two exceptions: the /function/ can...use remhash to remove that
> > entry."
> From: Juho Snellman <······@iki.fi>
> The difference is between "an entry" and "that entry". You may
> remove the key that the function was called with, you may not
> remove any other keys.
That's my understanding too. I'm 99% sure KMP will agree.
CLtL1 is more clear, but has a typo: Manually typing in from printed page:
"with one [sic] exception: if the function calls REMHASH to remove
the entry currently being processed by the function, or performs a
SETF of GETHASH on that entry to change the associated value."
The important more-clear phrase is "the entry currently being processed".
I wonder why KMP changed the language in the HyperSpec to be ever
so slightly less obviously clear than how Steele had explained the
same thing? Maybe KMP thought the new wording was less
wordy/verbose/redundant/overkill/forDummies?
(I don't have access to the ANSI spec AFAIK, so I'm just guessing
that KMP made the language more concise in the ANSI spec, then
simply copied that concise language into the HyperSpec. If Steele
would grant permission, perhaps KMP should update the HyperSpec to
use Steele's language instead, since it does seem to be a point of
occasional misunderstanding? Or maybe have the phrase "that entry"
in *each* of the two-exceptions be a hyperlink to the explanatory
footnote "the entry currently being processed, i.e. the entry whose
key is the first parameter to the function")
On May 13, 7:28 pm, ···················@SpamGourmet.Com wrote:
> The important more-clear phrase is "the entry currently being processed".
Which is exactly the text in the HS:
> The consequences are unspecified if any attempt is made to add or remove
> an entry from the hash-table while a maphash is in progress, with two
> exceptions: the function can use can use setf of gethash to change the
> value part of the entry currently being processed, or it can use remhash
> to remove that entry.
Beware of Usenet ellipses.
--Dan
------------------------------------------------
Dan Bensen http://www.prairienet.org/~dsb/
cl-match: expressive pattern matching in Lisp
http://common-lisp.net/project/cl-match/
danb wrote:
> On May 13, 7:28 pm, ···················@SpamGourmet.Com wrote:
>
>>The important more-clear phrase is "the entry currently being processed".
>
>
> Which is exactly the text in the HS:
>
>>The consequences are unspecified if any attempt is made to add or remove
>>an entry from the hash-table while a maphash is in progress, with two
>>exceptions: the function can use can use setf of gethash to change the
>>value part of the entry currently being processed, or it can use remhash
>>to remove that entry.
>
>
> Beware of Usenet ellipses.
>
Ah, but is not just a Usenet ellipsis, it reflected my mental ellipsis:
When I got to "change the value of..." I thought "right, right, right,
of course it can [aside: I wonder why there is a limitation to the entry
currently being processed, it would not change the hash order...
anyway...] and besides that is not what I want to do".
So I tuned out the bit about "entry currently being processed". When
that that came along I lacked its binding and got stumped.
The CLHS /does/ reverse the order such that remove gets the full
description of what can be removed and mutate gets the "that".
kzo
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
> danb wrote:
> > Beware of Usenet ellipses.
On May 14, 10:50 am, Ken Tilton wrote:
> Ah, but is not just a Usenet ellipsis, it reflected my mental ellipsis
Beware of Usenet ellipsors.
--Dan
------------------------------------------------
Dan Bensen http://www.prairienet.org/~dsb/
cl-match: expressive pattern matching in Lisp
http://common-lisp.net/project/cl-match/
Robert Maas, <···················@SpamGourmet.Com> wrote:
+---------------
| (I don't have access to the ANSI spec AFAIK...
+---------------
*Sure* you do!!
http://alu.org/HyperSpec/Body/fun_maphash.html
[That's as close to ANSI as *anybody* will get these days,
given the poor quality of what ANSI is selling as "the spec". ;-{ ]
+---------------
| ...so I'm just guessing that KMP made the language more concise
| in the ANSI spec, then simply copied that concise language into
| the HyperSpec.
+---------------
Don't guess; go look. As DanB points out, the ellipsis was Kenny's,
not Kent's.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Edi Weitz
Subject: Re: What Part of Unspecified Does Kenny Not Understand?
Date:
Message-ID: <uod79cmms.fsf@agharta.de>
On Tue, 13 May 2008 21:59:06 -0500, ····@rpw3.org (Rob Warnock) wrote:
> *Sure* you do!!
>
> http://alu.org/HyperSpec/Body/fun_maphash.html
I would advise against pointing out the alu.org URL and instead show
the one at lispworks.com:
http://www.lispworks.com/documentation/HyperSpec/Body/f_maphas.htm
The CLHS at alu.org is at version 4.0 while the one at lispworks.com
is at 7.0, presumably fixing a couple of issues with earlier versions.
It also makes clearer that (the predecessors of) LispWorks - and not
the ALU - paid for the generation of the HyperSpec, own the rights to
it, and made it publicly available.
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Kent M Pitman
Subject: Re: What Part of Unspecified Does Kenny Not Understand?
Date:
Message-ID: <uy76cri49.fsf@nhplace.com>
Edi Weitz <········@agharta.de> writes:
> The CLHS at alu.org is at version 4.0 while the one at lispworks.com
> is at 7.0, presumably fixing a couple of issues with earlier versions.
The issues were not major (and none are technical), but yes, there are
some fixes, including a better index.
I know people prefer version 4 because it had the Java widget in the
index that lets you type to it. I removed that in later versions
because in the early days was unreliable, and in modern times some
people have it disabled for security reasons. (And I find it's
usually faster to click through to a name using the index or permuted
index than to type something, even for me who is a pretty good typist,
so the Java widget seemed less good to me. It's prone to not finding
things if you make a typo, too, which is an issue the clickable
indexes mostly don't have. No, the clickable index doesn't fix the
LOGBITP problem, but neither does the Java widget.)
The newer v7 has an enhanced master index, including indexing of the
format operations and the sharpsign ops, if I recall. That alone makes
it a very bad thing to be continuing to reference v4 because a lot
of people have a lot of trouble finding these.
Also, I got a complaint from someone who was dyslexic who said that a
a partial "workaround" for that problem is to view things in high
contrast, and who pleaded with me not to put it on a gray background.
That's why it's on white these days, although it may just look like an
artistic choice--certainly there's very little text-on-gray in the
modern world compared to when the web was new. I do personally find
the white background easier to read.
And the CLHS at the ALU web site uses the old (longer) file naming,
the practical implication of which is that it increases the likelihood
that URL references will overrun a single text line, though it was
made for another reason--to allow service from some Macintosh file
system or another, which had a filename limit that was one character
off from *nix (31 instead of 32, if I remember right) causing a couple
of file names not to fit. In the process of the fix, I made all the
filenames DOS 8.3 compliant so someone could host it from any OS.
> It also makes clearer that (the predecessors of) LispWorks - and not
> the ALU - paid for the generation of the HyperSpec, own the rights to
> it, and made it publicly available.
LispWorks Ltd. presumably had to pay to acquire the assets they now
enjoy, of course, so I think it's right and proper to say they paid
for it. Also worth noting is that they have paid subsequent to that
to do some care and feeding on that current doc, a bit in money but
mostly in time and effort (which I'm sure to them translates to
opportunity cost, and hence to money, too), not just to do the
upgrades but also to do the QA that goes into make sure that the
upgrades are of good quality and that in attempting to fix one thing
they don't break another.
I do agree that having the site continue to point through to Harlequin
is not fair to the people that made it, though. Unfair does not mean
illegal. But there are people (myself include at times, as you know)
who think there is a crew of folks out there trying to actively assure
that no one who makes a commercial software investment in the world
ever succeeds, and who exploit every opportunity to commercially
injure any business that doesn't just give things away. I am NOT
suggesting that that's what happening here--I don't know the
motivation. But I certainly think it is consistent with that, and prone
to confuse some people, and as such is inappropriate from an organization
that seeks to represent the community.
I have said in the past and I will say again: The correct solution to
alu.org remaining vendor-neutral is for it to ALSO host other vendors'
documentation (e.g., Franz's alternate spec) if it wants to do that,
and to let individuals choose which to reference. Indeed, it should
also feel free to host both v4 and v7 of CLHS, for people who like the
old lookup widget thing if that's the issue, and again to let the
individual people decide which to reference by adding /v7/ or /v4/ in
the URL above the corresponding CLHS root filename. But it does as it
stands have the vague look of something that is trying hard to not
acknowledge that Harlequin is no longer there and is trying hard not
to accept that LispWorks is a viable vendor, making money, trying to
solicit customers, and paying their dues in the community by offering
not only the continued availability of CLHS but also other "free" (no
not GPL, which I don't agree has a lock on that word no matter what
they say, but certainly no-cost free-as-in-beer and quite usable for
some purposes) Lisp.
So I join with Edi in publicly requesting that someone fix the ALU
web site.
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
...
> So I join with Edi in publicly requesting that someone fix the ALU
> web site.
Just put the new version on the site. It is good advertising
for LispWorks. ;-)
--
http://lispm.dyndns.org/
Kent M Pitman <······@nhplace.com> wrote:
+---------------
| Edi Weitz <········@agharta.de> writes:
| > The CLHS at alu.org is at version 4.0 while the one at lispworks.com
| > is at 7.0, presumably fixing a couple of issues with earlier versions.
|
| The issues were not major (and none are technical), but yes, there are
| some fixes, including a better index.
+---------------
O.k., guys, I'll stop doing that unless/until the LispWorks version
gets mirrored at "alu.org". Just so you know, the main reasons I tend(ed)
to point at the ALU site are:
1. The URL(s) for Harlequin/Xanalys/LispWorks kept moving around
right about the time I was starting to use CL in anger, and articles
I posted ended up with broken CLHS links in the archives. (Bummer.)
I had some hope that the ALU URLs would be more stable [but that
hasn't always been the case, either, oh well].
2. I *hated* (and still dislike) the Franz version ("way too different"),
so I never pointed to it.
3. I *prefer* the gray background [which, despite Kent's comment to
the contrary, is *still* what I see with my browsers on both the
ALU & LispWorks sites, but *not* at Franz's -- go figure].
4. I *prefer* the "long" filenames, since I have a little personal/local
web-based CGI "grep" tool [though written in CL, not shell] that does
pattern matches against the v4 filenames. [The "8.3" filenames on v.7
(LispWorks) are *way* too short to do any meaningful matches on. Ugh.]
And since the old Harlequin version (v4?) is what I have on my laptop,
when I find a page locally it's just an exchange of URL prefix to
convert my local URL to a globally-accessible URL on the ALU site.
5. And last but not least, it seemed to be somewhat of an imposition
for us to *always* be beating up on LispWorks's web server, when
we could spread the bandwidth load around a bit. [And the ALU server
certainly was never very busy...]
Perhaps the "right" answer is to upload all three versions to some
neutral, "permanent", super-high-bandwidth site [SourceForge? GoogleCode?
other?] and offer a choice from a meta-cover page, maybe along with
a file (sexp, natch!) which relates the filenames of all three [or
more, if more variants are desired], e.g.:
...
((:franz_6.2 "dictentr/standard.htm")
(:harlequin_v4 "Body/typ_standard-char.html")
(:lispworks_v6 "Body/t_std_ch.htm"))
...
Then people could easily translate from one format to the other.
+---------------
| Also, I got a complaint from someone who was dyslexic who said that a
| a partial "workaround" for that problem is to view things in high
| contrast, and who pleaded with me not to put it on a gray background.
| That's why it's on white these days, although it may just look like an
| artistic choice--certainly there's very little text-on-gray in the
| modern world compared to when the web was new. I do personally find
| the white background easier to read.
+---------------
I don't, as I said above. Only the Franz version shows up with a
white background in the browsers I use.
+---------------
| > It also makes clearer that (the predecessors of) LispWorks - and not
| > the ALU - paid for the generation of the HyperSpec, own the rights to
| > it, and made it publicly available.
|
| LispWorks Ltd. presumably had to pay to acquire the assets they now
| enjoy, of course, so I think it's right and proper to say they paid for it.
+---------------
But the ALU version gives full credit to Harlequin on every page!
Didn't Harlequin pay for the production of that version? (v4?)
+---------------
| I do agree that having the site continue to point through to Harlequin
| is not fair to the people that made it, though.
+---------------
What does "point through" mean, here? You mean the clickable Harlequin
logo in the upper-left-corner of each page? It only "points through"
if you click it -- the image itself is local to wherever the CLHS mirror
is hosted. [And if you *do* click it (though why would you?), it gets
redirected to <http://www.globalgraphics.com/>, heh.]
+---------------
| I have said in the past and I will say again: The correct solution to
| alu.org remaining vendor-neutral is for it to ALSO host other vendors'
| documentation (e.g., Franz's alternate spec) if it wants to do that,
| and to let individuals choose which to reference.
+---------------
'Kay, fine. (See above.)
+---------------
| But it does as it stands have the vague look of something that is
| trying hard to not acknowledge that Harlequin is no longer there
| and is trying hard not to accept that LispWorks is a viable vendor,
| making money, trying to solicit customers, and paying their dues...
+---------------
Whoa! IMHO, you're reading *way* to much into the situation if
you're imputing that anybody is "trying hard" to do *anything*!!
Nobody's "trying" to acknowledge or *not* acknowledge anything
other than the text as it stands, which is unaltered from the date
the tarball was fetched. It's a totally passive historical accident.
A openly-copyable snapshot was taken at one point in time, and
nothing different is being "represented" by anyone as far as I know.
No hidden agendas in favor or against open-source, at least, not
in the CLHS sub-tree.
[I will not speak to the tone of the rest of the ALU site, other than
to note that <http://www.cliki.net/index> says that "Non-Free...resources
can be found at the ALU wiki <http://wiki.alu.org/>", implying that
the ALU site *isn't* as exclusively open-source oriented as the CLiki.
Likewise, <http://wiki.alu.org/Implementation> mentions a full panoply
of both commercial vendors & open-source projects.]
+---------------
| So I join with Edi in publicly requesting that someone fix the ALU
| web site.
+---------------
If by "fix" you mean put all three versions up there with a
meta-cover page, then that sounds like a good idea in any case.
I'll talk to the chief maintainer and see what has to be done
to make it happen...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
O.k., so Kenny's had his LOGBITP moment ["Why wasn't I told about
logbitp?"] and his MAPHASH/REMHASH moment ["What Part of Unspecified
Does Kenny Not Understand?"]...
Well, now it's my turn: Why didn't anyone tell me about [or more
honestly, why didn't I ever notice] the "Data/" subdirectory in the
CLHS distribution?!? Sheesh! And all this time I've been fighting
a non-problem! ;-} ;-}
Background/Explanation: Yesterday, in the thread "Re: What Part
of Unspecified Does Kenny Not Understand?" [which at the point of
my reply had actually morphed into a discussion about versions
of the CLHS and which ones people should/should_not link to],
I wrote the following:
rpw3 said:
+---------------
| 4. I *prefer* the "long" filenames, since I have a little personal/local
| web-based CGI "grep" tool [though written in CL, not shell] that does
| pattern matches against the v4 filenames. [The "8.3" filenames on v.7
| (LispWorks) are *way* too short to do any meaningful matches on. Ugh.]
| And since the old Harlequin version (v4?) is what I have on my laptop,
| when I find a page locally it's just an exchange of URL prefix to
| convert my local URL to a globally-accessible URL on the ALU site.
...
| Perhaps the "right" answer is to upload all three versions to some
| neutral, "permanent", super-high-bandwidth site...and offer a choice...
| maybe along with a file...which relates the filenames of all three...e.g.:
| ...
| ((:franz_6.2 "dictentr/standard.htm")
| (:harlequin_v4 "Body/typ_standard-char.html")
| (:lispworks_v6 "Body/t_std_ch.htm"))
| ...
| Then people could easily translate from one format to the other.
+---------------
[Where by "translate" I really meant "translate between the
filename(s) used in one CLHS version for one (or more) topic(s) into
the filename(s) used in a different version for the same topic(s)".]
Well, in some sidebar mail, Kent Pitman has kindly directed my
attention to these three files in the current Lispworks version
of the CLHS:
http://www.lispworks.com/documentation/HyperSpec/Data/Map_Sym.txt
http://www.lispworks.com/documentation/HyperSpec/Data/Map_IssW.txt
http://www.lispworks.com/documentation/HyperSpec/Data/Map_IssX.txt
And sure enough, the old v.4 CLHS on my laptop also has the same three,
albeit with different names:
.../HyperSpec/Data/Symbol-Table.text
.../HyperSpec/Data/Issue-Writeups.text
.../HyperSpec/Data/Issue-Cross-Refs.text
where the first such file has entries of this sort, for "Data/Map_Sym.txt":
DEFVAR
../Body/m_defpar.htm
DELETE
../Body/f_rm_rm.htm
DELETE-DUPLICATES
../Body/f_rm_dup.htm
DELETE-FILE
../Body/f_del_fi.htm
and for the older "Data/Symbol-Table.text":
DEFVAR
../Body/mac_defparametercm_defvar.html
DELETE
../Body/fun_removecm__elete-if-not.html
DELETE-DUPLICATES
../Body/fun_remove-du_e-duplicates.html
DELETE-FILE
../Body/fun_delete-file.html
In either case, using this file is a *much* better thing to do
than trying to search by pattern matching on the filenames as
I'd been doing in the past [as noted in #4 above]. So now I can
get even *better* matching with something as simple as this:
(let ((symbol-file-map
(file-lines (strcat +clhs-base+ "Data/Symbol-Table.text"))))
(with-html-output (s *standard-output* t)
(loop for (sym file) on symbol-file-map by #'cddr
when (search pat sym :test #'char-equal)
do (let ((url (strcat "file://" +clhs-base+ (subseq file 3))))
(htm (:a (:href url) sym) (lfd))))))
E.g., for an input of "mis" it would output:
<A HREF='file:///u/rpw3/file/doc/HyperSpec/Body/var_stprint-miser-widthst.html'>*PRINT-MISER-WIDTH*</A>
<A HREF='file:///u/rpw3/file/doc/HyperSpec/Body/fun_mismatch.html'>MISMATCH</A>
<A HREF='file:///u/rpw3/file/doc/HyperSpec/Body/stagenfun_slot-missing.html'>SLOT-MISSING</A>
And now I can migrate to v.7 without losing my favorite tool!!
Done. End of story. "D'oh!! Oh what a maroon I've been!" ;-} ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On 16 May, 04:02, ····@rpw3.org (Rob Warnock) wrote:
> Well, now it's my turn: Why didn't anyone tell me about [or more
> honestly, why didn't I ever notice] the "Data/" subdirectory in the
> CLHS distribution?!? Sheesh! And all this time I've been fighting
> a non-problem! ;-} ;-}
> Done. End of story. "D'oh!! Oh what a maroon I've been!" ;-} ;-}
As have I! I wrote a throwaway to index the CLHS so that I could
associate relative paths with each symbol in order to load the path as
a 'metadata' field onto the symbols entry in my ternary search
tree...all in order to provide hyperspec lookup in ABLE.
So regarding Edi's comment, by not reviewing prior efforts I've done
far worse as I was implementing exactly the same thing!
--
Phil
http://phil.nullable.eu/
On Thu, 15 May 2008 22:02:00 -0500, ····@rpw3.org (Rob Warnock) wrote:
> Well, now it's my turn: Why didn't anyone tell me about [or more
> honestly, why didn't I ever notice] the "Data/" subdirectory in the
> CLHS distribution?!? Sheesh! And all this time I've been fighting a
> non-problem! ;-} ;-}
You should have looked at one of the various CLHS lookup facilities
that have existed for years (I almost said "decades") like the ones
for ILISP, SLIME, LW-ADD-ONS, etc.
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) wrote:
| > Well, now it's my turn: Why didn't anyone tell me about [or more
| > honestly, why didn't I ever notice] the "Data/" subdirectory in the
| > CLHS distribution?!? Sheesh! And all this time I've been fighting a
| > non-problem! ;-} ;-}
|
| You should have looked at one of the various CLHS lookup facilities
| that have existed for years (I almost said "decades") like the ones
| for ILISP, SLIME, LW-ADD-ONS, etc.
+---------------
Umm, well... Yes, I probably should have, except that I'm not an
Emacs user[1] and therefore tend not to look at Emacs-based tools.
-Rob
[1] Dinna fash yersel aboot it. As noted previously, I've tried
several times, but it just doesn't work with my fingers. But
even for a benighted Vi user, Lisp is still the cat's pajamas...
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> O.k., so Kenny's had his LOGBITP moment ["Why wasn't I told about
> logbitp?"] and his MAPHASH/REMHASH moment ["What Part of Unspecified
> Does Kenny Not Understand?"]...
>
> Well, now it's my turn: Why didn't anyone tell me about [or more
> honestly, why didn't I ever notice] the "Data/" subdirectory in the
> CLHS distribution?!? Sheesh! And all this time I've been fighting
> a non-problem! ;-} ;-}
Lemme join in. I have spent several hours with a strange bug ... until
I found that bit in the hyperspec:
"sort and stable-sort destructively sort sequences"
Why the heck isn't it called *nsort*?
Oh well,
Peter
> Background/Explanation: Yesterday, in the thread "Re: What Part
> of Unspecified Does Kenny Not Understand?" [which at the point of
> my reply had actually morphed into a discussion about versions
> of the CLHS and which ones people should/should_not link to],
> I wrote the following:
>
> rpw3 said:
> +---------------
> | 4. I *prefer* the "long" filenames, since I have a little personal/local
> | web-based CGI "grep" tool [though written in CL, not shell] that does
> | pattern matches against the v4 filenames. [The "8.3" filenames on v.7
> | (LispWorks) are *way* too short to do any meaningful matches on. Ugh.]
> | And since the old Harlequin version (v4?) is what I have on my laptop,
> | when I find a page locally it's just an exchange of URL prefix to
> | convert my local URL to a globally-accessible URL on the ALU site.
> ....
> | Perhaps the "right" answer is to upload all three versions to some
> | neutral, "permanent", super-high-bandwidth site...and offer a choice...
> | maybe along with a file...which relates the filenames of all three...e.g.:
> | ...
> | ((:franz_6.2 "dictentr/standard.htm")
> | (:harlequin_v4 "Body/typ_standard-char.html")
> | (:lispworks_v6 "Body/t_std_ch.htm"))
> | ...
> | Then people could easily translate from one format to the other.
> +---------------
>
> [Where by "translate" I really meant "translate between the
> filename(s) used in one CLHS version for one (or more) topic(s) into
> the filename(s) used in a different version for the same topic(s)".]
>
> Well, in some sidebar mail, Kent Pitman has kindly directed my
> attention to these three files in the current Lispworks version
> of the CLHS:
>
> http://www.lispworks.com/documentation/HyperSpec/Data/Map_Sym.txt
> http://www.lispworks.com/documentation/HyperSpec/Data/Map_IssW.txt
> http://www.lispworks.com/documentation/HyperSpec/Data/Map_IssX.txt
>
> And sure enough, the old v.4 CLHS on my laptop also has the same three,
> albeit with different names:
>
> .../HyperSpec/Data/Symbol-Table.text
> .../HyperSpec/Data/Issue-Writeups.text
> .../HyperSpec/Data/Issue-Cross-Refs.text
>
> where the first such file has entries of this sort, for "Data/Map_Sym.txt":
>
> DEFVAR
> ../Body/m_defpar.htm
> DELETE
> ../Body/f_rm_rm.htm
> DELETE-DUPLICATES
> ../Body/f_rm_dup.htm
> DELETE-FILE
> ../Body/f_del_fi.htm
>
> and for the older "Data/Symbol-Table.text":
>
> DEFVAR
> ../Body/mac_defparametercm_defvar.html
> DELETE
> ../Body/fun_removecm__elete-if-not.html
> DELETE-DUPLICATES
> ../Body/fun_remove-du_e-duplicates.html
> DELETE-FILE
> ../Body/fun_delete-file.html
>
> In either case, using this file is a *much* better thing to do
> than trying to search by pattern matching on the filenames as
> I'd been doing in the past [as noted in #4 above]. So now I can
> get even *better* matching with something as simple as this:
>
> (let ((symbol-file-map
> (file-lines (strcat +clhs-base+ "Data/Symbol-Table.text"))))
> (with-html-output (s *standard-output* t)
> (loop for (sym file) on symbol-file-map by #'cddr
> when (search pat sym :test #'char-equal)
> do (let ((url (strcat "file://" +clhs-base+ (subseq file 3))))
> (htm (:a (:href url) sym) (lfd))))))
>
> E.g., for an input of "mis" it would output:
>
> <A HREF='file:///u/rpw3/file/doc/HyperSpec/Body/var_stprint-miser-widthst.html'>*PRINT-MISER-WIDTH*</A>
> <A HREF='file:///u/rpw3/file/doc/HyperSpec/Body/fun_mismatch.html'>MISMATCH</A>
> <A HREF='file:///u/rpw3/file/doc/HyperSpec/Body/stagenfun_slot-missing.html'>SLOT-MISSING</A>
>
> And now I can migrate to v.7 without losing my favorite tool!!
>
> Done. End of story. "D'oh!! Oh what a maroon I've been!" ;-} ;-}
>
>
> -Rob
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
>
Rob Warnock wrote:
> 3. I *prefer* the gray background [which, despite Kent's comment to
> the contrary, is *still* what I see with my browsers on both the
> ALU & LispWorks sites, but *not* at Franz's -- go figure].
>
I have my browser defaulting to grey background too (white is
Just Wrong on emissive displays - most screens are not paper-like!) -
When Kent said he made it white, I guess he meant he stopped making it
another colour explicitly somewhere, and assumed browsers defaulted to
white (which they do out-of-box, but it's a configurable user
preference).
I think that's the best solution really for such large volumes of text -
don't muck with people's own choice of colors, they've probably picked
them for comfortable reading (same reason my emacs is yellow on dark
blue - that tends muck up web pages more than white->gray though)
From: Kent M Pitman
Subject: Re: What Part of Unspecified Does Kenny Not Understand?
Date:
Message-ID: <uprrn9lgf.fsf@nhplace.com>
David Golden <············@oceanfree.net> writes:
> When Kent said he made it white, I guess he meant he stopped making it
> another colour explicitly somewhere, and assumed browsers defaulted to
> white (which they do out-of-box, but it's a configurable user
> preference).
I had actually remembered setting it to white, but didn't go check.
You're right that the latest version doesn't specify; the style sheet
it offers is pretty minimal and mostly just sets a couple of things
for color matching with the LispWorks Ltd. logos, leaving the rest to
user preferences.
> I think that's the best solution really for such large volumes of text -
> don't muck with people's own choice of colors, they've probably picked
> them for comfortable reading (same reason my emacs is yellow on dark
> blue - that tends muck up web pages more than white->gray though)
I agree.
From: Kent M Pitman
Subject: Re: What Part of Unspecified Does Kenny Not Understand?
Date:
Message-ID: <ufxslefnl.fsf@nhplace.com>
···················@SpamGourmet.Com (Robert Maas, http://tinyurl.com/uh3t) writes:
> > > CLHS 18.2.11 maphash:
> > > "...The consequences are unspecified if any attempt is made to add or
> > > remove an entry from the hash-table while a maphash is in progress,
> > > with two exceptions: the /function/ can...use remhash to remove that
> > > entry."
> > From: Juho Snellman <······@iki.fi>
> > The difference is between "an entry" and "that entry". You may
> > remove the key that the function was called with, you may not
> > remove any other keys.
>
> That's my understanding too. I'm 99% sure KMP will agree.
Not that it matters at this point. My opinion carries no additional formal
weight. But yes, that's the way I read the text.
> CLtL1 is more clear, but has a typo: Manually typing in from printed page:
> "with one [sic] exception: if the function calls REMHASH to remove
> the entry currently being processed by the function, or performs a
> SETF of GETHASH on that entry to change the associated value."
> The important more-clear phrase is "the entry currently being processed".
> I wonder why KMP changed the language in the HyperSpec to be ever
> so slightly less obviously clear than how Steele had explained the
> same thing? Maybe KMP thought the new wording was less
> wordy/verbose/redundant/overkill/forDummies?
Probably brevity. But I don't have a specific recollection.
FWIW, it doesn't look ambiguous to me. "that entry" is a definite
reference and implies a uniquely determined referent. In maphash, the
only two materially possible referents are to the entire set of
elements and to the object currently under consideration by the
function. So the latter prevails in my personal dialect. If you know
of another materially interesting interpretation, I'm curious.