[Openmcl-devel] Side effects when redefining dispatching reader macro?

[Gary Byers]

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
a lisp process.  There may be many ways of doing that

I don't know of any way in which readtable behavior is thread-specific.  
If the workaround that you use works for you
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
does.  I think that I understand  that.  Honest.


I rarely use SLIME .  I believe the following to be essentially correct 
and would appreciate being corrected if I am
mistaken about that

  A binding is an association/mapping between a variable name and some 
value, the bindings of special variables
in CCL can be thought of as being either static or dynamic. Dynamic 
bindings are established by LET/LET*, LAMBDA,
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
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
that variable in the thread in which the reference or assignment occurs.

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
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
for which dynamic bindings have been established in one thread does not 
change the values associated with bindings in other threads.

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
often the case that the values associated with those bindings involve 
the same objects.  Other implementations may use a different
model, where it is meaningful for a binding to be shared between a 
thread and the thread that created it.

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,
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
thread that is created by C-M-X.

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
the entire larger form is executed in the same thread.


On 11/12/2015 04:11 PM, Robert Cram wrote:
> 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.
>
> - Bob
>
> Bob Cram
> Robert Cram Construction
> www.robertcramconstruction.com <http://www.robertcramconstruction.com>
> 415-613-8319
> robert at robertcramconstruction.com 
> <mailto:robert at robertcramconstruction.com>
> CA LIC 965300
>
>> On Nov 12, 2015, at 2:27 PM, Gary Byers <gb at clozure.com 
>> <mailto:gb at clozure.com>> wrote:
>>
>>
>>
>> On 11/12/2015 11:37 AM, Ron Garret wrote:
>>> (MAKE-DISPATCH-MACRO-CHARACTER #\# NIL*readtable*)
>> CLHS says (of MAKE-DISPATCH-MACRO-CHARACTER) that,
>>
>> "Initially, every /character/ 
>> <http://www.lispworks.com/documentation/lw50/CLHS/Body/26_glo_c.htm#character> 
>> in the dispatch table associated with the /char/ has an associated 
>> function that signals an error of /type/ 
>> <http://www.lispworks.com/documentation/lw50/CLHS/Body/26_glo_t.htm#type> 
>> *reader-error* 
>> <http://www.lispworks.com/documentation/lw50/CLHS/Body/e_rder_e.htm#reader-error>."
>>
>> In the body of your message, you seemed to expect #' to have retained 
>> its original definition.
>>
>> 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 ...",
>> 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.
>>
>> 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.
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com <mailto:Openmcl-devel at clozure.com>
>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20151113/2bdbe1f6/attachment.htm>