tyson2 has quit [Remote host closed the connection]
lucasta has joined #commonlisp
bilegeek_ has quit [Quit: Leaving]
lucasta has quit [Quit: Leaving]
hineios has quit [Ping timeout: 240 seconds]
hineios has joined #commonlisp
jmercouris has quit [Server closed connection]
jmercouris has joined #commonlisp
ronald has quit [Read error: Connection reset by peer]
shka has joined #commonlisp
azimut has quit [Ping timeout: 240 seconds]
tetsuo9 has joined #commonlisp
tetsuo9_ has quit [Ping timeout: 260 seconds]
ronald has joined #commonlisp
dcb has joined #commonlisp
patrix has quit [Server closed connection]
patrix has joined #commonlisp
Gleefre has quit [Ping timeout: 246 seconds]
dcb has quit [Ping timeout: 240 seconds]
dcb has joined #commonlisp
toastloop has quit [Read error: Connection reset by peer]
<beach>
hayley: Did you write it in C?
<beach>
Or, I guess if it is a garbage collector, in non-conforming C?
<hayley>
C with dubious degrees of undefined behaviour.
<beach>
Yes, I understand.
habamax has joined #commonlisp
<hayley>
C++ would hurt marginally less (in particular, I use #define and #include as a lame template system), and I wasn't sure how to manage the MMTk library (written in Rust) as a build dependency.
drmeister has quit [Server closed connection]
drmeister has joined #commonlisp
mingus has joined #commonlisp
d4ryus has joined #commonlisp
habamax has quit [Ping timeout: 265 seconds]
rgherdt has joined #commonlisp
Cymew has joined #commonlisp
habamax has joined #commonlisp
fuwatou has joined #commonlisp
JoshYoshi has joined #commonlisp
igemnace has joined #commonlisp
JoshYoshi has quit [Read error: Connection reset by peer]
JoshYoshi has joined #commonlisp
dcb has quit [Quit: MSN Messenger 3.8]
dino_tutter has joined #commonlisp
gascown has joined #commonlisp
msavoritias has joined #commonlisp
pve has joined #commonlisp
habamax has quit [Quit: ERC 5.4 (IRC client for GNU Emacs 28.2)]
puchacz has joined #commonlisp
<puchacz>
hi, which matrix library works in non-sbcl lisps? magicl, lisp-stat, numericals don't compile in abcl and clasp.
<puchacz>
does not have to be fast
<puchacz>
array-operations seem to work in abcl
<JoshYoshi>
pjb: are you using copilot.el?
<JoshYoshi>
oh
JoshYoshi is now known as Josh_2
<Josh_2>
:sunglasses:
fuwatou has quit [Remote host closed the connection]
rogersm has joined #commonlisp
mgl has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
LW has joined #commonlisp
minion has quit [Server closed connection]
specbot has quit [Remote host closed the connection]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
LW has quit [Ping timeout: 252 seconds]
amb007 has quit [Ping timeout: 265 seconds]
amb007 has joined #commonlisp
LW has joined #commonlisp
LW has quit [Client Quit]
Josh_2 has quit [Ping timeout: 240 seconds]
<Shinmera>
puchacz: Have you tried 3d-matrices
<Shinmera>
I don't know if it works, but it might :)
<puchacz>
Shinmera, no, thanks - I will try
buffet has quit [Quit: WeeChat 3.8]
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 252 seconds]
Lord_of_Life_ is now known as Lord_of_Life
rainthree has joined #commonlisp
minion has joined #commonlisp
specbot has joined #commonlisp
laxmik has joined #commonlisp
scymtym has quit [Remote host closed the connection]
<flip214>
CLHS 2.1.4 lists ":" as constituent character, like plus and alphanumerics. Can I tell the lisp reader to read a colon like any other alnum? so that (let ((*package* ...)) (read-from-string "foo:bar")) would return a symbol <some package>::|foo:bar|.
Brucio-61 has quit [Remote host closed the connection]
Brucio-61 has joined #commonlisp
<beach>
You can configure Eclector to do that.
<puchacz>
Shinmera - +1 for 3d-matrices, it works in abcl. and it has wolfram output format :) thanks!
<Shinmera>
yay :)
Josh_2 has joined #commonlisp
<puchacz>
will try clasp in a moment, it takes ages longer to compile
<puchacz>
I saw the name before, but I dismissed it as I thought it was specialised for 3x3 matrices
<puchacz>
and indeed it has a type for 3x3, but it also has any size matrices
<puchacz>
so all good
fuwatou has joined #commonlisp
Brucio-61 has quit [Ping timeout: 260 seconds]
<flip214>
beach: do you have an example? simply passing in a modified readtable doesn't work.
<beach>
No, that stuff can't be configured by a readtable since : is not a macro character.
<beach>
You need to stick a method on INTERPRET-TOKEN (the name might be wrong).
<flip214>
I can see :package-marker in tokens.lisp, but #\: gets checked in other places as well...
<beach>
If you override INTERPRET-TOKEN, the : should not be checked anywhere else.
<flip214>
interpret-symbol-token ?
<beach>
The default method on INTERPRET-TOKEN calls INTERPRET-SYMBOL, but you want to override the default method.
<flip214>
well, interpret-token does quite a lot of stuff....
<beach>
I think you can call CALL-NEXT-METHOD for the other cases.
<beach>
Check whether there are any : in the token, and then call INTERN or something like that. If not, call CALL-NEXT-METHOD.
<beach>
By "override" I mean, define your own CLIENT object and specialize to its class. Do not replace the existing method.
<beach>
That way, both your method and the default method are applicable.
Brucio-61 has joined #commonlisp
<beach>
Does that make sense?
<flip214>
yeah, but.... I need to duplicate the whole logic checking whether the input is a float, a ratio, an integer, a string ... BEFORE I can hand over to the default method
<beach>
Why?
<beach>
If it contains : then it can't be any of those.
<flip214>
and at least a string can always include a colon
<beach>
But a string is not a token.
<beach>
So INTERPRET-TOKEN will not be called for a string.
<ixelp>
eclector-access/examples/extended-package-prefix-syntax.lisp at master · pve1/eclector-access · GitHub
habamax has joined #commonlisp
<flip214>
beach: pve: thanks... I need to think about what exactly should be allowed, and what should be the result.
<flip214>
Like #:foo should be interned as |#:foo| in the same package as |bar:foo|? or not interned anywhere? or disallowed?
<flip214>
and what about #\:? that currently gives me #:|| ....
<pve>
flip214: it sounds like maybe you could get away with just an interpret-symbol method? Because i think the package-indicator parameter is going to be the "foo" part from your example. So you just call-next-method with a modified symbol-name and package-indicator.
habamax has quit [Remote host closed the connection]
<flip214>
pve: do you mean interpret-symbol-token?
<pve>
flip214: let me check, it's been a while
attila_lendvai has joined #commonlisp
<beach>
flip214: So, let me get the specification clear... If you have a token that does not contain a colon, you want it handled normally, and if it does, you want to do something else with it. Right?
Gleefre has joined #commonlisp
habamax has joined #commonlisp
<beach>
flip214: Because, if so, that is precisely what I suggested. Create an overriding (or perhaps the right word is "extending") method that checks for colon. If the token does not contain a colon, call CALL-NEXT-METHOD which will handle it normally, otherwise, do whatever you want in your overriding method.
<flip214>
and running interpret-symbol instead of call-next-method is a loop
habamax has quit [Remote host closed the connection]
<flip214>
but I can drop the special client in the recursive call
<flip214>
still, #:foo and #\: need to be handled as special cases...
<pve>
I'm not sure what I'm looking at :)
<flip214>
pve, beach: thanks for the help, I'll need to think some more
<beach>
flip214: I don't get it. If you want :FOO to be a keyword, then intern it there in your overriding method.
<flip214>
pve: error message from sbcl
<pve>
did my example produce that?
<beach>
flip214: How can : be handled wrong if you handle it yourself?
<flip214>
pve: with some small modifications, yes
<flip214>
beach: that is the point -- I *need* to handle it myself, and for that I need to find out where it is used and what I want to do with it in each case
<pve>
flip214: Ok, I mean it does work as I pasted it
<flip214>
pve: yes, it does. thanks a lot!
<flip214>
my original idea "just make #\: a constituent like #\a" was restricted to symbol tokens, now I have a bigger set of tokens to think through
<pve>
flip214: hm so what was your modification?
<beach>
Ah, changing requirements.
<flip214>
pve: I changed the target package, and (if (member package-indicator '(:keyword :current))
<pve>
flip214: and that gave you the error you showed?
<flip214>
with interpret-symbol there's another small problem - 3:4 and 3::4 get read identically, and 3:::4 is disallowed completely. maybe I need to use interpret-token after all.
<pve>
checking for :keyword is good, I forgot to do that
<pve>
you could check those cases in interpret-token, and maybe bind a special variable, and still handle it in interpret-symbol
<pve>
ah, is it because package-indicator is nil? And therefore of type null?
<pve>
so we can't call-next-method with "CL-USER"
<pve>
right, so package-indicator seems to be NIL for uninterned symbols
<pve>
so maybe call-next-method in that case too?
<flip214>
I just dropped the client argument for the "recursive" call
<pve>
I added nil to the member check, worked fine
alcor has joined #commonlisp
random-nick has joined #commonlisp
<flip214>
so there's just the question whether 3:4 should be EQ 3::4 after reading or not, and whether 3:::4 should be allowed or not....
<jackdaniel>
I think that to answer this question you must elaborate what is the purpose of reading symbols this way?
<jackdaniel>
i.e why are you doing this
sabra has joined #commonlisp
<flip214>
long story
<flip214>
wait for ELS24, perhaps
<jackdaniel>
given the above insight imo 3:::4 seems totally legit
<flip214>
well, eclector doesn't allow it, though
<flip214>
hrmpf
<flip214>
If I use eclector to READ-FROM-STRING, I can't use CL:LOAD any more
<pve>
why? :)
scymtym has joined #commonlisp
dino_tutter has quit [Ping timeout: 240 seconds]
<Shinmera>
puchacz: good to know, though bike might still want to know about it
<scymtym>
flip214: to allow more than two package markers, you could use (handler-bind ((eclector.reader::symbol-can-have-at-most-two-package-markers #'eclector.reader:recover)) (call-next-method)) in an :AROUND method on INTERPRET-TOKEN
<scymtym>
the actual interpretation of these tokens would need custom CHECK-SYMBOL-TOKEN and INTERPRET-SYMBOL-TOKEN methods, of course
gjvc has quit [Server closed connection]
gjvc has joined #commonlisp
dino_tutter has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
jeffrey has joined #commonlisp
fuwatou16 has joined #commonlisp
tyson2 has joined #commonlisp
scymtym_ has joined #commonlisp
Brucio-61 has quit [Ping timeout: 260 seconds]
Brucio-61 has joined #commonlisp
scymtym has quit [Ping timeout: 240 seconds]
tyson2 has quit [Ping timeout: 240 seconds]
<fuwatou16>
Hi, I am trying to compile sbcl-2.3.5 on windows using MinGW and having troubles. gcc complains about "conflicting types for select" (and a bunch of other types like timespec); I am not familiar enough about c to figure out how to fix that but it seems like MinGW helper files have some problems. Can anyone help me with this? thanks.
<beach>
fuwatou16: I think there is also an SBCL-specific channel which might be better for this kind of problem.
<Gleefre>
You could try building with clang
<fuwatou16>
I was not aware of that. I'll try ask there.
tyson2 has joined #commonlisp
<fuwatou16>
I have tried used clang and it yields error: internal compiler error which libtraceback cannot generate a trace
<fuwatou16>
which I think is even more hopeless to dig in
<beach>
Wow!
<jackdaniel>
it seems that your compilation environment is broken one way or another; an easy fix is to replace windows with some saner operating system (and no, osx is _not_ saner ;)
<alcor>
Building anything on Windows with just vanilla MinGW is a PITA. fuwatou16, try using MSys2 if you can, or if at all possible - cross-compiling.
<fuwatou16>
I can use linux for development but at the end of the day I have to target windows (with sbcl). And I think it is not really reasonably possible to cross-compile using sbcl?
<fuwatou16>
Yeah I am using MSys2 and tried to compile with different environments. Each failure is either internal compiler error or that conflicting type.
<jackdaniel>
cross-compiling from linux actually worked fine for me when I needed to (but I did not bother with that for a few years already)
jonatack has quit [Ping timeout: 240 seconds]
jon_atack has joined #commonlisp
<fuwatou16>
Maybe I should look into cross compiling again, I tried and failed but I can't remember what caused it. Maybe things changed.
jeffrey has quit [Remote host closed the connection]
<alcor>
fuwatou16: How did you bootstrap SBCL? To compile SBCL, you need an existing CL compiler first (Which in this case could either be an older SBCL binary, or ECL/CCL)
<fuwatou16>
I use sbcl-2.3.2 on windows
<fuwatou16>
Somehow I need the newest version
<alcor>
fuwatou16: If you want, you can try using a prebuilt sbcl-2.3.5 from the GitHub CI
<alcor>
yitzi: Thanks, will check later. I thought there should be a git tag somewhere, but I can't find that either.
<MetaYan>
Thanks, yitzi , I was looking for an official announcement place.
ronald has quit [Ping timeout: 240 seconds]
fuwatou has quit [Remote host closed the connection]
fuwatou has joined #commonlisp
fuwatou has quit [Remote host closed the connection]
fuwatou has joined #commonlisp
fuwatou7 has joined #commonlisp
habamax has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.0.92)]
fuwatou7 has quit [Client Quit]
azimut has joined #commonlisp
laxmik has quit [Quit: ERC (IRC client for Emacs 26.3)]
Gleefre has quit [Remote host closed the connection]
<ogamita>
osx is saner: it's a unix system. But yes. Starting from MS-Windows, you may try first to use wsl. wsl --install ubuntu ; wsl ; apt-get install sbcl # I have 2.1.11.debian currently. Then you can use it to compile 2.3.2
<ogamita>
or whatever.
kevingal has quit [Ping timeout: 240 seconds]
<jackdaniel>
osx is like: "declaratively posix, but our api is yolo"
<Shinmera>
fuwatou: FWIW I can reproduce your compiler issue on mingw.
scymtym_ is now known as scymtym
Gleefre has joined #commonlisp
ronald has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
<ixelp>
arm64: don't use a temporary in array accessors. · sbcl/sbcl@a15d1c2 · GitHub
<Gleefre>
Well, it doesn't seems to be the case for backquote
<alcor>
Shinmera: Although, one thing that is interesting is the use of SBCL 1.4.14 for bootstrapping. I'm not sure if that has any effect though.
<jackdaniel>
Gleefre: ,@ is slightly underspecified
<jackdaniel>
that said: "Anywhere ``,@'' may be used, the syntax ``,.'' may be used instead to indicate that it is permissible to operate destructively on the list structure produced by the form following the ``,.'' (in effect, to use nconc instead of append). "
<jackdaniel>
true horrors begin when you start imagining that ,@,@ has any meaning
<jackdaniel>
even worse, it will work on some implementations
<Gleefre>
It says though "If a comma is immediately followed by an at-sign, then the form ... is evaluated to produce a **list** of objects.
<jackdaniel>
(at the cost of some amazing bonkers when you return half-spliced objects)
<jackdaniel>
that's why I've said that it is underspecified
<Gleefre>
Sure
<Gleefre>
It's just... Sad
<jackdaniel>
I have witnessed sadder things than quirky edge cases ;)
<Gleefre>
Sure
<Gleefre>
It's just... sad. Not very sad.
<beach>
Gleefre: You should see the collection of undefined behavior that we try to address with the WSCL project.
<beach>
Gleefre: For example, did you realize that it is not specified what happens when AREF is given an object that is not an array.
<beach>
So (AREF 'x) could very well return 234.
<Shinmera>
iirc, you can also get whatever if you index beyond the range
<beach>
I think that's true, yes.
<Gleefre>
Oh, I heard about wscl some time ago, wasn't able to remember the name some time ago
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
chomwitt has joined #commonlisp
<_death>
you can also get whatever if you index within the range, sometimes
sjl_ has quit [Ping timeout: 252 seconds]
sjl_ has joined #commonlisp
<jackdaniel>
in other words don't use arrays, lists are all you need
<jackdaniel>
(if that's not obvious - it is a joke :)
<yitzi>
(TARS humor setting 75%)
<therepl>
How is ,@ implemented in the language? is it a reader macro? so that means when the reader finds , it has to do a lookahead to see if the next char is @ and then unwrap the list ahead?
<jackdaniel>
therepl: it varies between implementations
<jackdaniel>
cltl2 proposes some fancy implementation that involves carrying the state, but the standard allows doing what you've said (and some implementations do exactly that)
<yitzi>
therepl: comma is one of the standard macro characters
<beach>
therepl: Usually, backquote results in a macro form, and comma in something determined by the implementation. It is the resulting macro that does the job.
puchacz has quit [Quit: Client closed]
<beach>
therepl: So the reader typically doesn't do very much.
Cymew has quit [Ping timeout: 240 seconds]
<beach>
therepl: The macro is an ordinary macro, as opposed to the reader macros associated with backquote and comma.
<yitzi>
therepl: What it results in is implementation dependent. SBCL has a class to represent. ECL, CLASP use something like (UNQUOTE bla)
puchacz has joined #commonlisp
<fuwatou>
therepl: Actually it would transform it into codes that unwrap the list. When does the code run depends on the usage. Usually it's not read-time though.
Posterdati has quit [Ping timeout: 240 seconds]
<beach>
fuwatou: How could that be done if that code is not a macro call? It has to be done before run-time.
ronald has quit [Read error: Connection reset by peer]
<therepl>
thanks beach, yitzi, fuwatou
<beach>
Sure.
<fuwatou>
beach: I don't understand what you mean by macro call. The expanded code can run at runtime if the implementation is an interpreter (and a very inefficient one)
<therepl>
doesn't ,@ need to unwrap the list into its elements at macro evaluation time itself? otherwise, we will have incorrect code for the run-time.
chrcav has quit [Ping timeout: 258 seconds]
<fuwatou>
What I want to say is that most of time it won't the list won't be unwrapped immediately after the macro function of comma is invoked
rainthree has quit [Ping timeout: 260 seconds]
<beach>
fuwatou: I guess you are right. I guess the right term for what I named "macro call" is "macro form".
<fuwatou>
Yes, it is evaluated in the macro environment.
<fuwatou>
(although it can be used outside of a macro form)
<_death>
the structure is often built at runtime, but sometimes it's possible to avoid that, so that the result may be a literal
<beach>
_death: How would the structure be built at run-time if a compiler is used?
<_death>
beach: the form will expand to calls to list, append, vector, etc.
<jackdaniel>
`(,@x) will expand to (append x) for that instance
<jackdaniel>
s/will/may/
<beach>
How would it expand if it is not a macro?
<_death>
beach: I did not assume that it's not a macro?
<beach>
_death: Maybe not, but I asked specifically about a compiled environment, and then minimal compilation is required, so that no macro forms remain at run-time.
<_death>
I agree with what you said earlier, that backquote reader macro often results in a macro form
<beach>
_death: OK, but my question still remains. How is it just "often" rather than "always" in a compiled environment?
<_death>
`(1 2 3) can result in a literal, like the result of '(1 2 3)
<beach>
That's not my question.
<beach>
_death: <_death> the structure is often built at runtime, ... and then I asked how that would work in a compiled environment.
<_death>
I'm not sure I understand what you're asking
<beach>
Never mind. Not important.
<jackdaniel>
in some situations the reader may churn out a constant, and such constant may be used both in the compilation environment and in the runtime environment
gascown has quit [Quit: WeeChat 3.8]
<beach>
Sure, but "used in the runtime environment" is different from "built at runtime".
<ixelp>
Franz Inc. - Knowledge Graph and Common Lisp Solutions
luna-is-here has quit [Ping timeout: 265 seconds]
luna-is-here has joined #commonlisp
fuwatou has quit [Remote host closed the connection]
azimut has quit [Ping timeout: 240 seconds]
lucasta has joined #commonlisp
gioyik has joined #commonlisp
<flip214>
scymtym: thanks!
luna-is-here has quit [Read error: Connection reset by peer]
luna-is-here has joined #commonlisp
<Gleefre>
While there is still a lot of smart people here... How do you think a symbol with an unprintable package should be printed? [ i.e. package name & nicknames were shadowed by PLN ]
<Gleefre>
There are a number of not that ideal solutions: [1] use #. syntax, binding the *package* & using find-symbol/intern/read-from-string
<Gleefre>
[2] Use a new syntax like #`foo:bar <-- reads without PLN or #:(foo bar) / #::(foo bar) <-- package is looked up in global namespace
<Gleefre>
[2.5] Use an ugly syntax foo:::bar and foo::::bar
<Gleefre>
[3] Print it unreadably (and signal an error when *print-readably* is T) #<SYMBOL IN A SHADOWED PACKAGE FOO:BAR>
<Gleefre>
[4] ignore the problem :/
mgl has quit [Quit: Client closed]
<beach>
3 looks good to me.
<beach>
Or, rather, 3 looks the least bad to me. :)
<_death>
is the printer PLN-aware? (I don't have much experience with PLN use as I try to avoid them)
<beach>
I think the suggestion is to make it so, no?
varjag has joined #commonlisp
<Gleefre>
Mostly it is already, except for that case
<_death>
beach: I guess one could interpret it that way, if it's not already a thing..
<Gleefre>
At least on sbcl/ccl/abcl it prints with a local nickname where there is one
luna-is-here has quit [Ping timeout: 240 seconds]
<_death>
Gleefre: so maybe another solution would be to avoid such awareness in the printer
<beach>
Gleefre: And it uses solution 4 otherwise?
<Gleefre>
IIRC sbcl tries to take a name that is not shadowed, but I'm not sure
susam has quit [Server closed connection]
susam has joined #commonlisp
<Gleefre>
Nope, it does not :/
<_death>
Gleefre: it would hurt print-read consistency, but that's already not perfect..
luna-is-here has joined #commonlisp
<beach>
Maybe it should not be allowed to create a package-local nickname with a name that is already the name or the nickname of another package?
dino_tutter has quit [Ping timeout: 252 seconds]
<Gleefre>
But that's the purpose of package-local nicknames
<_death>
beach: what about a different order of operations.. can a package be created with a name that's used as a PLN for some other package?
<beach>
Oh? I don't think so.
<Gleefre>
To be able to use a nickname without thinking about others using it already
<_death>
*in some other package
ldb has joined #commonlisp
gioyik has quit [Remote host closed the connection]
<Nilby>
4 - because that's what is already the case with rename-package. more syntax sucks. unreadable things suck but are unavoidable.
gioyik has joined #commonlisp
<Gleefre>
I believe that [4] is worst :/ I would guess adding a simple check in the printer should not be too hard
<Gleefre>
And it doesn't seems like it is critically important for performance, right? PLN are used mostly with the reader & in the REPL
<Nilby>
I already deal with 4 all the time.
<Gleefre>
It doesn't mean it is better though
<Gleefre>
[4] is what mostly Allegro does [ probably because of their own hierarchial packages ]
luna-is-here has quit [Read error: Connection reset by peer]
luna-is-here has joined #commonlisp
<Gleefre>
Also ECL and CLASP, but it looks like PLN are generally not that well supported there
<Gleefre>
I mean, basic reader stuff works, sure, which is enough most of the time
<ldb>
I like [1]
<ldb>
Which looks lispy to me
tyson2 has quit [Remote host closed the connection]
<_death>
given that (format nil "~S" 'some-nickname:foo) => "NOT-NICKNAME:FOO" behavior like (format nil "~S" 'some-pln:foo) => "NOT-NICKNAME:FOO" seems consistent to me
<ldb>
I think, there should be a package to allow user to specify how to deal with things that are not printable
<beach>
Gleefre: To me, package-local nicknames exist so that one can use a fairly short package prefix even when the name or the nicknames of a package are long enough to be unique. I would neither install an external package, nor create my own package with a name as short as a package-local nickname typically is. So I don't see why my suggested restriction is problematic.
<jackdaniel>
beach: some pre-existing packages already have short names (i.e "GL")
<Gleefre>
Well, for one there are older libraries with shorter nicknames
<Nilby>
readability of symbols is a lie unless you want 9a7920f4-b9d2-4c76-b940-5a96f93c87e1::foo
<beach>
jackdaniel: I am sorry to hear that. And I would not install such a package.
<jackdaniel>
oh? how about xlib?
<jackdaniel>
or clim
<beach>
Those are unique, and I would not choose them as a package local nickname.
<jackdaniel>
I don't see what is that unique about these names, but I'll just look harder at them and (possibly) acquire enlightenment
<beach>
Yes, do that.
<Gleefre>
The problem with some-pln:foo => home-package:foo is that with shadowing PLN you can get confusing output in the REPL session for example.
<_death>
Gleefre: confusing how? if anything, that's de-confusing
<_death>
Gleefre: then the confusability is just limited to READ and not PRINT ;)
Devon has quit [Ping timeout: 240 seconds]
<Gleefre>
Well, this exact example is not real-world, sure, but there is one in SBCL's manual
<Gleefre>
When you have foo::x => bar::x and bar::x => foo::x, it sure is confusing
<_death>
well, if you start from an initial state that screams confusion, not sure the move for the next state is to blame
<Gleefre>
Also with global nicknames (eq 'nick:symbol (read-from-string (format nil "~S" 'nick:symbol))) is always T
waleee has quit [Ping timeout: 240 seconds]
<Gleefre>
But with PLN you easily can get NIL, which also is not very nice
<_death>
yes, and (eq 'pln:a (read-from-string "PLN:A")) would also be T.. this one's not about printing, but reading
<jackdaniel>
I think that you are looking for problems where they are not present
<Gleefre>
I'm not sure, this is why I'm hoping to discuss it as fully as possible
<jackdaniel>
you don't need package local nicknames to get yourself confused in common lisp (with a bit of creativity)
samebchase has joined #commonlisp
<Gleefre>
But that doesn't mean that PLN must be confusing
<Gleefre>
Why make things more confusing?
<jackdaniel>
but they are not confusing with their use case - they are to simplify writing code when the package name is too long
<jackdaniel>
and to avoid name clashes
<jackdaniel>
not to privide printer extensions (adding "features" will only make them more complicated)
<Nilby>
if you want non-confusing, get your namespace right and just use-package
<Gleefre>
PLN are also used in the REPL
<jackdaniel>
I expect that the printer will print the real package name - not its nickname, nor its local nickname, just the package name
<jackdaniel>
and that's not confusing, having it print something else (what you think may be right) _is_
<Gleefre>
And in the REPL I like to have things [1] copy-paste'able [2] not printing long-long names
attila_lendvai has quit [Ping timeout: 252 seconds]
<jackdaniel>
you already lose that with #<surprise>
* jackdaniel
gets back to writing his Common-Lisp-Instant-Messanging, clim for short :)
<jackdaniel>
messaging*
<Gleefre>
Well, what about macroexpand-1?
* jackdaniel
if he were still here would ask "what about it?", but he's not
<_death>
usually you would already have something like (let ((package (find-package "KEYWORD"))) ... print the stuff ...) so as long as keyword package doesn't use PLNs...
tyson2 has joined #commonlisp
<_death>
(I meant binding *package*)
<Gleefre>
Probably, right
<jackdaniel>
macroexpand-1 when printed has plenty of uninterned symbols that are in fact eq
<jackdaniel>
but when read back - they are not
<Gleefre>
So... what about *print-readably* ?
<Gleefre>
I'd think at least when *print-readably* is T (read-from-string (format nil "~S" <...>)) should either return eq / equal object or signal an error
<jackdaniel>
(read (print 'clim:foo)) will work just fine, doesn't it?
<Gleefre>
Not if you have a PLN for (#:clim #:clim-2)
<Nilby>
language customization is the boon and bane of lisp
<Gleefre>
Anyways, thanks you all for the discussion :D
amb007 has quit [Ping timeout: 265 seconds]
<_death>
the uninterned symbol issue is solved with print-circle ;)
amb007 has joined #commonlisp
amb007 has quit [Ping timeout: 260 seconds]
rainthree has joined #commonlisp
amb007 has joined #commonlisp
Josh_2 has joined #commonlisp
Lycurgus has joined #commonlisp
tyson2 has quit [Ping timeout: 246 seconds]
dino_tutter has joined #commonlisp
Inline has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
ec has quit [Ping timeout: 240 seconds]
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
ds9soft has joined #commonlisp
ds9soft has quit [Client Quit]
amb007 has quit [Ping timeout: 240 seconds]
amb007 has joined #commonlisp
ldb has quit [Quit: ERC 5.4 (IRC client for GNU Emacs 28.1)]
Lycurgus has quit [Quit: Exeunt: personae.ai-integration.biz]
dcb has joined #commonlisp
puchacz has quit [Quit: Client closed]
puchacz has joined #commonlisp
chomwitt has quit [Remote host closed the connection]
morganw has joined #commonlisp
Posterdati has joined #commonlisp
attila_lendvai has joined #commonlisp
lucasta has quit [Quit: Leaving]
waleee has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
rogersm has quit [Read error: Connection reset by peer]
rogersm has joined #commonlisp
puchacz has quit [Quit: Client closed]
sjl_ has quit [Ping timeout: 240 seconds]
sjl_ has joined #commonlisp
Brucio-61 has quit [Ping timeout: 260 seconds]
scymtym has quit [Ping timeout: 260 seconds]
taichi has joined #commonlisp
msavoritias has quit [Remote host closed the connection]
mariari has quit [Ping timeout: 240 seconds]
attila_lendvai has quit [Ping timeout: 252 seconds]
dino_tutter has quit [Ping timeout: 240 seconds]
sjl_ has quit [Ping timeout: 252 seconds]
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
dbotton has quit [Ping timeout: 240 seconds]
delyan_ has quit [Ping timeout: 240 seconds]
stylewarning has quit [Ping timeout: 240 seconds]
pvac has quit [Read error: Connection reset by peer]
shunter has quit [Read error: Connection reset by peer]
mhcat has quit [Read error: Connection reset by peer]
theesm has quit [Read error: Connection reset by peer]
ashpool has quit [Read error: Connection reset by peer]
pvac has joined #commonlisp
shunter has joined #commonlisp
mhcat has joined #commonlisp
ashpool has joined #commonlisp
theesm has joined #commonlisp
dbotton has joined #commonlisp
patrix has quit [Read error: Connection reset by peer]
patrix has joined #commonlisp
susam has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Brucio-61 has joined #commonlisp
susam has joined #commonlisp
stylewarning has joined #commonlisp
delyan_ has joined #commonlisp
drakonis has quit [Ping timeout: 240 seconds]
drakonis has joined #commonlisp
ds9soft has joined #commonlisp
sjl_ has joined #commonlisp
attila_lendvai has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
Patternmaster has quit [Server closed connection]
Patternmaster has joined #commonlisp
Patternmaster has joined #commonlisp
rainthree has quit [Quit: Leaving]
ds9soft has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
tyson2 has joined #commonlisp
pve has quit [Quit: leaving]
ds9soft has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
zagura has quit [Server closed connection]
zagura has joined #commonlisp
varjagg has joined #commonlisp
Inline has quit [Ping timeout: 240 seconds]
dino_tutter has joined #commonlisp
eddof13 has joined #commonlisp
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kevingal has joined #commonlisp
rgherdt has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
ds9soft has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
shka has quit [Ping timeout: 252 seconds]
ronald has quit [Read error: Connection reset by peer]
greaser|q has quit [Remote host closed the connection]
greaser|q has joined #commonlisp
ronald has joined #commonlisp
kreuter has quit [Remote host closed the connection]
kreuter has joined #commonlisp
kreuter has quit [Remote host closed the connection]
kreuter has joined #commonlisp
alcor has quit [Remote host closed the connection]
dino_tutter has quit [Ping timeout: 240 seconds]
attila_lendvai has quit [Ping timeout: 240 seconds]
morganw has quit [Remote host closed the connection]
gioyik has quit [Quit: WeeChat 3.8]
greaser|q has quit [Remote host closed the connection]
greaser|q has joined #commonlisp
<paulapatience>
Is there a convention for the meanings of clone and copy methods? Meaning, is one normally a deep copy and the other shallow, or are they just arbitrarily used to mean the same thing?
<yitzi>
clone and copy methods where? The word clone isn't used in the ANSI spec at all, as I recall. Just copy.
ski has quit [Server closed connection]
habamax has joined #commonlisp
ski has joined #commonlisp
<bike>
i'm not familiar with them having particular diferent meanings.
bilegeek has joined #commonlisp
<paulapatience>
Not in the spec, I mean in libraries. Authors sometimes use clone, e.g., Trucler has cloning-information and quasi-clone, and others use copy. I can't seem to find a consistent usage.
amb007 has quit [Ping timeout: 240 seconds]
amb007 has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
<White_Flame>
paulapatience: there's no standard definition of "clone". Each usage has its own implications about what data is assumed to be shared vs copyable
<White_Flame>
same issue as the varying levels of equality
<White_Flame>
and that's across all programming languages, not just a lisp thing
<White_Flame>
shallow copy is the only thing that tends to be a well-known operation