<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I am using C-M-X below to refer to whatever Emacs key binding is
used to send a selection from an editor buffer to<br>
a lisp process. There may be many ways of doing that<br>
<br>
I don't know of any way in which readtable behavior is
thread-specific. If the workaround that you use works for you<br>
and may work for others, It may not matter to anyone involved why it
works, or it may matter a lot less than I think it<br>
does. I think that I understand that. Honest.<br>
<br>
<br>
I rarely use SLIME . I believe the following to be essentially
correct and would appreciate being corrected if I am<br>
mistaken about that<br>
<br>
A binding is an association/mapping between a variable name and
some value, the bindings of special variables<br>
in CCL can be thought of as being either static or dynamic. Dynamic
bindings are established by LET/LET*, LAMBDA,<br>
and a few other things. They are always thread-specific, and the
effect of LET et al is to establish a new dynamic binding and make
it current<br>
in the thread in which it occurs. A reference of or assignment to a
special variable returns or modifies the value of the current
binding of<br>
that variable in the thread in which the reference or assignment
occurs.<br>
<br>
When a thread is first created, it has no dynamic bindings and its
current binding for any special variable is a static one which is
shared by all threads which<br>
have not yet established thread-private dynamic bindings. Soon
after the thread is created and before it executes its initial
function, dynamic bindings are created for many special variables
(especially things related to I/O). Changing the value to which
*PACKAGE*, *READTABLE* or any of the other variables<br>
for which dynamic bindings have been established in one thread does
not change the values associated with bindings in other threads.<br>
<br>
There is in general no relationship between the bindings established
in a thread and those established in its parent (whatever thread
created it), though it is<br>
often the case that the values associated with those bindings
involve the same objects. Other implementations may use a different<br>
model, where it is meaningful for a binding to be shared between a
thread and the thread that created it. <br>
<br>
By default, SLIME creates a new thread every time it tries to
execute a form via C-M-X or similar means. This often causes
confusion,<br>
because assignments to things made in one thread (created by C-M-X)
do not persist and do not affect the bindings visible to the next<br>
thread that is created by C-M-X.<br>
<br>
The workaround that you suggest suggest - using C-M-X to send a
PROGN or function definition to Lisp - works as well as it does
because<br>
the entire larger form is executed in the same thread. <br>
<br>
<br>
<div class="moz-cite-prefix">On 11/12/2015 04:11 PM, Robert Cram
wrote:<br>
</div>
<blockquote
cite="mid:6FCD8536-E1DD-487B-A87B-584E34D4F91B@robertcramconstruction.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Well above my (very low) LISP pay grade, but I note that slime was
mentioned. I had problems with named read-tables in one of the
database libraries, in slime, found that read-table behavior was
thread-specific, and that each statement executed at a separate
prompt in slime was running in a separate thread. Your last
statement may know nothing about the read table environment set up
in the prior one. Combining into a function or progn or the like
solved the problem for me. Don’t know if that makes any sense or
is helpful, but thought I’d throw it out there.
<div class=""><br class="">
</div>
<div class="">- Bob</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">
<div class="">Bob Cram</div>
<div class="">Robert Cram Construction</div>
<div class=""><a moz-do-not-send="true"
href="http://www.robertcramconstruction.com" class="">www.robertcramconstruction.com</a></div>
<div class="">415-613-8319</div>
<div class=""><a moz-do-not-send="true"
href="mailto:robert@robertcramconstruction.com" class="">robert@robertcramconstruction.com</a></div>
<div class="">CA LIC 965300</div>
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Nov 12, 2015, at 2:27 PM, Gary Byers <<a
moz-do-not-send="true" href="mailto:gb@clozure.com"
class=""><a class="moz-txt-link-abbreviated" href="mailto:gb@clozure.com">gb@clozure.com</a></a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> <br
class="">
<br class="">
<div class="moz-cite-prefix">On 11/12/2015 11:37 AM, Ron
Garret wrote:<br class="">
</div>
<blockquote
cite="mid:0736676C-3D3A-4F1C-9D7E-108FF3EB8B84@flownet.com"
type="cite" class="">
<pre class="" wrap="">(MAKE-DISPATCH-MACRO-CHARACTER #\# NIL <b class="moz-txt-star"><span class="moz-txt-tag">*</span>readtable<span class="moz-txt-tag">*</span></b>)</pre>
</blockquote>
CLHS says (of MAKE-DISPATCH-MACRO-CHARACTER) that,<br
class="">
<br class="">
"Initially, every <a moz-do-not-send="true"
rel="DEFINITION"
href="http://www.lispworks.com/documentation/lw50/CLHS/Body/26_glo_c.htm#character"
class=""><i class="">character</i></a> in the dispatch
table associated with the <i class="">char</i> has an
associated function that signals an error of <a
moz-do-not-send="true" rel="DEFINITION"
href="http://www.lispworks.com/documentation/lw50/CLHS/Body/26_glo_t.htm#type"
class=""><i class="">type</i></a> <a
moz-do-not-send="true" rel="DEFINITION"
href="http://www.lispworks.com/documentation/lw50/CLHS/Body/e_rder_e.htm#reader-error"
class=""><b class="">reader-error</b></a>."<br
class="">
<br class="">
In the body of your message, you seemed to expect #' to
have retained its original definition.<br class="">
<br class="">
If the term "... makes char be a
dispatching-macro-character ..." is read as "does
nothing if the character is already defined as a
dispatching-macro, else ...",<br class="">
your expectation is reasonable. I am probably more
accustomed to the behavior that that you said that you
get in 1.10, but both expectations seem reasonable.<br
class="">
<br class="">
Portable code could avoid the issue by calling
GET-DISPATCH-MACRO-CHARACTER and only calling
MAKE-DISPATCH-MACRO-CHARACTER if the character is not
already defined as a dispatching macro. I don't know
what the library that the original poster mentioned
does. or what version of that library they are using.<br
class="">
</div>
_______________________________________________<br
class="">
Openmcl-devel mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:Openmcl-devel@clozure.com" class="">Openmcl-devel@clozure.com</a><br
class="">
<a class="moz-txt-link-freetext" href="https://lists.clozure.com/mailman/listinfo/openmcl-devel">https://lists.clozure.com/mailman/listinfo/openmcl-devel</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openmcl-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a>
<a class="moz-txt-link-freetext" href="https://lists.clozure.com/mailman/listinfo/openmcl-devel">https://lists.clozure.com/mailman/listinfo/openmcl-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>