lucasta has quit [Remote host closed the connection]
akoana has quit [Quit: leaving]
jonatack has joined #commonlisp
benjaminl has quit [Remote host closed the connection]
ad-absurdum has joined #commonlisp
benjaminl has joined #commonlisp
puke has quit [Remote host closed the connection]
puke has joined #commonlisp
kevingal has quit [Remote host closed the connection]
kevingal_ has quit [Remote host closed the connection]
<char>
Is there a practical difference between returning (values) vs nil?
<paulapatience>
Not really, (values) is treated as NIL when passed as argument
<paulapatience>
The difference is visible just in the REPL
<thuna`>
MULTIPLE-VALUE-CALL and MULTIPLE-VALUE-LIST are probably the only two which care about the difference
<thuna`>
And the REPL too, yeah
ryanbw has quit [Quit: I'll be back.]
jon_atack has joined #commonlisp
jonatack has quit [Ping timeout: 264 seconds]
jon_atack has quit [Ping timeout: 256 seconds]
istewart has joined #commonlisp
char has left #commonlisp [Leave.]
char has joined #commonlisp
reb`` has quit [Ping timeout: 264 seconds]
char has quit [Ping timeout: 264 seconds]
NotThatRPG_ has joined #commonlisp
NotThatRPG has quit [Read error: Connection reset by peer]
reb`` has joined #commonlisp
jonatack has joined #commonlisp
<beach>
Gleefre: You must have some kind of agent between "allow" and "to" in English, for instance "allow the programmer to" or "allow the user to". If you want to avoid the agent, you can rewrite the phrase, say "Package-local nicknames make it possible to use...".
<beach>
Gleefre: "name conflict" is a singular noun, so it must have an article in English. So either "introducing a name conflict" or "introducing name conflicts".
ad-absurdum has quit [Ping timeout: 268 seconds]
<beach>
Gleefre: I think there is the same problem in the first sentence of the Description section. Perhaps "A package-local nickname (or local nickname) ..."
ad-absurdum has joined #commonlisp
<beach>
Gleefre: "Local nickname is allowed to" => "A local nickname is allowed to"
<beach>
Gleefre: "make-package lambda list" => "The make-package lambda list"
amb007 has joined #commonlisp
decweb has quit [Ping timeout: 240 seconds]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
<beach>
I don't recall seeing the error terminology "must be signaled". Maybe just "is signaled".
<beach>
Gleefre: I would try to be consistent between US and UK English. The text uses UK spelling "behaviour", but US spelling "signaled".
<beach>
Gleefre: "a style warning might signaled" => "a style warning might be signaled"
<beach>
Gleefre: I recommend that you avoid the use of the genitive 's for non-proper nouns and instead us the "of" construct, so I would replace "If NICKNAME shadows the DESIGNATED-PACKAGE'S package name or one of its global nicknames" by "If NICKNAME shadows the package name or one of the global nicknames of the DESIGNATED-PACKAGE".
<beach>
Gleefre: "When argument to find-package" => "When the argument to find-package"
<beach>
Gleefre: "the FORMAT's tilde slash directive" => "the tilde slash directive of FORMAT"
<beach>
I'll try to do more later. I don't think I am able to have opinions on the essence of the proposal, though. So I encourage others to proofread as well.
jonatack has quit [Ping timeout: 264 seconds]
triffid has quit [Remote host closed the connection]
triffid has joined #commonlisp
msv has quit [Remote host closed the connection]
msv has joined #commonlisp
istewart has quit [Quit: Konversation terminated!]
zxcvz has joined #commonlisp
zxcvz has quit [Client Quit]
NotThatRPG_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
char has joined #commonlisp
emaczen has quit [Ping timeout: 255 seconds]
deadmarshal_ has quit [Ping timeout: 268 seconds]
<beach>
Though perhaps I should add that it is preferable to have as much behavior as possible specified. So if the implementations agree on some behavior that is currently said to be undefined or unspecified, I would encourage you make that behavior specified.
bilegeek has quit [Quit: Leaving]
ad-absurdum has quit [Remote host closed the connection]
attila_lendvai has quit [Ping timeout: 268 seconds]
dawids_ has joined #commonlisp
dawids_ has quit [Remote host closed the connection]
dino_tutter has joined #commonlisp
amb007 has quit [Ping timeout: 260 seconds]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
attila_lendvai has joined #commonlisp
<mrcom>
Code style RFO (request for opinion): Using (SETF) to set properties with moderately complex semantics.
<mrcom>
For example, (setf (foo-origin foo-thing) (list x y)), where we want to snap the coords to a grid.
<mrcom>
How much tweaking of the value by setf is polite?
McParen has joined #commonlisp
<mrcom>
Or (setf (foo-scale ft) value), where value could be a scalar, or a list of scale factor and x & y origin, and scale could be a real or zoom-in/zoom-out.
<mrcom>
Too contorted for setf?
<mrcom>
On the one hand, "(setf (foo-scale obj) '+)" is .... hm. Handy but unpleasant to look at?
<mrcom>
"(incf (foo-scale obj))" would be very handy.
<mrcom>
On the other hand, smells like C++ operator overloading.
kopiyka has quit [Remote host closed the connection]
kopiyka has joined #commonlisp
McParen has left #commonlisp [#commonlisp]
<mrcom>
Thinking about it, (setf baz '+) as some kind of incf is an abomination.
ad-absurdum has joined #commonlisp
asdf has quit [Remote host closed the connection]
inline has joined #commonlisp
inline is now known as Guest9895
Guest9895 is now known as inline
amb007 has quit [Ping timeout: 272 seconds]
amb007 has joined #commonlisp
inline has quit [Client Quit]
random-nick has joined #commonlisp
jrx has joined #commonlisp
cage has joined #commonlisp
<Gleefre>
beach: Thanks for the corrections! I think I have addressed them all in the main spec, as well as similar grammatical errors/inaccuracies; will fix them in the standardization issues next.
<Gleefre>
re unspecified / undefined behavior: some of those situations are addressed by the standardization issues; while the others might not necesseraly make sense to be specified, similar to how the ANSI standard leaves some things out, like an incompatible redefinition of a package.
McParen has joined #commonlisp
<beach>
Gleefre: Great!
<beach>
Gleefre: Yes, the ANSI standard leaves a lot out, which is why we are working on WSCL to specify most of the things left out.
<beach>
So it would be sad to write a new CDR that would then immediately be subject to several WSCL issues.
<beach>
mrcom: For one thing, I advise against prefixing the operators with the type of the object.
danza has joined #commonlisp
<mrcom>
beach: That's kind of a key point. Setf is _supposed_ to be a slot-access thing, not an operator.
<beach>
So?
<beach>
mrcom: And you get (INCF (SCALE OBJ)) for free if you have (SETF SCALE) defined, because (INCF (SCALE OBJ)) then turns into (SETF (SCALE OBJ) (1+ (SCALE OBJ))).
<mrcom>
Slot accessors are typically prefixed with the structure or class name, no?
<beach>
mrcom: You should not make a distinction between an operator that is also a slot accessor and an operator that is not. Doing so will make implementation details visible in the protocol.
<mrcom>
Oh, that's a good point.
<beach>
So SYMBOL-VALUE is a slot accessor? Hint: Nope!
<beach>
My guess is that this habit developed when the package system was still underused.
prokhor has quit [Ping timeout: 264 seconds]
<beach>
It is ugly and unnecessary, and I recommend against it in new application code.
prokhor has joined #commonlisp
* mrcom
ponders rowing against existing idiom.
<mrcom>
But things do change.
<beach>
It is ugly because, when you have subclasses, you get things like (in CLIM) (SHEET-REGION PANE)
<mrcom>
Putting that aside for now.. Regardless of function naming, there's an important mental divide between "I'm just setting a property" vs. "this does some stuff and sets things as side effects".
<beach>
... and not (PANE-REGION PANE). It should be just (REGION PANE).
<beach>
mrcom: That's an implementation decision that can change, so it should not be visible in the the protocol.
<mrcom>
That would take care of "I forget--is it WINDOW-foo, PANE-foo, or SHEET-foo." :)
<beach>
mrcom: Take (BOUNDING-RECTANGLE <object>). It should not be visible in the protocol whether the bounding rectangle is stored and just returned, or whether it is computed.
<beach>
And, in fact, it could change over time, as a result of decisions to cache things, for instance.
<beach>
You wouldn't want to rename an operator just because an implementation decision was made.
<mrcom>
No, but (SETF (BOUNDING-RECTANGLE ..) ) implies, conceptually, a dual with (BOUNDING-RECTANGLE ...). You put one in and get the same thing out.
<mesaoptimizer>
Just stumbled upon _Successful Lisp_. Seems like a very under-popularized book
<mrcom>
And, _conceptually_, nothing happens under the covers you really need to worry about.
<beach>
This convention is also not healthy as a mental divide. Take SYMBOL-VALUE, SYMBOL-FUNCTION, and SYMBOL-PLIST. They frequently make the programmer think that it is mandatory for a symbol to have slots for these things.
<McParen>
beach: is there a link for the WSCL i can take a look at?
<beach>
McParen: Sure, hold on...
Gleefre has quit [Ping timeout: 250 seconds]
<mrcom>
Conceptually, they do. The slots may be unbound or NIL, of course.
<mrcom>
beach: OK, you won your point, in this instance at least. I looked again at the task, and relaized most of the conceptual (and implementation) details are "verb" things, not "nouns" or "adjectives".
<mrcom>
In other words, just the op name.
<beach>
Great!
<mrcom>
And also correctly generalizing.
<beach>
mrcom: Did you want to ask or say something about the standard method combination?
mwnaylor has quit [Ping timeout: 268 seconds]
jonatack has joined #commonlisp
mwnaylor has joined #commonlisp
Devon has joined #commonlisp
loke has quit [Ping timeout: 252 seconds]
loke has joined #commonlisp
jonatack has quit [Ping timeout: 252 seconds]
ad-absurdum has quit [Ping timeout: 252 seconds]
amb007 has quit [Read error: Connection reset by peer]
<mrcom>
beach: No, sorry. sombody asked a question on #lisp and I couldn't remember how to get the lookup to work.
<beach>
I see.
ad_absurdum has joined #commonlisp
NotThatRPG_ has quit [Ping timeout: 256 seconds]
ad-absurdum has quit [Ping timeout: 255 seconds]
NotThatRPG has joined #commonlisp
NotThatRPG_ has joined #commonlisp
NotThatRPG has quit [Ping timeout: 268 seconds]
<Gleefre>
beach: [re PLN draft, language] I have fixed all grammatical errors/inaccuracies I could find in the issues section, and rewrote some sections, so hopefully it's more readable now :)
msv has quit [Remote host closed the connection]
King_julian has joined #commonlisp
NotThatRPG_ has quit [Ping timeout: 268 seconds]
NotThatRPG has joined #commonlisp
edgar-rft_ has joined #commonlisp
wacki has quit [Ping timeout: 264 seconds]
wacki has joined #commonlisp
ad-absurdum has joined #commonlisp
edgar-rft has quit [Ping timeout: 264 seconds]
ad_absurdum has quit [Ping timeout: 268 seconds]
lucasta has joined #commonlisp
<beach>
Gleefre: Great! I'll have a look later.
emaczen has joined #commonlisp
jonatack has quit [Ping timeout: 246 seconds]
hay has joined #commonlisp
ixelp has quit [Ping timeout: 256 seconds]
jonatack has joined #commonlisp
ixelp has joined #commonlisp
<thuna`>
Why are prog1 and prog2 specified as returning exactly one value instead of all the values? Seems like an odd decision to me
<thuna`>
s/one value/the first value/
awlygj has quit [Quit: leaving]
King_julian has quit [Ping timeout: 240 seconds]
<Gleefre>
For prog1 there is multiple-value-prog1.
<Gleefre>
[for prog1 but with multiple-values]
<thuna`>
Yeah, I am aware, but that's even more confusing, because why doesn't prog1 do that to begin with?
<mrcom>
Technical: m-v-progn is a special op. prog1 & prog2 are macros.
<thuna`>
m-v-prog1 can be a macro too: `(let ((#1=#:values (multiple-value-list ,first))) ,@body (values-list #1#))
<mrcom>
It's a bit more complicated than that.
<thuna`>
How so?
<mrcom>
Ask me how I know :)
<mrcom>
Ooh boy.. let me see if I can remember.
<mrcom>
One thing I member is return types. You lose them with the macro.
<thuna`>
What do you mean?
lucasta has quit [Remote host closed the connection]
lspangler has joined #commonlisp
<mrcom>
If you "(declaim (ftype (function (t) (values fixnum fixnum &optional))))"
<mrcom>
And wrap your function is ".... (multiple-value-list ,blah)"
<mrcom>
then the compiler has no idea if your function actually does the right thing.
<thuna`>
Hmm, I feel like that's a problem with the compiler rather than with the macro
<mrcom>
Non-local exits seem to ring a bell too.
<mrcom>
You want a compiler that keeps track of possible values for everything on a list??
<mrcom>
Me too.
<thuna`>
Non-locals are a problem, yeah. In the end I decided to make it not work with catch/throw and only with block/return[-from]
<mrcom>
It would be nice to declare (type (list fixnum string doodad))
<thuna`>
Sure, the compiler keeping track of the values in a list may be asking for a lot but special-casing m-v-prog1 is not that much better
<mrcom>
Then there's the historical aspect--way back when progn, prog1, prog2 were invented,
<mrcom>
back when we bought individual bits and put them together with tweezers and string...
<mrcom>
they didn't deal w/ multiple values.
<mrcom>
So they can't now without breaking "things".
<lspangler>
hi, I'm stumped by a seemingly basic project setup issue... I define an asdf system like:
<thuna`>
Historical reasons is the most likely reason for why PROG1 doesn't work the way it (IME) should - that, I can definitely understand. Still somewhat miffing.
<mrcom>
Welcome to Common Lisp :)
<thuna`>
lspangler: Please use a pastebin when sending multiple lines.
<lspangler>
sorry
<thuna`>
lspangler: What's the error?
<lspangler>
Component ASDF/USER::CL-PORTAUDIO not found, required by
<mrcom>
Put quotes around the first set of dependencies.
ronald has quit [Ping timeout: 272 seconds]
<mrcom>
And drink more coffee :)
<mrcom>
Don't forget the quotes for the "main" dependency too.
<lspangler>
you mean like this? :depends-on ("deploy" "cffi" "cl-portaudio")
<mrcom>
yeah. You've got it on the last dependency.
<mrcom>
Without the quote you're telling it to depend on a symbol, one you've haven't even assigned a value.
puke has quit [Remote host closed the connection]
<lspangler>
still doesn't seem to work :
<lspangler>
i'm literally shaking but i'll try drinking more coffee
puke has joined #commonlisp
puke has quit [Client Quit]
<lspangler>
I think the "main" :depends-on part is wrong
<lspangler>
that's for depending on other files and such not on systems
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wacki has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
ad_absurdum has joined #commonlisp
<lspangler>
aha. I think I just got the package name wrong
<lspangler>
cl-portaudio defines a system :cl-portaudio but the package that it defines is just :portaudio
<mrcom>
yeah, but the system name is what asdf sees.
ad-absurdum has quit [Ping timeout: 268 seconds]
<lspangler>
right, so I needed "cl-portaudio" in the :depends-on of my system, but the package that my system declares, I just needed :use :portaudio
lspangler has quit [Remote host closed the connection]
<mrcom>
Now I'm confused. BTW, I see symbols are OK. ASDF downcases their names and uses that as the system name.
<paulapatience>
But ASDF recommends strings
mgl_ has joined #commonlisp
<mrcom>
Still trying to figure out what just happened.
<mrcom>
asdf complained about the (:file "main" :depends-on (cl-portaudio)) -- no cl-portaudio component.
<mrcom>
Fair enough--there is such a system, but no component named that in his definition.
<mrcom>
Must have removed the :dpends-on in that clause, _and_ fixed the (defpackage ...) at the same time.
<mrcom>
The first took care of the asdf error. Nothing to do with fixing package def.
hexa6 has quit [Ping timeout: 268 seconds]
akoana has joined #commonlisp
amb007 has quit [Remote host closed the connection]
amb007 has joined #commonlisp
jonatack has quit [Ping timeout: 268 seconds]
jonatack has joined #commonlisp
<Gleefre>
beach: re ||:xxxx I think I know one possible reason SBCL treated reading ||:xxxx as a keyword as a bug, even though the standard implies that it should be read as a keyword.
<Gleefre>
[as I wrote in the WSCL issue] NOT reading ||:xxxx as a symbol in the package named "" loses print-read consistency.
<Gleefre>
As seen in this paste (https://plaster.tymoon.eu/view/4480) such a symbol is printed as one of ||:foo, ||::foo, :foo, ::foo -- depending on whether the symbol is exported and on the implementation. And all of those would read as a keyword.
char has joined #commonlisp
<Gleefre>
Moreover, reading back in ::foo or ||::foo is an unspecified behavior (note: unspecified = unpredictable but harmless, as per CLHS 1.4.2)
wacki has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 264 seconds]
lspangler has joined #commonlisp
Devon has quit [Ping timeout: 252 seconds]
<char>
Hey Gleefre, I just finished reading through all the issues for the package-local-nicknames stuff. I was expecting to seeone, but I didn't see it: using the same nickname for multiple packages. Perhaps this is already solved? I know sbcl does not allow it.
<Gleefre>
Do you mean something like (:local-nicknames (#:bar #:cl) (#:bar #:cl-user)) ?
Lord_of_Life has joined #commonlisp
<lspangler>
mrcom: sorry I ended up crashing emacs calling into this library so had to leave the channel. Thanks for your help though.
<char>
Gleefre: Yes that I what I mean.
<Gleefre>
char: That's a name conflict, which is not allowed. It is handled by ADD-PACKAGE-LOCAL-NICKNAME and signals a correctable error.
<Gleefre>
(Described in the draft of the spec, see Specification -> API -> add-package-local-nickname -> Exceptional situations)
<char>
Gleefre: Nice. In regards to issue #1, what would be wrong with just using the local nickname as the package prefix?
NotThatRPG has joined #commonlisp
<Gleefre>
re name conflict: I wonder if I should open a standartization issue for that. Although it seems to be the only "good" solution to me, not all implementations signal an error at all. (At least Allegro CL and ECL)
<Gleefre>
Do you mean the issue 2, print-read consistency ?
<char>
Oh yeah. #2.
mgl_ has quit [Ping timeout: 264 seconds]
<Gleefre>
The main issue is when there is no local nickname for the symbol's home package; so using it is not an option.
<Gleefre>
More specifically, the problem is when there is no local nickname, but the name and all global nicknames are also shadowed by existing local nicknames to other packages.
<Gleefre>
(See the first example with FOO:+)
jonatack has quit [Ping timeout: 268 seconds]
<char>
I don't really see a problem. Going with the first example, the local nickname makes the foo package unreachable (which might be the intention of the person who wrote the bar package).
<char>
I guess example 2 is a problem since there is disagreement.
<char>
For example 2, it seems like (ecl, acl, clasp) are doing the right thing. Why not just propose that as the standard?
<Gleefre>
The problem is that print-read consistency is not maintained anymore.
<Gleefre>
(This seems to be the most related hyperspec page)
mgl_ has joined #commonlisp
<char>
It says the rules only hold if *package* does not change, so I am still missing somthing. Is binding *package* different from just using in-package?
<char>
in-package typically effects the reader for subsequent forms, where as let will not change the reader right?
istewart has joined #commonlisp
<Gleefre>
Binding the *package* allows to read the symbol in the #:cl-user package instead of the #:bar in the example.
<Gleefre>
In the package #:bar the symbol foo:+ is printed as "FOO:+", yet "FOO:+" reads as cl:+ which is not eq to foo:+
<Gleefre>
Basically, if you change it to (eq 'foo:+ (read-from-string (format nil "~S" 'foo:+))) while the *package* is bound to the #:bar package, it will return NIL.
<Gleefre>
But print-read consistency claims that this form must always return T.
mgl_ has quit [Ping timeout: 264 seconds]
Pixel_Outlaw has joined #commonlisp
<lspangler>
any ideas on getting a stack trace from a foreign (C) library when calling from sbcl?
<lspangler>
sbcl is hanging instead a call to the library. I can interrupt and see which function it is, but from there I have no idea how to tell where it's stuck.
cage has quit [Quit: rcirc on GNU Emacs 29.4]
mgl_ has joined #commonlisp
hexa6 has joined #commonlisp
<char>
Gleefre: It is correct to say that the problem is caused by the local value of *package* effecting read-from-string, but not printing?
<paulapatience>
lspangler: If it's freezing, I'm not sure how you could get a stack trace anyway. In your situation, assuming I could modify the library, I'd add debug prints to the C side.
<Gleefre>
char: I wouldn't say that the value of *package* is local, since it is a dynamic variable & binding in the example.
<char>
Gleefre: Okay, but the symbol is printed in cl-user, and read in bar.
<Gleefre>
No, the symbol is printed in bar as well.
<Gleefre>
It is first read in the cl-user package though, which is used for convinience, since package FOO is unaccessible from the package BAR
n00b1 has joined #commonlisp
<Gleefre>
(Note: from the package BAR you could still access the symbol by binding *package* to say (find-package '#:keyword) and then doing (find-symbol "+" '#:foo))
<Gleefre>
It is also wrong to say that the value of *package* doesn't affect printing of the symbol -- it does. For example, if the symbol is accessible in the *package*, the package prefix is not used, even if printed readably.
<Gleefre>
Furthermore, local nicknames also have an effect on printing on sbcl, ccl, abcl and lispworks.
mgl_ has quit [Ping timeout: 256 seconds]
<Gleefre>
I'd say the root problem is that there is no readable representation of the symbol FOO:+ when the *package* is bound to the package "BAR".
hay has quit [Quit: Konversation terminated!]
wacki has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
wacki has joined #commonlisp
n00b1 has quit [Ping timeout: 264 seconds]
<char>
That is what I meant when I said not accessable: no readable representation. Thanks for helping me understand. In that case, I think I like proposal 2.2.8 the best.
istewart has quit [Quit: Konversation terminated!]
<Gleefre>
Just for clarity: you are referring to the Proposal THREE-FOUR-PACKAGE-MARKERS, foo:::bar and foo::::bar ? [ FWIW I can' guarantee that the numeration is going to remain unchanged, since it is autogenerated ]
yitzi has joined #commonlisp
<char>
That is the one. I feel like it fits with the rest of commn lisp syntax the best. It is still a bit akward, but it should be pretty rare.
jonatack has joined #commonlisp
<char>
I also noticed that you use the word shadow quite a few times in this section. The ansi spec page 2.3.6 does mention that shadow is allowed to affect the consistency. I don't think package local nicknames uses shadow, but I wonder if it could fall under that category.
<Gleefre>
I was going to say that it wasn't my favorite because it could interfere with a possible "nested packages" extension. But then it came to me that a sequence of N package markers needs to be treated separately anyways because of the existing external/internal symbol syntax... I wonder if there were other reasons not to "like" this syntax, will need to check logs from a year ago.
<char>
Another reason to not like it is that it is kinda hard to see how many colons there are at a glance.
<Gleefre>
re shadow: I think that the function SHADOW has a slightly different meaning from what I'm talking about.
<Gleefre>
Also the spec page 2.3.6 talks about it in a different context: it says that the print/read consistency can be violated by changing the package object bound to *package*, which can be done with the functions SHADOW / SHADOWING-IMPORT-FROM. In the example given in the 2nd issue, print-read consistency is violated even though the package object is not being changed.
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
shka has quit [Quit: Konversation terminated!]
shka has joined #commonlisp
<char>
I am mainly just not a fan of the other proposals. #. it just too verbose. #: would then be used for uninterned symbols and un-readable package symbols. print-unreadably seems like a loop hole and just sidesteps the problem; This might be okay; it is just not very satisfying.
<char>
and #` looks too much like #'
<char>
I think all the sharpsign reader approaches would make it impossble to do something like this: #'foo:::bar
<Gleefre>
About ::: and :::: -- it seems that there is a possibility that those are already used by some implementations (dunno if it is true)
<Gleefre>
FWIW #: is already used by the printer to print not just uninterned symbols, but also *apparently uninterned* symbols -- for example a symbol from a deleted package that is still interned in some other package is an apparently uninterned symbol, but not an uninterned symbol.
<Gleefre>
#` is also a not-already-defined, new reader syntax, which also might be already used by some implementations or libraries.
varjag has joined #commonlisp
X-Scale has quit [Quit: Client closed]
aciep has joined #commonlisp
<char>
At least uninterned symbols and apparently uninterened symbosl are somewhat realtaed. I don't see how a symbol from an unreadable package is realted to being uninterned.
<Gleefre>
I suppose it's true. Although I suppose you could call it "an unprintable symbol syntax"...
amb007 has quit [Read error: Connection reset by peer]
<Gleefre>
About #'foo:::bar and impossibility with other reader macros -- no, you can? Reader macros can be chained, so you can still do #'#`foo:bar or #'#.(let ((*package* (find-package "KEYWORD"))) (find-symbol "FOO" "BAR")) or #'#:(foo bar) e.t.c.
<Gleefre>
,#'#.(find-symbol "+" "CL")
<ixelp>
=> #<Compiled-function + #x14036D36>
amb007 has joined #commonlisp
ldb has joined #commonlisp
ad_absurdum has quit [Ping timeout: 256 seconds]
ldb has quit [Changing host]
ldb has joined #commonlisp
mgl_ has joined #commonlisp
<char>
Thanks. I didn't realize that.
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
char has quit [Ping timeout: 268 seconds]
char has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
char has quit [Remote host closed the connection]
char has joined #commonlisp
brokkoli_origin has quit [Remote host closed the connection]
amb007 has quit [Ping timeout: 256 seconds]
brokkoli_origin has joined #commonlisp
X-Scale has joined #commonlisp
shka has quit [Quit: Konversation terminated!]
mgl_ has quit [Ping timeout: 255 seconds]
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pve has quit [Quit: leaving]
wacki has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
attila_lendvai has quit [Ping timeout: 256 seconds]
vms14 has joined #commonlisp
varjag has quit [Ping timeout: 256 seconds]
dino_tutter has quit [Ping timeout: 256 seconds]
char has quit [Ping timeout: 256 seconds]
char has joined #commonlisp
akoana has quit [Quit: leaving]
donleo has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
amb007 has quit [Ping timeout: 246 seconds]
Devon has joined #commonlisp
Gleefre has quit [Ping timeout: 250 seconds]
Gleefre has joined #commonlisp
jon_atack has joined #commonlisp
istewart has joined #commonlisp
jonatack has quit [Ping timeout: 252 seconds]
istewart_ has joined #commonlisp
istewart has quit [Ping timeout: 246 seconds]
JimG has joined #commonlisp
char has quit [Ping timeout: 264 seconds]
Devon has quit [Ping timeout: 268 seconds]
aciep has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.3)]
NotThatRPG has joined #commonlisp
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vms14 has quit [Remote host closed the connection]