00:01 <nij-> standard: "The set of special operator names is fixed in Common Lisp; no way is provided for the user to define a special operator. " The set of special operator names is fixed in Common Lisp; no way is provided for the user to define a special operator.

00:01 <nij-> Oops Double post. I meant - http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_3-1-2-1-2-1.html#clspecialops

00:01 <ixelp> CLHS: Section 3.1.2.1.2.1

00:02 <nij-> So the standard bans the implementation from giving the user option to define new special ops.. I wonder if the implementation can provide more special ops though.

00:21 <bike> implementations can and do provide other special operators

00:25 <nij-> I see..

00:32 <bike> i don't know how useful a special operator like that would be though, compared to just having an eval function with an environment parameter

00:33 <bike> kernel has a similar special operator called $remote-eval or something, and part of the idea was to use it to e.g. evaluate code in a standard environment a la with-standard-io-syntax, but i don't know how practically useful that is

01:33 <nij-> Does it mean "some" rather than "any" in "interned adj. Trad. 1. (of a symbol) accessible in any package." ? https://novaspec.org/cl/26_1_Glossary#interned

01:33 <ixelp> 26.1 Glossary | Common Lisp Nova Spec

01:34 <gilberth> That's a grammar question.

01:35 <nij-> Sorry for my bad grammar. English isn't my native. But this reads to me like it saying the symbol is accessible in *every* package.

01:37 <gilberth> Neither is it mine. But no, I don't think that "any" would imply every.

01:38 <gilberth> Consider a questions: "Is FOO accessible in any package?" "Yes, it is accessible from CL-USER, but not from FANCY-PACKAGE."

01:48 <nij-> Grammar sites and LLM suggest any means one or more. Ok.. so that's fine. Sorry!

01:53 <gilberth> I was more referring to to my ears a sentence like "I have any apples, I should make an apple pie." sounds wrong while "I have some apples." sounds right.

01:55 <gilberth> I believe negation implies "any". "I don't have any apples, so I cannot make an apple pie." sounds ok. While "I don't have some apples." sounds odd. Maybe someone better at English than me could clarify.

02:59 <nij-> I remember seeing "any" used in an affirmative English sentence. But it doesn't show up quite often nowadays, at least in verbal english.

03:02 <paulapatience> gilberth's ear is good.

03:03 <paulapatience> One example where any strongly suggests all would be: My code works with any compiler.

03:05 <paulapatience> But it is indeed a source of ambiguity.

03:21 <nij-> Can a symbol be interned in two packages simultaneously?

03:25 <nij-> Oh yes - "the same symbol can be interned in more than one package." Sorry this is a stupid question.

03:25 <nij-> https://novaspec.org/cl/t_symbol

03:25 <ixelp> symbol | Common Lisp Nova Spec

03:25 <nij-> Oh.. that's what 'USE does.

03:26 <gilberth> Nope.

03:26 <gilberth> You would need to "import" a symbol to make it interned in some other package than its home package.

03:27 <gilberth> Look at the second return value of https://novaspec.org/cl/f_find-symbol

03:27 <ixelp> find-symbol | Common Lisp Nova Spec

03:28 <nij-> !! I see. Thanks

03:29 <nij-> This is a nuance that I think I will easily forget again..

03:29 <gilberth> This use list as with :USE in defpackage is more like a search path.

03:30 <nij-> Yep..

03:30 <nij-> Why does the standard differ these two?

03:30 <nij-> How is such seperation useful?

03:31 <gilberth> Because that are different things. Begins with that to refer to symbols in used packages (without a package qualifier) would only work if that symbol is exported. And the used package can also change.

03:32 <gilberth> And of course when you use a package you use all symbol exported symbols from that package.

03:33 <gilberth> You might however want to only import one specific symbol from another package. Or a few.

03:33 <gilberth> So both have it uses.

03:34 <nij-> I see.

07:10 <younder> beach: All implementation's I have looked at use a copy-on-write approach to multi-threading. Has this been addressed in the updated spec?

07:15 <younder> I mean for a global environment.

07:26 <beach> That would be very strange.

07:26 <beach> So if you do (defun foo ...) in one thread, the function foo will not be defined in a different thread?

07:29 <younder> heh?

07:29 <beach> And, the only "updated spec" I know of is WSCL, and I think multiple threads would be way too hard for WSCL, at least initially.

07:30 <beach> younder: DEFUN does a (setf (fdefinition ...)) which writes to the global environment, so if it is then first copied, the function won't be seen in other threads.

07:33 <beach> Besides, no current Common Lisp implementation has an object representing the global environment, so to write-protect it that way would mean write-protecting almost the entire system.

07:34 <younder> We must be talking past each other. How do you deal with a dynamic variable (usually global) in a thread. You just read the global one. It is fine if all threads do is read them. But what happens on write? You make a thread local copy and write to that. This can all be made to work as long as you check if there is a thread local copy first and on fail fallback on reading the global (top process) one.

07:35 <beach> I believe that in all current Common Lisp implementations with threads, the global bindings is shared between all the threads.

07:36 <beach> And if you are not talking about the global value, and instead you are referring to a thread-local binding of it, then you are not using the global environment.

07:36 <younder> I mean that is what dynamic binding does anyhow even in a single thread.

07:37 <beach> If the variable is locally bound, then writing to it does not affect the global environment.

07:38 <beach> How the dynamic environment is represented is outside the scope of any specification anyway, let alone WSCL.