<fiddlerwoaroof>
It might make sense to add tests to this package, now that several implementations are implementing this?
robdog has joined #lisp
abhixec has joined #lisp
Lycurgus has quit [Quit: Exeunt]
APic has joined #lisp
robdog has quit [Ping timeout: 240 seconds]
robdog has joined #lisp
sword has quit [Read error: Connection reset by peer]
sword has joined #lisp
robdog has quit [Ping timeout: 240 seconds]
robdog has joined #lisp
Kundry_Wag has joined #lisp
wusticality has quit [Ping timeout: 250 seconds]
Kundry_Wag has quit [Ping timeout: 240 seconds]
<aeth>
that doesn't look like it goes far enough
robdog has quit [Ping timeout: 240 seconds]
ntbre has quit [Quit: ntbre]
Kundry_Wag has joined #lisp
Bike has quit [Quit: Lost terminal]
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
serichsen has quit [Ping timeout: 252 seconds]
Kundry_Wag has quit [Ping timeout: 250 seconds]
esrse has joined #lisp
<beach>
Good morning everyone!
<fiddlerwoaroof>
morning beach
dale has quit [Quit: dale]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 240 seconds]
dale has joined #lisp
igemnace has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 245 seconds]
FreeBirdLjj has joined #lisp
_rubik has quit [Quit: leaving]
abhixec has quit [Ping timeout: 250 seconds]
FreeBirdLjj has quit [Ping timeout: 250 seconds]
dvdmuckle has quit [Quit: Bouncer Surgery]
dvdmuckle has joined #lisp
libertyprime has quit [Ping timeout: 246 seconds]
Kundry_Wag has joined #lisp
Oladon has quit [Quit: Leaving.]
Kundry_Wag has quit [Ping timeout: 246 seconds]
dale has quit [Quit: dale]
abhixec has joined #lisp
libertyprime has joined #lisp
igemnace has joined #lisp
igemnace has quit [Remote host closed the connection]
prite has joined #lisp
igemnace has joined #lisp
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 245 seconds]
iovec has quit [Quit: Connection closed for inactivity]
Necktwi has quit [Quit: leaving]
frodef has joined #lisp
undiscovered has joined #lisp
Inline has quit [Quit: Leaving]
jprajzne has joined #lisp
<phoe>
fiddlerwoaroof: thanks!
nowhere_man has quit [Ping timeout: 252 seconds]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 244 seconds]
_whitelogger has joined #lisp
makomo has joined #lisp
shrdlu68 has joined #lisp
scymtym has quit [Ping timeout: 245 seconds]
varjag has joined #lisp
quazimodo has quit [Ping timeout: 240 seconds]
xkapastel has quit [Quit: Connection closed for inactivity]
holycow has joined #lisp
sauvin has joined #lisp
froggey has quit [Ping timeout: 250 seconds]
themsay has joined #lisp
froggey has joined #lisp
<splittist>
morning
kajo has quit [Ping timeout: 268 seconds]
<beach>
Hello splittist.
gxt has quit [Ping timeout: 240 seconds]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Read error: Connection reset by peer]
Kundry_Wag has joined #lisp
<makomo>
morning
<beach>
Hello makomo.
<makomo>
\o
Kundry_Wag has quit [Ping timeout: 240 seconds]
cmatei has quit [Ping timeout: 245 seconds]
kayront_ has joined #lisp
scymtym has joined #lisp
kajo has joined #lisp
quazimodo has joined #lisp
Kundry_Wag has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
Kundry_Wag has quit [Ping timeout: 272 seconds]
holycow has quit [Quit: Lost terminal]
rozenglass has quit [Ping timeout: 272 seconds]
trocado has quit [Ping timeout: 250 seconds]
meepdeew has joined #lisp
schweers has joined #lisp
meepdeew has quit [Ping timeout: 272 seconds]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 268 seconds]
themsay has quit [Ping timeout: 250 seconds]
robdog has joined #lisp
atgreen_ has quit [Ping timeout: 240 seconds]
ebrasca has joined #lisp
<hjudt>
one question to lisp experts: can the following code be written better or made more efficient? -> https://pastebin.com/Mrx8s5J7
<shka_>
hjudt: that is some sort of set operation, right?
<shka_>
because set-union and set-difference exist
<hjudt>
probably. (artifacts host) is simply a list.
<shka_>
yeah
<shka_>
i would simply use set-union and set-difference functions
<shka_>
they work on lists, obviously
<shka_>
that would be cleaner imho
<hjudt>
i will try. the collects are hierarchically though, don't know yet if set-difference will be as efficient...
themsay has joined #lisp
<hjudt>
since i do not need to compare huge quantities, it shouldn't matter though.
<shka_>
probabbly not as efficient, but it will be easier to understand
meepdeew has joined #lisp
<shka_>
even if not, it makes sense to implement your own utility function that does that
<shka_>
something like set-union-intersection-difference that would return 3 values corresponding to each operation
<shka_>
it is usually a good idea to have general purpose code separated into it's own functions
meepdeew has quit [Ping timeout: 245 seconds]
<phoe>
hjudt: more efficient, I don't think so; written better, I suppose it could be written a little bit less verbose
fusagi has joined #lisp
gxt has joined #lisp
<hjudt>
phoe: i can of course create an flet find-in-other-artifacts for the find operation etc. one thing that annoys me about my version is that the nested if/else block doesn't get properly indented.
gxt has quit [Client Quit]
<hjudt>
but that doesn't help much because there are only 2 occurrences of find.
xrash has quit [Ping timeout: 244 seconds]
Kundry_Wag has joined #lisp
<hjudt>
with set-difference/intersection i have to save the results and create more bindings, which doesn't make the code more readible imho.
xrash has joined #lisp
Kaisyu has quit [Quit: Connection closed for inactivity]
Kundry_Wag has quit [Ping timeout: 240 seconds]
<makomo>
hjudt: as much as i like LOOP, i also hate its COLLECT because it has to be used as a clause
<makomo>
and if you've got conditional collecting, it forces you to use its conditional clauses as well
<makomo>
and it just ends up looking messy, idk...
<makomo>
hjudt: perhaps using something like a COLLECT/COLLECTING/WITH-COLLECT macro with standard lisp ifs/cond would be neater?
<hjudt>
you mean series?
<shka_>
makomo: iterate
<makomo>
no, that would be an overkill. just a simple macro that introduces a local "collecting function"
<shka_>
hjudt: destructuring bind is your friend
<makomo>
shka_: that's an option i guess
<shka_>
also, metabang-bind is cool
<makomo>
but iterate is also annoying because it doesn't work exactly like LOOP, i.e. you must USE its symbols
<makomo>
rather than the symbols being recognized by their name
<hjudt>
iterate is not an option for me. i'd probably have to replace every loop in my code? i actually like loop as it is pretty natural to read.
<makomo>
there are multiple variants of this collecting macro around on the internet
hectorhonn has quit [Quit: Page closed]
arbv has quit [Ping timeout: 250 seconds]
themsay has quit [Ping timeout: 272 seconds]
<hjudt>
thanks. i'll search for it.
<schweers>
DO+ is also nice, but building it is a bit of a pain, as it has (or had) a dependency which is/was hard to find.
rozenglass has joined #lisp
arbv has joined #lisp
Kundry_Wag has joined #lisp
pbgc has joined #lisp
<makomo>
hjudt: if you end up trying a variant of your function with COLLECTING, i'd be interested to see how it looks
<jackdaniel>
loop is to me like a write-only construct. it is a nice vehicle to express ideas but not so nice to convey them
Kundry_Wag has quit [Ping timeout: 250 seconds]
<nirved>
hjudt: if the lists of artifacts are big enough, you might try using hash tables
JetJej has joined #lisp
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 246 seconds]
fusagi has quit [Remote host closed the connection]
pierpal has quit [Read error: Connection reset by peer]
adam4567 has left #lisp ["ERC (IRC client for Emacs 24.5.1)"]
rozenglass has quit [Ping timeout: 244 seconds]
pierpal has joined #lisp
pierpal has quit [Ping timeout: 246 seconds]
Kaisyu has joined #lisp
pierpal has joined #lisp
beach has quit [Disconnected by services]
beach has joined #lisp
iovec has joined #lisp
gxt has joined #lisp
arbv has quit [Ping timeout: 240 seconds]
arbv has joined #lisp
esrse has quit [Ping timeout: 268 seconds]
Lord_of_Life has quit [Ping timeout: 268 seconds]
meepdeew has joined #lisp
Lord_of_Life has joined #lisp
meepdeew has quit [Read error: Connection reset by peer]
meepdeew has joined #lisp
meepdeew has quit [Ping timeout: 245 seconds]
m00natic has joined #lisp
robdog has quit [Remote host closed the connection]
kajo has quit [Ping timeout: 252 seconds]
gxt has quit [Ping timeout: 240 seconds]
osune has joined #lisp
<hjudt>
nirved: i have considered this as a possible performance improvement and in fact use hash-tables in other parts, but here the number of artifacts simply does not justify it. the current function usually only takes at most 0.01 seconds to perform, which is really fast enough.
Kundry_Wag has joined #lisp
<fe[nl]ix>
hi Fade
<fe[nl]ix>
dlowe: any questions ?
markoong has joined #lisp
Kundry_Wag has quit [Ping timeout: 246 seconds]
dddddd has joined #lisp
quazimodo has quit [Ping timeout: 272 seconds]
amerlyq has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
xrash has quit [Read error: Connection reset by peer]
nowhere_man has joined #lisp
pierpal has quit [Ping timeout: 245 seconds]
nowhere_man has quit [Ping timeout: 240 seconds]
gxt has joined #lisp
robdog has joined #lisp
anewuser has joined #lisp
milanj has joined #lisp
pbgc has quit [Quit: Computer has gone to sleep.]
malm has quit [Read error: No route to host]
svillemot has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
xkapastel has joined #lisp
varjag has quit [Quit: ERC (IRC client for Emacs 25.2.2)]
amerlyq has quit [Quit: amerlyq]
spoeplau has joined #lisp
pbgc has joined #lisp
q3d has joined #lisp
amerlyq has joined #lisp
Bike has joined #lisp
<dlowe>
fe[nl]ix: I have some bitrot on this program that uses iolib - it stores iolib timers in a persistant database and restores them on startup
<dlowe>
it's dying, though, because the delay is too big to store in a (signed-byte 32)
<dlowe>
I haven't drilled down yet to see why the delay is too big, but this code used to work
atgreen has joined #lisp
svillemot has joined #lisp
malm has joined #lisp
ntbre has joined #lisp
ntbre has quit [Client Quit]
meepdeew has joined #lisp
varjag has joined #lisp
meepdeew has quit [Read error: Connection reset by peer]
smokeink has quit [Remote host closed the connection]
smokeink has joined #lisp
abhixec has quit [Ping timeout: 240 seconds]
libertyprime has quit [Ping timeout: 245 seconds]
atgreen has quit [Remote host closed the connection]
<fe[nl]ix>
dlowe: can you condense it to a short error case ?
<dlowe>
It's probably not even an error on iolib's part, I thought you might have an idea off the top of your head
Necktwi has joined #lisp
<dlowe>
it looks like that code hasn't changed in a really long time. hm.
<beach>
Is that bad?
* beach
has a lot of bad code in that case.
<dlowe>
that's good for iolib, bad for me :)
<beach>
Heh, OK.
<dlowe>
old code in portable common lisp is timeless. It's lovely.
ravndal has quit [Quit: WeeChat 2.3]
warweasle has joined #lisp
smokeink has quit [Quit: Leaving]
shrdlu68 has quit [Quit: WeeChat 2.3]
Necktwi has quit [Ping timeout: 245 seconds]
Kaisyu has quit [Quit: Connection closed for inactivity]
<dlowe>
as expected, it's a bug in my code
<dlowe>
the problem only surfaces when loading very old timers, though
iovec has quit [Quit: Connection closed for inactivity]
shka_ has quit [Quit: WeeChat 1.9.1]
igemnace has quit [Ping timeout: 245 seconds]
q3d has quit [Ping timeout: 256 seconds]
frodef has quit [Ping timeout: 268 seconds]
edgar-rft has quit [Quit: Leaving]
q3d has joined #lisp
zigpaw has quit [Remote host closed the connection]
LiamH has joined #lisp
meepdeew has quit [Remote host closed the connection]
cage_ has joined #lisp
ntbre has joined #lisp
ntbre has quit [Client Quit]
ntbre has joined #lisp
Zaab1t has joined #lisp
<loli>
it's quite a shame that (in-package ...) only works at the top level. It has made me try to hack hard to get around it
q3d has quit [Ping timeout: 256 seconds]
anewuser has quit [Ping timeout: 246 seconds]
JetJej has quit [Quit: [Quit]]
<Bike>
it works at any level, it just doesn't affect compile-file except at top-level, is that what you mean?
<loli>
yea, that is what I meant
<loli>
I wrote a reader macro to get around it, but that's too inflexible
<loli>
so I've decided to just allow the users to write expanders for things that define functions, values, or macros, to properly put them in a namespace
<Bike>
what are you trying to do exactly?
<Bike>
a lot of the time you can avoid needing such things with some reorganization
<loli>
well, I wish to make CL packages more flexible
<loli>
one thing I"m adding is module functors, and another is making them more first class
<loli>
this is just a step towards that goal
<Bike>
what is a module functor? you mean like a parameterized package?
<loli>
yeah, it'll take a package and produce a package
igemnace has joined #lisp
<loli>
I want this defmodule macro to also be able to define packages easily for the library user as well, going in and out of the package namespace, as I may need to do this in a function
<Bike>
how does that lead to non top level in-package?
<loli>
well consider when you want to make a module system first class
<loli>
but that leaks too much, and would be cumbersome where used, I'd rather not trouble the user in this sense
<loli>
so I've thought of a better solution
<pjb>
you see, the point is that you can already always read the sexp you want, whatever the current package, by qualifying the symbols.
<loli>
I understand that
<pjb>
This is why we don't need further nitpicking with packages or in-package.
shka_ has joined #lisp
<loli>
well this doesn't work for all forms
<loli>
consider
<loli>
(defstruct foo::test a b)
<loli>
this will make the constructor and copier in the *package*
<loli>
and not in foo
<loli>
so an expander which creates the proper constructor and copier-name is needed
<loli>
which is easy to do once you are in a macro
<Bike>
yeah, defstruct is uniquely weird in that sense.
<pjb>
There's a reader macro to allow also qualifying sexps: (in-package "FOO") (let ((x 3)) bar::(+ 1 2 foo:x)) which syntactically is more pleasant IMO. But again, I don't feel a need to use it.
m00natic has quit [Remote host closed the connection]
<Bike>
i think defstruct is the only operator in the language that makes its own symbols like that.
<loli>
really we have bar::(+ 1 2 x) that's cool
<Bike>
that's not standard, but it is common
<Bike>
might only work at top level, though
<loli>
Bike: maybe defclass does?
<Bike>
defclass does not
<Bike>
you provide all the symbols to defclass explicitly
<loli>
huh, well that's good to know, as this will make my new approach easy
wigust has quit [Ping timeout: 250 seconds]
<Bike>
that's why it has that verbose syntax with :accessor and :initarg and so on
<loli>
I've never used the object system outside of defmethod, I tend to stay away
<Bike>
defstruct is kind of old, you know? keeps to its own beat
<stylewarning>
you should use the object system, it’s nice
<loli>
yeah, that's fine though, as it has options to fix the oddities
<loli>
quite extensible
<pjb>
What may be perhaps more often useful, is a reader macro to be able to write sexps using symbols from packages that don't already exist. There are circumstances when building systems where that occurs (eg. ql:quickload a system, and generate an executable with a toplevel in a package, but that package is not defined until run-time. Or defining test targets in asd files, where the test functions are in packages loaded and build b
<pjb>
asd, therefore not existing when you define the asd…
<loli>
yeah, I'd like that as well pjb, I'll consider if I can think of a way to do that
<loli>
I was writing package alias functions
<loli>
with-alias and let-alias that had to use R.ref to alias reference:ref which is quite ugly
<pjb>
On the other hand, since the need only occurs in very specific places, and it's solved with funcall and those runtime-… functions, perhaps we can avoid writing the reader macro. There's not a lot to be earned by writing it.
<loli>
I personally try to avoid reader macros when possible
<pjb>
It's a good resolution.
<loli>
like the one I presented even I found a way to phase that out, and I'm happy about it
<loli>
anyways I must be taking my leave, thank you pjb and Bike
kajo has joined #lisp
schweers has quit [Ping timeout: 268 seconds]
gxt has quit [Ping timeout: 245 seconds]
Mr-Potter has joined #lisp
rumbler31 has joined #lisp
nowhere_man has joined #lisp
pierpal has joined #lisp
karlosz has quit [Quit: karlosz]
nowhere_man has quit [Read error: Connection reset by peer]
nowhere_man has joined #lisp
pierpal has quit [Read error: Connection reset by peer]
FreeBirdLjj has joined #lisp
iovec has joined #lisp
rumbler31 has quit [Remote host closed the connection]
anamorphic has quit [Quit: anamorphic]
pierpal has joined #lisp
frodef has joined #lisp
atgreen has joined #lisp
atgreen has quit [Read error: Connection reset by peer]
pierpal has quit [Ping timeout: 268 seconds]
gxt has joined #lisp
pierpal has joined #lisp
anamorphic has joined #lisp
scymtym has quit [Ping timeout: 240 seconds]
xkapastel has quit [Quit: Connection closed for inactivity]
ntbre has quit [Quit: ntbre]
nowhere_man has quit [Ping timeout: 252 seconds]
<phoe>
I have a package FOO for which another package BAR defines a package-local nickname.
<phoe>
What happens if package FOO is deleted?
<phoe>
I assume the link is then broken.
<phoe>
What happens if package FOO is renamed?
<phoe>
What if the new name clashes with a different, already existing package-local nickname?
<phoe>
Is there a proper test suite for package local nicknames at all that tests all of these behaviors?
Kundry_Wag has quit [Remote host closed the connection]
<sjl_>
If not, it's probably worth making one and running it in the implementations that already have the feature.
<phoe>
Sounds like I'll yak shave and create such a test suite.
<phoe>
Because it's hard to implement package local nicknames if I have no idea how they are supposed to work in details.
<phoe>
If it's a matter of adding PLNs to CCL, because other implementations already support them, then I suppose I could ask maintainers of these implementations for their test suites of that feature.
<sjl_>
I think I remember Xach working on something related to package local nicknames at some point, but maybe I'm misremembering
anamorphic has joined #lisp
milanj has quit [Quit: This computer has gone to sleep]
<phoe>
OK - holding my horses until I hear something from the different maintainers.
<phoe>
As in, I could pull that out of SBCL and turn it into a portable test suite.
<phoe>
Shit, I thought I would be "just" implementing package local nicknames in CCL, but I will likely end up yak shaving a whole darn test suite and specification for this.
<phoe>
Oh well, time to create a new Git repository. 🎵
pfdietz has joined #lisp
<Xach>
I was thinking hard about package-local nicknames and I have a strong feeling that they should be done without adding extra packages.
<Xach>
Or using different packages on different implementations.
<Xach>
But that feeling ran up against the spec which says standard functions must not return new extra values.
notzmv has joined #lisp
meepdeew has joined #lisp
<phoe>
Xach: for now, I will only create a system that tests package-local nicknames on a given implementation.
<phoe>
And once that is in place, I'll try to run it/ask people to try to run it on SBCL, ECL, Clasp, ... and see if it works the same.
<Xach>
I hoped to have something that was better than "load cffi" or "load usocket" - something that worked out of the box with nothing extra to load and no conditionalization
<Xach>
as much as i love c2mop i wish you didn't have to fetch and load it. i wish more extensions were like that.
iAmDecim has quit [Ping timeout: 240 seconds]
<phoe>
Xach: I actually want to do it like that
<phoe>
like, uh, some extension to DEFPACKAGE or what not that is common across all implementations
<phoe>
I assume that non-CCL implementations already have that
akoana has joined #lisp
<phoe>
So, ideally, the test suite should run perfectly on them
<Xach>
Sure. but there are other pieces of the interface that are currently done through sb-ext or what-have-you.
<phoe>
Oh right, that is correct
<Xach>
I will try to dig up and share my wip document on the topic
<phoe>
And I can't really skip that.
<phoe>
I mean, I can't export new functions out of CL because that wouldn't conform.
<Xach>
But you can add keywords and that can change behavior
<Xach>
I think I would argue for adding return values too
<phoe>
Yes, but I can't export #'PACKAGE-LOCAL-NICKNAMES out of CL or adding more return values to FIND-PACKAGE.
<phoe>
So I think the best that can happen is (ql:quickload :pln) (use-package :pln)
<Xach>
That is not the best
<phoe>
Which is the curse that you described up above.
<phoe>
I'm open to suggestions!
<phoe>
I want to hear how it can be made better.
<Xach>
That is far from the best! The best is consensus to allow returning extra values and use a common set of extra keywords on standard funcitons.
<Xach>
let me dig up what i wrote in design for this and hope it is not embarrassingly short
edgar-rft has joined #lisp
<phoe>
So, basically, a consensus to willingly go against the standard in this particular spot.
<phoe>
Which is what already happened when Unicode was adopted, I guess.
xkapastel has joined #lisp
pierpal has quit [Quit: Poof]
cage_ has quit [Remote host closed the connection]
pierpal has joined #lisp
<Xach>
Hmm, I can't find it, even though I spent some hours working on it right after ELS last year.
<Xach>
I will keep digging.
iAmDecim has joined #lisp
<phoe>
OK
ravenousmoose has joined #lisp
Zaab1t has quit [Quit: bye bye friends]
<sjl_>
Is the prohibition against returning extra values to prevent code that uses multiple-value-list from suddenly getting a larger/smaller list than it was expecting?
<Bike>
or multiple value call, probably, yeah
<phoe>
Yes
<sjl_>
Or is there some other reason? In general multiple values seem pretty flexible when it comes to extra ones -- m-v-b ignores them, standard use ignores them, etc.
<sjl_>
Ah yeah I forgot about m-v-c
FreeBirdLjj has quit [Remote host closed the connection]
iAmDecim has quit [Ping timeout: 240 seconds]
<phoe>
jackdaniel: in which ECL versions package local nicknames are present?
<phoe>
I have 16.1.3 and it does not seem to have them yet.
<pjb>
phoe: notice that in the case of ccl, everything is in the ccl package, and cl re-export symbols from the ccl package. eg. (eql 'cl:find-package 'ccl::find-package)
<phoe>
pjb: yes, I'm aware of that.
gxt has quit [Ping timeout: 245 seconds]
<pjb>
phoe: therefore you cannot define extensions just in ccl; you need to define a cl-with-package-local-nicknames package.
<phoe>
jackdaniel: thanks.
<pjb>
phoe: or a package named EXT.
<jackdaniel>
sometimes it is yet another scenario
<jackdaniel>
package SYSTEM uses both CL and EXT
<jackdaniel>
so things defined in system, if exported from any of two latter packagages, are bound to symbols from said packages
<phoe>
or there is a package conflict
<pjb>
phoe: why don't you first implement it over CL without touching the internals? For example, a function such as package-local-nicknames can be implemented as: (defun package-local-nicknames (pd) (gethash (find-package pd) *pln*))
<jackdaniel>
phoe: the exact point of doing so is to avoid package conflicts (i.e by not being able to compile it that way)
<pjb>
phoe: then you will know what (minimal) extensions you need in the implementation to support pln.
<phoe>
pjb: I'll do it, as soon as I have a working test suite.
<jackdaniel>
there isn't much to test
<jackdaniel>
I mean: sure, you may spawn infinite number of tests which test the same thing, but there is not much functionality to cover
<phoe>
jackdaniel: I copied the tests from SBCL and I'm portabilizing them now.
<pjb>
phoe: if you look at my relative-package names, you will see that I shadow a number of package functions from CL. This is because to maintain consistency, those standard function need to perform some additionnal processing. For example, FIND-SYMBOL needs to be patched. You can implement it as a shadowed function first, and then you'll know if you can do it with just a hook in the implementations, or if you need to modify deeply
<pjb>
implementation.
iAmDecim has joined #lisp
iAmDecim has quit [Ping timeout: 246 seconds]
jprajzne has quit [Quit: jprajzne]
jprajzne has joined #lisp
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
zigpaw has joined #lisp
jprajzne has quit [Client Quit]
jprajzne has joined #lisp
anamorphic has quit [Quit: anamorphic]
findiggle has joined #lisp
gxt has joined #lisp
anamorphic has joined #lisp
shka_ has quit [Ping timeout: 245 seconds]
<phoe>
jackdaniel: I see differences in behavior between ECL and SBCL
<phoe>
a symbol from a package with a local nickname is printed with an explicit local nickname prefix in SBCL but without it in ECL
scymtym has joined #lisp
<verisimilitude>
What's the particular expression used, phoe?
<phoe>
verisimilitude: too complex to put it in one line. It depends on the current state of the package system.
<verisimilitude>
That is, what are the various *PRINT- values?
<phoe>
verisimilitude: we're not talking about standard behavior here.
<verisimilitude>
Alright.
iAmDecim has joined #lisp
warweasle has quit [Quit: rcirc on GNU Emacs 24.4.1]
Kundry_Wag has joined #lisp
iAmDecim has quit [Ping timeout: 244 seconds]
<jackdaniel>
phoe: it behves as specified
<jackdaniel>
behavior which is not specified is not implemented
<jackdaniel>
you may see in ecl or sbcl documentation what exactly is guaranteed
<phoe>
jackdaniel: gotcha - so the portable test should not test symbol printing
<jackdaniel>
portable test should test *only* what is mentioned in the documentation
<jackdaniel>
(i.e not some implementaiton-specific quirks which may be result of unrelated system parts)
<phoe>
hm
<phoe>
"When printing a package prefix for a symbol with a package local nickname, the local nickname is used instead of the real name in order to preserve print-read consistency."
<phoe>
actually this is in the ECL manual
<phoe>
and this is what seems to fail in the test
<phoe>
let me try to isolate this
LiamH has quit [Quit: Leaving.]
<jackdaniel>
if there is something contrary in documentation and implementation please report an issue
<phoe>
Sure, I will, as soon as I have a reproducible test case
<pjb>
phoe: depends on the specifications. But I would say that specifying that the symbols accessible from *package* should print without qualifier. So the behavior in sbcl is wrong.
<pjb>
phoe: on the other hand, the defpackage form is not conforming.
<phoe>
pjb: obviously it's not conforming, we're discussing an extension.
<pjb>
phoe: perhaps in sbcl, defpackage without :use is equivalent to (:use) while in ecl it's equivalent to (:use :cl).
<phoe>
pjb: F5
<pjb>
modulo the extension of course.
<phoe>
I've updated it to have an empty (:use)
<phoe>
Same result.
<pjb>
Ok. Now definitely a problem in the implementation in sbcl. (assuming my spec).
<pjb>
err, no, wait.
<verisimilitude>
If you don't specify an empty :USE clause, it's implementation-dependent what's included.
<pjb>
the implementation in sbcl is correct, the implementation in ecl is wrong.
<phoe>
The thing about print-read consistency I quoted above is what is keeping me worried.
<phoe>
Because this result seems to be against the specified behavior.
<phoe>
I'll just wait for jackdaniel confirmation before I make a ticket on ECL.
<pjb>
You should probably add (*print-readably* t) to be sure.
Kundry_Wag has quit [Remote host closed the connection]
matijja has joined #lisp
<jackdaniel>
I won't get into it now. Please put an issue, link the relevant specification part and I (or Marius) will get to it eventually
<phoe>
pjb: same result
<phoe>
jackdaniel: OK
<jackdaniel>
and if I'll find it a non-issue I'll close it. Otherwise it will be fixed as soon as importance mandates
<sjl_>
apparently yes, in SBCL. and it chooses an arbitrary one to use for the package prefix. seems weird -- I'd expect it to behave like non-local nicknames like pjb said, i.e. never using the nicknames as a package prefix
<Bike>
does it change if it's readable?
<phoe>
"When printing a package prefix for a symbol with a package local nickname, the local nickname is used instead of the real name in order to preserve print-read consistency. "
<phoe>
Bike: nope
<phoe>
sjl_: all stems from this passage in the PLN specification I guess
<sjl_>
yeah I see the docs
<sjl_>
what specification?
<sjl_>
you mean the sbcl docs?
<phoe>
it would be silly for the symbol to be printed any other way, since you'd read something else than what was printed
<pjb>
phoe: I assume local nicknames are able to shadow global package names or nicknames. Therefore while it would be "pointless" to shadow its own package name, it may be incidental and implementation specific, and should be allowed, IMO.
<phoe>
but when printed and read, they are the same object
<phoe>
so it is consistent
<phoe>
pjb: got it
iAmDecim has joined #lisp
<sjl_>
Well yes, of course. I'm saying that it's weird they print with the nickname as the package prefix. They should print with the package name as the package prefix, just like non-local nicknames do.
<phoe>
sjl_: this trips up the moment you have package name shadowing
<phoe>
SBCL has an example with (:local-nicknames (:foo :bar) (:bar :foo)) as a pathological case
<phoe>
and your case wouldn't have it consistent, while SBCL's method has it consistent
<sjl_>
Yeah, that's an ugly corner case
<phoe>
yes, ugly as hell
kajo has joined #lisp
<pjb>
phoe: it's related to what I mentionned in relative package names: either we're working only with names, or we're working structurally with the packages. Unfortunately, when we deal with symbols, we don't have a lot of choices, we have to deal with the package. I'm not sure hacking the printer to find a local nickname is safe or worth it, since there could be several local nicknames.
<phoe>
pjb: oh, I see. SBCL has a #'CONTINUE restart in there.
<phoe>
So it signals a continuable error.
<phoe>
Restarts: 0: [CONTINUE] Continue, use it as a local nickname anyways.
<phoe>
Does this make sense?
Kundry_Wag has joined #lisp
<pjb>
printing needs to consider only the package name and the global nicknames, because they're in a global namespace. The shadowing namespaces of local nicknames cannot be used to resolve a printable name.
<phoe>
then you do not have print-read consistency.
ebrasca has quit [Remote host closed the connection]
<pjb>
phoe: yes. That's the result of shadowing of local nicknames.
<pjb>
To have print-read consistency, you must not shadow the name of the home packages of the symbols you print.
anamorphic has joined #lisp
<phoe>
pjb: then, in the pathological case of (:foo :bar) (:bar :foo), (read-from-string (prin1-to-string 'x)) isn't necessarily eq to x.
<pjb>
Indeed.
matijja has quit [Ping timeout: 246 seconds]
<phoe>
Using this logic, it could be argued that reading also needs to consider only the package name and the global nicknames, because they're in a global namespace. The shadowing namespaces of local nicknames cannot be used to resolve a printable name.
<phoe>
So, since we have printing and reading that don't use local nicknames, hey, we don't have local nicknames anymore.
<pjb>
well, the point is that we want to use local nicknames to read.
<phoe>
And using local nicknames for reading only and not for printing is even uglier because it is not consistent in a place where Lisp is consistent.
Kundry_Wag has quit [Ping timeout: 246 seconds]
<phoe>
Which is, when *print-readably* is T, either you have print-read consistency, or Lisp signals an error.
<anamorphic>
This CCL bounty source stuff for things like local packages seems awesome
<pjb>
Notice that with relative package names the same problem occur: if we print qualifying with a short, relative name, there may be ambiguity when reading in a different package, where the relative package name may resolve to a different absolute package.
<phoe>
anamorphic: perhaps awesome for the end users but it's hella lotta tricky to get right
<phoe>
pjb: that's correct, but in this case, I'd assume that we read in the same package in which we print.
<phoe>
We can't make it work otherwise in a system where package nicknames may not be unique.
<pjb>
You can set up a package where there is now way to do it.
<anamorphic>
phoe: shinmera wrote that basically everyone bu ccl has it. Are the ones that do -- are they pretty compatible?
<pjb>
You can shadow all the global names and nicknames of that package, or the home package of the symbol considered.
<pjb>
So yes, if *print-readably*, you may want to signal an error.
<phoe>
anamorphic: I think so, yes.
varjag has joined #lisp
<pjb>
So, selecting the name to use to qualify a symbol when printing-readably becomes complicated.
<phoe>
pjb: basically, if the package we're in has any local nicknames, and *print-readably* is true, we want to signal an error. Is that corect?
<phoe>
correct?
<pjb>
No, that would depend on the symbol to be printed.
<phoe>
Still sounds like an ugly edge case that it is.
<anamorphic>
Would it solve the problem where two quick lisp systems creating the same defpackage name would not be usable in the same Lisp image? I forget who blogged about it, but apparently there's name conflicts already
<phoe>
Fixing SBCL's printing isn't in my scope at the moment; feel free to raise an issue at their launchpad bug tracker.
<pjb>
anamorphic: nope. :-)
<sjl_>
anamorphic: it wouldn't solve that on its own, but it would provide an alternative those conflicting packages could take advantage of: use longer, unique names and let uses choose the short nicknames themselves
<pjb>
anamorphic: for that you would want to use relative-package names, and load one system in a package, and another in another package.
<pjb>
anamorphic: alternatively, if we had first class environment, we could load different systems in different environments.
nowhere_man has quit [Ping timeout: 252 seconds]
matijja has joined #lisp
<phoe>
ABCL passes all the tests from SBCL's test suite, so it behaves consistently with SBCL.
<engblom>
Last time I tried, ABCL did not work for compiling SBCL
<phoe>
engblom: oh wait, I didn'
<phoe>
t mean compiling SBCL
<phoe>
just tests for package local nicknames - sorry, I wasn't clear enough.
<anamorphic>
phoe: I just saw on the bountysource you're attempting it - that's great! good luck!
<phoe>
anamorphic: faint heart never won fair lady
kirkwood has quit [Quit: ERC (IRC client for Emacs 27.0.50)]
Kundry_Wag has joined #lisp
anamorphic has quit [Quit: anamorphic]
Kundry_Wag has quit [Ping timeout: 272 seconds]
iovec has quit [Quit: Connection closed for inactivity]
ntbre has joined #lisp
frodef has quit [Ping timeout: 244 seconds]
permagreen has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
pfdietz has quit [Ping timeout: 250 seconds]
Kundry_Wag has quit [Ping timeout: 245 seconds]
Kundry_Wag has joined #lisp
moei has quit [Quit: Leaving...]
<phoe>
Okay, enough for tonight
random-nick has quit [Ping timeout: 240 seconds]
matijja has quit [Ping timeout: 244 seconds]
<phoe>
I might rip out SBCL's code for handling PLNs and stuff it into CCL tomorrow
<phoe>
And later, I'll actually modify the reader
fkac has joined #lisp
Kundry_Wag has quit [Ping timeout: 244 seconds]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 250 seconds]
undiscovered has quit [Remote host closed the connection]
undiscovered has joined #lisp
Kundry_Wag has joined #lisp
jxy has quit [Quit: leaving]
zigpaw has quit [Remote host closed the connection]
jxy has joined #lisp
zigpaw has joined #lisp
Kundry_Wag has quit [Ping timeout: 272 seconds]
Bike has quit []
ravenousmoose has joined #lisp
ravenousmoose is now known as ravenousmoose[aw
drolax has quit [Ping timeout: 250 seconds]
ravenousmoose[aw has quit [Client Quit]
themsay has quit [Ping timeout: 246 seconds]
kirkwood has joined #lisp
themsay has joined #lisp
Kundry_Wag has joined #lisp
sjl_ has quit [Ping timeout: 244 seconds]
Kundry_Wag has quit [Ping timeout: 244 seconds]
ntbre has quit [Quit: ntbre]
nowhere_man has joined #lisp
fkac has quit [Remote host closed the connection]
ntbre has joined #lisp
rumbler31 has joined #lisp
mfiano has quit [Ping timeout: 246 seconds]
mfiano has joined #lisp
undiscovered has quit [Remote host closed the connection]
rumbler31 has quit [Ping timeout: 268 seconds]
meepdeew has joined #lisp
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 246 seconds]
Lord_of_Life_ is now known as Lord_of_Life
Kundry_Wag has joined #lisp
meepdeew has quit [Ping timeout: 240 seconds]
Kundry_Wag has quit [Ping timeout: 250 seconds]
cantstanya has quit [Remote host closed the connection]