<jcowan>
is it a requirement that CONDITION is a standard-class?
<Bike>
no.
<Bike>
the condition system is a bit outside of clos.
<aeth>
iirc it isn't in SBCL
<aeth>
but is everywhere else
<aeth>
At least, that's what someone was saying in here a while ago
<Bike>
in point of fact i'm not sure condition types even have to be classes.
<jcowan>
I guess it doesn't matter, since you have to create conditions with a specialized function. I didn't notice that requirement before.
<aeth>
greenb: CL has an integrated debugger, so it's about as hard to keep things secret in as JavaScript in the browser. (i.e. if you know where to look, you can just look)
<aeth>
You can run it with the debugger off in some implementations, though
lumm has joined #lisp
terpri has joined #lisp
<Bike>
i think if you have access to a debugger you can pretty much rule out security
<Bike>
but gdb existing doesn't mean a C program couldn't be secure
<aeth>
Bike: I think the difference is that with CL the expectation is that the debugger is pretty much always there, and the compiler definitely is always there
<greenb>
aeth: That's irrelevant to the point at hand. What Caja does is make it so that external code (a 3rd party embedded app or ad on a webpage) can only access the webpage via the object references explicitly given to it. It's simple and works.
sjl has quit [Quit: WeeChat 2.2-dev]
lumm has quit [Ping timeout: 240 seconds]
<aeth>
greenb: sounds like a closure is the closest thing to that, as White_Flame said earlier
asarch has joined #lisp
<greenb>
aeth: It would appear so. Isn't there an saying that a closure is a poor man's object?
<greenb>
s/an/a
<jcowan>
But then again, an object is a poor man's closure.
<jcowan>
In fact, OO and FP are duals.
<aeth>
greenb: In this case you actually want a poor object, since you don't want everything an object can offer
<aeth>
Usually when you want a poor object in CL you want a struct, but here you want something even poorer, a closure.
didi has quit [Quit: O bella ciao bella ciao bella ciao, ciao, ciao.]
<greenb>
aeth: Why not a full object? Io can do capabilities (it's easiest in a pure prototype-based OO language), and it's certainly more powerful than CL (and about the same as Kernel) because it effectively replicates Kernel's explicit evaluation strategy and lexically-scoped fexprs.
<jcowan>
Is there any way to make a Lisp cough up the non-portable stuff that quasiquote expands into? I was expecting that '`(a ,b c) would => (list 'a b 'c) or some equivalent, but all I get from either clisp or sbcl is `(a ,b c).
<Bike>
jcowan: try (setq *print-pretty* nil)
<jcowan>
or rather `(a ,b c)
<Bike>
jcowan: sbcl is just printing (sb-int:quasiquote ...) like that for you
kristof has joined #lisp
argoneus has quit [Remote host closed the connection]
<Bike>
greenb: because objects can have slot-value used on them. also i don't see how fexprs are related?
<jcowan>
(SB-INT:QUASIQUOTE (A #S(SB-IMPL::COMMA :EXPR B :KIND 0) C)) in sbcl, same as before in clisp.
<Bike>
I don't know what clisp is doing then... Odd.
<Bike>
You might have to be more manual. class-of, car, cdr, kinda thing
<greenb>
Bike: Alan Kay's "An Early History Of Smalltalk" contains an interesting quote - "...LISP had not only been around enough to get some honest barnacles, but worse, there were deep flaws in its logical foundations. By this, I mean that the pure language was supposed to be based on functions, but its most important components—such as lambda expressions, quotes, and conds—were not functions at all, and instead were called special
<greenb>
receiving side when needed? I could never get a good answer, but the question was very helpful when it came time to invent Smalltalk..."
<greenb>
forms. Landin and others had been able to get quotes and conds in terms of lambda by tricks that were variously clever and useful, but the flaw remained in the jewel. In the practical language things were better. There were not just EXPRs (which evaluated their arguments), but FEXPRs (which did not). My next question was, why on earth call it a functional language? Why not just base everything on FEXPRs and force evaluation on the
<Bike>
i know what fexprs are.
<Bike>
i don't understand what they have to do with capabilities.
<greenb>
The point is that Alan Kay's idea of OOP was based on it, and accidentally reinventing it leads to the same semantics as Kernel, whose lexically-scoped fexprs effectively combine the semantics of closures with the power of macros.
<Bike>
I was under the impression that in smalltalk functions evaluate their arguments. Though I don't know smalltalk that well.
<Bike>
I've made a few toy Kernel implementations. It doesn't strike me as secure, but you could use the environments for it.
kristof has quit [Ping timeout: 264 seconds]
<greenb>
Bike: It was only made that way with Smalltalk-76 for the sake of efficiency. Smalltalk-71 and 72 were very different and directly inspired Hewitt's actor model.
<aeth>
greenb: Common Lisp was designed to be an efficiently compiled language (even though it can be bytecode compiled with the bytecode then interpreted). Afaik, fexprs cannot efficiently be compiled so they were not an option for CL.
<White_Flame>
fexprs receive literal args like macros, but are expected to execute them at runtime
<Bike>
I see.
<oni-on-ion>
greenb: interesting..
meepdeew has joined #lisp
<Bike>
I still don't really get the connection to actors or oop. not an area i'm into.
<Bike>
and javascript doesn't have fexprs unless i'm seriously mistaken
<greenb>
I think there's a connection between capabilities (only operating on what is explicitly given, but doing so arbitrarily on the receiving side) and lexically-scoped fexprs (basically the same). You don't need fexprs for capabilities or vice versa, but the two fit together very nicely.
argoneus has joined #lisp
<Bike>
ok.
<jcowan>
after calling macroexpand-1, I get (LIST* 'A B '(C)) in sbcl and (CONS 'A (CONS B '(C))) in clisp
<greenb>
Well, Kernel expressions can operate on unbounded variables, but you see what I mean.
<jcowan>
so it's just that clisp doesn't respect print-pretty for quasiquotes, where sbcl does
<White_Flame>
if LAMBDA were just a single character, and there was small syntax for a zero-expression lambda, I bet that special forms such as IF and COND would have just used those instead of not-always-evaluated inline code snippets
<White_Flame>
*zero-parameter
<Bike>
All I meant was that objects in lisp are not encapsulated because you can use slot-value and standard-instance-access and such, as you already knew. You'd have to prevent use of the latter and seriously restrict the former to get any kind of access control.
<White_Flame>
thus satisfing kay's complaints. Not sure why he wanted fexprs, though
<Bike>
But you knew that. That's why real objects wouldn't be satisfied.
<jcowan>
Well, that's what ST does, but it turns out that the ST compilers don't normally work on cases where the then: and else: arguments aren't literal blocks.
<Bike>
wouldn't be satisfactory
<jcowan>
Smalltalk-76 had fexprs
<jcowan>
Smalltalk-80 did not, thus recapitulating the history of Lisp
<White_Flame>
heh
<Bike>
makes u think..................................................................
<Bike>
i have a toy project for a language with fexprs that can be compiled. it's kind of a pain in the ass though.
<aeth>
Bike: What if you named your slots with gensyms so you can't access the slots with any kind of slot-value thing and can only use the accessors because the symbols for the slots are no longer there?
<Bike>
kernel lets you ADD lexical variables so anything might be shadowed whenever so i think it's pretty impossible.
<jcowan>
Much of what has happened since about 1975 in computer programming has recapitulated the history of Lisp. That's why we are Smug Lisp Weenies (TM): we've had all that for years.
<Bike>
aeth: i was thinking, like, packages, but sure.
<aeth>
Bike: beach's solution is better but it doesn't exist yet
<Bike>
beach's solution to what now?
<aeth>
packages
<greenb>
jcowan: Really? I've seen at least one person claim that it was Smalltalk-80 which got rid of fexpr-like semantics, but I've also seen claims that Smalltalk-76 was the one which dumped actors for a more Simula-like structure.
<Bike>
you mean global environments? i think greenb has been referred to them several times, but is probably not interested in something that isn't fully ipmlemented
<White_Flame>
aeth: can't you enumerate slot names, thus gensyms not hiding anything?
<Bike>
well... deployed.
<Bike>
White_Flame: you'd have to cut out the mop, yes.
<greenb>
Bike: They look interesting, but I haven't yet read through the paper that I just found.
<aeth>
White_Flame: could you use the mop to prevent that or are they required?
<Bike>
they are interesting, but if you're familiar with kernel it probably won't be anything too new to you.
<White_Flame>
I don't know much about the mop
<Bike>
aeth: class-slots is used internally as well. you couldn't have it lie.
<jcowan>
in ST-76 fexprs the keywords were followed by a non-ASCII open colon instead of a colon
<Bike>
well, not without basically writing an entire parallel object system.
<Bike>
which would be stupid.
<jcowan>
I'm not sure if that means the decision was made at the point of call, or if the definitions had to have open colons too
<Bike>
this is what i get for just reading the smalltalk 80 manual instead of embarking on a history project :v
<jcowan>
people who know too much about the MOP risk being arrested for MOPery
<aeth>
Bike: can you have one internal package in one environment and one external-to-use package in another?
<Bike>
each environment can have its own package mapping.
<Bike>
so sure, probably. maybe i don't understand what you mean.
<jcowan>
open colons had two little circles instead of dots
<aeth>
Bike: Implementing a parallel object system seems to be the ultimate end result of trying to do what greenb wants unless there's implementation support.
<Bike>
yep.
termlen0 has quit [Ping timeout: 268 seconds]
<Bike>
CLOS is not built for encapsulation.
<Bike>
lisp is a ball of mud.
smasta has quit [Ping timeout: 250 seconds]
<aeth>
Bike: I was wondering if you could encapsulate symbols (truly private, not just :: to get to them) by having certain packages (but not all of the packages) of a program in some private environment
<Bike>
You could, yes.
<White_Flame>
or just extend the notion of a package itself to have private members
<Bike>
Beach intends to do this for e.g. compiler symbols, in the lisp OS.
lumm has joined #lisp
<aeth>
White_Flame: Yes, you could add that with local nicknames
<aeth>
And a bunch of other necessary extensions
<aeth>
Might as well throw a bunch in
<greenb>
White_Flame: I was considering asking about packages as encapsulation.
<Bike>
nothing in lisp is really very encapsulated.
<Bike>
even closures can sometimes be rifled through by internal but usable tools.
<greenb>
Most "OO" systems are little more than poorly done module/package systems, anyways.
<Bike>
clos isn't that, at least
<Bike>
it ain't smalltalk either tho
<greenb>
Bike: I didn't say it was. CLOS is awesome.
<aeth>
There are two things that makes truly encapsulated packages a bad thing, though. (1) tests (e.g. foo::bar seems okay in tests in some circumstances) and (2) nobody. exports. their. types. (#2 is a bug on the part of like 500 libraries, but it is a bug that can be worked around with the current package system)
<White_Flame>
I don't think symbols are necessarily the proper tool for seeking object-style encapsulation or capabilities. The ability to name something orthogonal to using it is probably useful
<Bike>
i mean if you want security you're going to have to look at lisp's actual modules at some point.
<Bike>
fasls are bundles of side effects, you know?
<Bike>
it ain't helping
frgo has joined #lisp
rpg has quit [Ping timeout: 245 seconds]
<jcowan>
maybe it was ST-72 that had fexprs
<jcowan>
ST-72 definitely had each class parsing its arguments out of the code
lumm has quit [Read error: Connection reset by peer]
benjamin-l has joined #lisp
funnel has joined #lisp
m00natic has quit [Remote host closed the connection]
warweasle has quit [Quit: Night all.]
Lycurgus has quit [Quit: Exeunt]
ryan_vw has quit [Ping timeout: 250 seconds]
zolk3ri has quit [Remote host closed the connection]
kristof has joined #lisp
smasta has joined #lisp
epr0xe has joined #lisp
kristof has quit [Ping timeout: 252 seconds]
rpg has joined #lisp
wanz has joined #lisp
cylb has quit [Ping timeout: 244 seconds]
lumm has joined #lisp
igemnace has joined #lisp
nokdoot has quit [Remote host closed the connection]
nokdoot has joined #lisp
smasta has quit [Ping timeout: 252 seconds]
kristof has joined #lisp
esrse has joined #lisp
emaczen has joined #lisp
kristof has quit [Ping timeout: 252 seconds]
<aeth>
jasom: I didn't mention it earlier because I didn't want to hijack the conversation, but I guess this is what ASDF is doing. < jasom> greenb: that being said, it's possible to implement message-passing OO with CLOS < jasom> e.g. (defmethod send (o (eql 'method1) &rest args) ...)
dddddd has quit [Remote host closed the connection]
pierpal has joined #lisp
nanoz has joined #lisp
pierpal has quit [Read error: Connection reset by peer]
pierpal has joined #lisp
wanz has joined #lisp
pierpal has quit [Ping timeout: 240 seconds]
Sauvin has joined #lisp
arescorpio has joined #lisp
Bike has quit [Quit: Lost terminal]
elfmacs has quit [Ping timeout: 264 seconds]
wanz has quit [Remote host closed the connection]
<beach>
Good morning everyone!
<makomo>
morning!
meepdeew has quit [Remote host closed the connection]
smasta has joined #lisp
cyberlard is now known as TheShitter
ym has joined #lisp
slyrus1 has joined #lisp
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 244 seconds]
smasta has quit [Ping timeout: 240 seconds]
nanoz has quit [Ping timeout: 268 seconds]
kristof has quit [Ping timeout: 252 seconds]
shifty has quit [Ping timeout: 244 seconds]
vlatkoB has joined #lisp
arescorpio has quit [Remote host closed the connection]
makomo has quit [Ping timeout: 252 seconds]
makomo has joined #lisp
ryan_vw has quit [Ping timeout: 250 seconds]
Inline has quit [Quit: Leaving]
asarch has quit [Quit: Leaving]
beach has quit [Disconnected by services]
beach has joined #lisp
elfmacs has joined #lisp
angavrilov has joined #lisp
jcowan has quit [Quit: Connection closed for inactivity]
smasta has joined #lisp
Patternmaster has quit [Remote host closed the connection]
doubledup has joined #lisp
epr0xe has joined #lisp
epr0xe has quit [Client Quit]
beach has quit [Ping timeout: 264 seconds]
smasta has quit [Ping timeout: 244 seconds]
frodef has joined #lisp
beach has joined #lisp
smasta has joined #lisp
Patternmaster has joined #lisp
smasta has quit [Ping timeout: 272 seconds]
frgo has joined #lisp
frgo has quit [Remote host closed the connection]
frgo has joined #lisp
semz has joined #lisp
cylb has joined #lisp
hiroaki has joined #lisp
cylb has quit [Ping timeout: 245 seconds]
scymtym has quit [Ping timeout: 244 seconds]
epr0xe has joined #lisp
shifty has joined #lisp
astalla has joined #lisp
emaczen has quit [Ping timeout: 246 seconds]
makomo has quit [Read error: Connection reset by peer]
<no-defun-allowed>
looking to get gsharp running, what would load the package CLIM-MOP? quickloading MCCLIM didn't reveal it
<beach>
I think it is broken because of changes to McCLIM.
<beach>
I suggest you abandon the attempt for now.
<no-defun-allowed>
well, alright
<no-defun-allowed>
that's a shame, it looked really nice
<no-defun-allowed>
(also i wanted an easy to work with output format/system for trying to notate songs using FFT, but i understand)
fikka has quit [Ping timeout: 245 seconds]
fikka has joined #lisp
makomo has joined #lisp
smokeink has quit [Ping timeout: 252 seconds]
epr0xe has quit [Quit: epr0xe]
scymtym has joined #lisp
<beach>
Gsharp is one of my applications where I made a certain number of mistakes in my first attempt, so a successor is planned. But I don't have time for that right now.
msb has quit [Ping timeout: 245 seconds]
msb has joined #lisp
<beach>
Applications like that are very hard, because there is no existing design to implement. And design ideas often turn out to be sub-optimal. The same happened with (first) Climacs.
<beach>
no-defun-allowed: Now, if you are willing to work on it, that's a different story.
<no-defun-allowed>
well...
<no-defun-allowed>
i don't think i can
<beach>
That's what I suspected.
<no-defun-allowed>
sorry
<beach>
It's OK.
<beach>
It took me a very long time to read up and understand about music engraving. But it was fun.
<no-defun-allowed>
i see
shka_ has joined #lisp
<beach>
There was only one, very thin, book available at the time.
<shka_>
good morning
<no-defun-allowed>
morning shka_
<beach>
Now there is a complete treatise.
<beach>
Hello shka_.
<beach>
no-defun-allowed: In Gsharp, I introduced the concept of a "segment" in order to hope to have an efficient redisplay algorithm. That concept turned out to be incomprehensible to the user. I now have a better idea that will also help the performance, but that will be easier to understand.
<no-defun-allowed>
alright
<beach>
Design is just hard.
kajo has quit [Ping timeout: 250 seconds]
<no-defun-allowed>
indeed it is
deng_cn has quit [Remote host closed the connection]
deng_cn has joined #lisp
<beach>
Anyway, let me take advantage of this discussion to say that I am very happy with the significant and rapid progress being made on McCLIM, and with the fact that there are now several people working to improve it. It is definitely time for people who write GUI applications in Common Lisp to consider using McCLIM (perhaps adding a feature or two that they might need and that is currently missing), rather than one of the FFI-based
<beach>
solutions.
Patternmaster has quit [Ping timeout: 268 seconds]
<beach>
Recently, McCLIM has been used to create several important development tools like a flame-graph viewer and viewers for intermediate code. And Clouseau (the inspector) is being worked on as well.
jochens has joined #lisp
<no-defun-allowed>
mcclim is much nicer to work with, coming from the hellholes of tkinter and gtk
<no-defun-allowed>
you don't have to work out which layout pieces fit where and keep a tree of instances in your head, you just lay it out as a tree in lisp
<beach>
I am willing to believe you. I never tried using them. It was much easier for me to first work on McCLIM and then use it to implement what I needed. :)
<no-defun-allowed>
it's very nasty
Folkol has joined #lisp
<shka_>
flame-graph viewer is superbly useful tool
<beach>
Yes, especially with all the features of the one currently being worked on by scymtym.
<shka_>
scymtym: it looks way better the last time i tried
<beach>
no-defun-allowed: Thanks for the example.
<no-defun-allowed>
no problem c:
<shka_>
scymtym: truely outstanding work
<scymtym>
shka_: yes, it handles threads and zooming (two kinds) much better now. and performance has improved (some of that worked was in mcclim and even SBCL, though)
<no-defun-allowed>
nice
<scymtym>
shka_: thanks. it is actually relatively straightforward (clim is great for that kind of thing). just putting pieces together
ggole has joined #lisp
<shka_>
well, it already was hugely useful in it's previous state
<shka_>
despite poor performance
<shka_>
now it looks crazy good
<scymtym>
i wouldn't go that far
<scymtym>
but i hope to improve it further
<shka_>
well, please do :-)
varjag has joined #lisp
hvxgr has quit [Ping timeout: 246 seconds]
nirved has joined #lisp
frodef has quit [Ping timeout: 272 seconds]
MichaelRaskin has quit [Quit: MichaelRaskin]
xkapastel has joined #lisp
ogamita has joined #lisp
beach has quit [Ping timeout: 252 seconds]
asymptotically has joined #lisp
beach has joined #lisp
fikka has quit [Ping timeout: 250 seconds]
siraben has quit [Remote host closed the connection]
Jach[m] has quit [Remote host closed the connection]
xylef has quit [Remote host closed the connection]
no-defun-allowed has quit [Write error: Connection reset by peer]
Gnuxie[m] has quit [Write error: Connection reset by peer]
Manny8888 has quit [Read error: Connection reset by peer]
LdBeth has quit [Remote host closed the connection]
Jachy has quit [Remote host closed the connection]
Folkol has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
msb has quit [Ping timeout: 252 seconds]
thinkpad has quit [Ping timeout: 252 seconds]
masterdonx has quit [K-Lined]
thinkpad has joined #lisp
msb has joined #lisp
GDPR has quit [Remote host closed the connection]
GDPR has joined #lisp
heisig has joined #lisp
hhdave has joined #lisp
Manny8888 has joined #lisp
fikka has joined #lisp
doubledup has quit [Quit: Leaving]
ogamita has quit [Ping timeout: 250 seconds]
Folkol has joined #lisp
ogamita has joined #lisp
xylef has joined #lisp
nowhere_man has quit [Remote host closed the connection]
ogamita has quit [Read error: Connection reset by peer]
ogamita has joined #lisp
angavrilov has joined #lisp
Folkol has joined #lisp
lumm has quit [Quit: lumm]
kristof has joined #lisp
lumm has joined #lisp
beach has quit [Ping timeout: 252 seconds]
beach has joined #lisp
Bike is now known as Bicyclidine
ogamita has quit [Ping timeout: 252 seconds]
kooga has quit [Ping timeout: 252 seconds]
<luis>
I've seen some libraries that expand on CL-WHO's (and net.html.generator's) ideas. E.g.: spinneret. Has anyone done the same for the HTML generator bits of YACLML? I'm pondering updating YACLML for HTML5, but I suspect someone must have done this already.
akovalenko has joined #lisp
kristof has quit [Ping timeout: 252 seconds]
kooga has joined #lisp
ogamita has joined #lisp
quazimodo has quit [Ping timeout: 240 seconds]
elfmacs has joined #lisp
quazimodo has joined #lisp
cylb has joined #lisp
neirac has joined #lisp
papachan has joined #lisp
frgo has joined #lisp
thijso has joined #lisp
ogamita has quit [Ping timeout: 252 seconds]
ogamita has joined #lisp
igemnace has quit [Quit: WeeChat 2.3]
Essadon has joined #lisp
Guest13389 has quit [Ping timeout: 240 seconds]
<pfdietz>
I will, unfortunately, not be able to attend ELS 2019. Something that is not movable is scheduled for that week that has priority.
<antoszka>
Easter?
<pfdietz>
No
Guest13389 has joined #lisp
frodef has joined #lisp
<hypnon>
pfdietz: It's a C++ conference, isn't it? ;)
<flip214>
hjudt: interesting. can it use a local QL mirror URL (to have exact versions), too?
sjl has joined #lisp
<flip214>
and a chance to start the vlime lisp helper instead of slynk would be very nice as well ;)
sunset_NOVA has quit [Quit: leaving]
<shka_>
so regarding this vlime
<shka_>
i don't use vim nowdays
<shka_>
but many would want to use vim to edit CL
<shka_>
should i recommend vlime for that?
<shka_>
i heared good thinks about it
<luis>
vlime looks decent, but I haven't actually tried it. There's also evil-mode for Emacs, would that fly?
<flip214>
shka_: I'm using it, and I know one or two others.
<flip214>
luis: evil-mode doesn't work for me -- too many keybindings missing.
<luis>
flip214: do spacemacs or doom-emacs make any difference? Is vlime the one you'd recommend for VIM users?
<shka_>
well, i was recommending evil mode up to now
ogamita has quit [Ping timeout: 268 seconds]
ogamita has joined #lisp
troydm has quit [Ping timeout: 252 seconds]
<flip214>
luis: either that, or slimv.
<flip214>
I've switched to vlime and have my own fork, so there you go.
<knobo>
How do I print out a stactrace in sbcl?
<knobo>
Found it: (SB-DEBUG:BACKTRACE-AS-LIST)
<shka_>
flip214: vlime > slimv?
<luis>
flip214: BTW, if you have suggestions on how to make SWANK more friendly towards clients other than SLIME, I'd like to hear them. (Things like adding some sort of versioning to the protocol, or making it fail more gracefully when certain features aren't present, etc.)
fikka has quit [Ping timeout: 264 seconds]
<flip214>
shka_: IMO, yeah.
<flip214>
luis: a native JSON output (instead of needing a separate lisp thread for that translation) would be nice.
<flip214>
luis: perhaps triggered by a first message starting with #\{ instead of the swank-message-length in hex?!
<luis>
flip214: why is the current protocol hard to parse in vimscript?
<splittist>
No wonder humans are doomed. As a mere sack of meat, my instinctive thought is that the way to get from Geneva to Genoa by train is to get a train to Milan, and then another train to Genoa. But, no. Our silicon overlords, using computing resources literally unimaginable to me, have determined that the proper route involves four changes of train, takes 30% longer, and costs twice as much. (The lisp content is the ELS2019
<splittist>
reference.)
<flip214>
parsing S-expressions byte per byte in vimscript is not that nice - especially with bigger data chunks (input latency) or higher bandwidth (debug output)
ogamita has quit [Remote host closed the connection]
<jdz>
flip214: have you tried God mode?
<flip214>
jdz: idkfa? oh no, iddqd it was. no, what is that?
<flip214>
jdz: thanks. no, sorry, I'm too heavily invested in the vim world... plugins, muscle memory, ...
<jdz>
Right.
fikka has quit [Ping timeout: 268 seconds]
rpg has joined #lisp
frgo has quit [Remote host closed the connection]
<flip214>
not that I didn't try every few years... but I'm too old to switch ;)
<luis>
flip214: I see. JSON feels a bit dirty for a Lisper, but perhaps we can extend SWANK such that you apply a bidirectional translation hook somewhere? It seems like you might already be doing something like that?
meepdeew has joined #lisp
nicksmaddog has joined #lisp
<flip214>
luis: vlime starts a new thread in the inferior lisp that connects to swank and translates to/from JSON.
Volt_ has quit [Ping timeout: 272 seconds]
<flip214>
luis: perhaps vlime could push a single (CHANGE-CLASS *swank-socket* 'json-swank-socket) command (via the slime-interface) and already receive the result as json?
semz has joined #lisp
SaganMan has joined #lisp
<luis>
flip214: I'm always keen to find out a legitimate use-case for CHANGE-CLASS, but perhaps it'd be easier to convert the sexp before it's serialised and written to the socket, no?
LiamH has joined #lisp
fikka has joined #lisp
Jesin has quit [Quit: Leaving]
<sjl>
I'm one of the "one or two others" using Vlime with Neovim and it works pretty well.
frgo has joined #lisp
<sjl>
flip214: I've been meaning to dig into a Vlime bug, but maybe you have an idea of where I should look
<sjl>
flip214: evaluating something that results in a raw ASCII escape in the output kills all further output from Vlime
<sjl>
e.g. eval (disassemble '(lambda () #.(string #\Escape))), which will have a raw escape byte in the output because SBCL includes the string literal "ESC"
elfmacs has quit [Ping timeout: 252 seconds]
frgo has quit [Ping timeout: 240 seconds]
vtomole has joined #lisp
troydm has joined #lisp
kristof has joined #lisp
kristof has quit [Ping timeout: 252 seconds]
smasta has joined #lisp
frgo has joined #lisp
frgo has quit [Read error: Connection reset by peer]
frgo has joined #lisp
warweasle has joined #lisp
meepdeew has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 244 seconds]
sabrac has quit [Ping timeout: 244 seconds]
nly has joined #lisp
jochens has quit []
varjag has quit [Quit: ERC (IRC client for Emacs 25.2.2)]
meepdeew has joined #lisp
fikka has joined #lisp
Zaab1t has joined #lisp
anamorphic has joined #lisp
noark9 has quit [Quit: noark9]
Bronsa has joined #lisp
nly has quit [Read error: Connection reset by peer]
meepdeew has quit [Ping timeout: 252 seconds]
fikka has quit [Ping timeout: 246 seconds]
nly has joined #lisp
noark9 has joined #lisp
fikka has joined #lisp
papachan has quit [Quit: WeeChat 2.2]
quazimodo has quit [Ping timeout: 240 seconds]
nokdoot has quit [Remote host closed the connection]
noark9 has quit [Client Quit]
nokdoot has joined #lisp
nokdoot has quit [Max SendQ exceeded]
nokdoot has joined #lisp
nokdoot has quit [Max SendQ exceeded]
nokdoot has joined #lisp
frgo has quit [Remote host closed the connection]
noark9 has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
nirved has quit [Killed (niven.freenode.net (Nickname regained by services))]
nirved has joined #lisp
Inline has joined #lisp
Bicyclidine has quit [Ping timeout: 240 seconds]
kristof has joined #lisp
robotoad has joined #lisp
vlatkoB has quit [Remote host closed the connection]
m00natic has quit [Ping timeout: 240 seconds]
kristof has quit [Ping timeout: 260 seconds]
svillemot has quit [Ping timeout: 264 seconds]
vlatkoB has joined #lisp
svillemot has joined #lisp
Bicyclidine has joined #lisp
frgo has joined #lisp
fikka has joined #lisp
cmjones has quit [Ping timeout: 240 seconds]
theBlackDragon has joined #lisp
frgo has quit [Remote host closed the connection]
frgo has joined #lisp
m00natic has joined #lisp
varjag has joined #lisp
cmjones has joined #lisp
<jcowan>
That reminds me: do Lisps typically tolerated quoted unrepresentable objects in the forms passed to eval, like (eval '(list quote (find-class "CL")))?
<dlowe>
you mean `(list quote ,(find-class "CL"))?
<jcowan>
yes
<dlowe>
they just evaluate as themselves
<Bike>
representability is independent of being self evaluating, yeah
<Bike>
also that might not be a good example since classes do have a make-load-form, though not a readable form
scymtym has quit [Ping timeout: 264 seconds]
<jcowan>
yes, it seems to follow from definition 2 of "form"
<Bike>
eval is basically (typecase form (symbol ...) (cons ...) (t form))
frodef has quit [Ping timeout: 245 seconds]
<beach>
jcowan: So you don't even need to quote it. (eval (find-class ..)) works too.
shifty has quit [Ping timeout: 240 seconds]
elderK has quit []
shka_ has quit [Quit: WeeChat 1.9.1]
<Bike>
oh, wait, i do remember that oleg thing about implementing quote with a representation deal
rippa has joined #lisp
<beach>
Time to prepare some "treats" to avoid some "tricks".
epr0xe has joined #lisp
pjb has quit [Ping timeout: 264 seconds]
hiroaki has quit [Ping timeout: 250 seconds]
<jcowan>
I tried a few Schemes; all of them can handle unprintable objects when quoted, but some cannot cope with unquoted unprintables, even though they are self-evaluating
<beach>
Maybe Scheme does not have the strict evaluation rule that Common Lisp does.
<jcowan>
What do you mean by strict? Both of them are strict languages.
<beach>
I meant "strict" in the common meaning of the term. Not in the technical sense of "innermost evaluation".
<beach>
Let me rephrase...
<beach>
In Common Lisp, every datum can be passed to EVAL for evaluation, and the value is well defined. Perhaps that is not the case with Scheme. Just a suggestion of course. I don't know the answer.
<beach>
Replace "the value is well defined" by "the result is well defined". The form may not have a value of course.
kristof has joined #lisp
nokdoot has quit [Quit: Leaving]
lumm has quit [Ping timeout: 252 seconds]
ggole has quit [Quit: ggole]
kristof has quit [Ping timeout: 264 seconds]
<jcowan>
Ah, thanks. I had to poke around a bit, but Scheme defines a constant expression as either a quoted datum, where a datum is the external representation of a Scheme object, or else one of six types of literals (number, string, character, vector, bytevector, boolean). Therefore the application of eval to a non-datum is a licit but definitely not required extension, and I was wrong to say that Scheme has adopted the CL rule here.
<Bike>
is an "external representation" not like, text?
<jcowan>
Bike: Yes it is, so I may have misunderstood something
<Bike>
So in Scheme you could evaluate (quote "(A)") and get a list?
<Bike>
that can't be right.
<sjl>
flip214: huh, am I not using the latest code? weird.
<flip214>
sjl: you haven't merged my latest changes, at least ;)
<sjl>
welp
<flip214>
sjl: pull again, just pushed a few more commits
<jcowan>
No, the term "external representation" is definitely used in two senses in the standards, one which "(A)" is an external representation of a list and another in which (A) is. This probably calls for an erratum. In any case, clearly the second sense is intended in the discussion of literals, and when not considering eval, it is mostly a distinction without a difference.
<sjl>
flip214: cool, thanks
<sjl>
nice, this works now
<jcowan>
Eval first appeared in R5RS (1998), though most if not all implementations had it long before.
<sjl>
I can stop losing my mind when trying to disassemble ANSI-escape-seq-emitting functions
<flip214>
luis: well, perhaps it would make sense to keep the length marker and just have a different line representation, right
<Bike>
oh this is that thing where scheme defines things more in terms of text than in terms of list structure, eh
<jcowan>
R6RS says that the first argument to eval must be a syntactically valid Scheme expression represented as a datum, a small improvement unfortunately not inherited by R7RS.
<flip214>
sjl: that hurt me as well, that's why I "fixed" it. Not all characters are currently treated that way...
<jcowan>
No, Scheme doesn't define things in terms of text. (DKLisp does.)
<flip214>
sjl: if you do some more, please leave a message so that I do a targetted pull from your repo ;)
<sjl>
flip214: Do you know what exactly is breaking? JSON should allow ESC bytes in strings, I think...
<flip214>
luis: one point that might be worth discussion is how to encode symbols for JSON...
<Bike>
Well I mean why is it talking about syntactic validity in relation to a function at all?
<Bike>
or maybe it's "represented as"
<Bike>
something is tripping me up
<flip214>
sjl: I first fixed that for NULs, because of encode_json():
<flip214>
+ "Handling of NUL would need special code; see ':help json_encode' for details.
<flip214>
+ So we just patch NULs out.")
<flip214>
luis: a simple ":" might break for symbols containing a ":"... OTOH, vlime currently sends a dictionary with {"name": "foo", "package": "KEYWORD"}, which is awful, too
DGASAU has quit [Remote host closed the connection]
<sjl>
:h json_encode says that non-printing chars will just be dumped as \uhhhh which seems fine
<flip214>
luis: I'm pondering whether an ASCII SOH (\002) or so would be a good choice - I'd like to compare the received symbols via a simple string compare, not have to check a whole dictionary
DGASAU has joined #lisp
<jcowan>
actually, I think DKLisp has the same equivocation as Scheme, which caused Henry Baker to claim that they defined things in terms of text, I think incorrectly.
noark9 has quit [Quit: noark9]
<flip214>
luis: what's your opinion about msgpack?
doubledup has joined #lisp
doubledup has quit [Remote host closed the connection]
<flip214>
sjl: yeah, but NUL and a few others cause some special dictionary structures to be returned, which would need special handling
<jcowan>
flip214: Meta-Control-Q and Meta-Control-R are specifically reserved as private-use control characters
<jcowan>
coopting one to mean "What follows is a Lisp datum, not a literal string" might make sense, and it generalizes to all sorts of objects
Bronsa has quit [Remote host closed the connection]
<flip214>
jcowan: well, with msgpack such extra types would be possible, too
<jcowan>
"M-C-Q#2a((1 2 3) (4 5 6))" could be used to transmit an array to a cooperating receiver, leaving the JSON layers none the wiser.
heisig has quit [Quit: Leaving]
<jcowan>
#\x91 that is
epr0xe has quit [Quit: epr0xe]
emdeesee has quit [Read error: Connection reset by peer]
<luis>
flip214: I didn't know about msgpack before. Can vimscript parse it easily? Regarding keywords, {"symbol": "foo:bar"}? I'm not sure what the context is.
<sjl>
ah
frodef has joined #lisp
fikka has quit [Ping timeout: 244 seconds]
astronavt has joined #lisp
<flip214>
jcowan: would make more sense to use JSON encoding then, IMO ;)
<jcowan>
or even "\u0091(lambda (x) (x + 1)", though you would want to sandbox that carefully.
<jcowan>
or no, you don't need to; that's a list, not a procedure
<jcowan>
whew
<flip214>
luis: well, comparing a simple string would be preferred - because of the number of places in the code.
<jcowan>
flip214: I don't understand
<flip214>
luis: SWANK sends messages, with keywords in some places: eg. like "000015(:return (:ok nil) 7)"
smasta has quit [Ping timeout: 252 seconds]
<flip214>
luis: vlime currently translates that to this: [8,[{"name":"RETURN","package":"KEYWORD"},[{"name":"OK","package":"KEYWORD"},null]]]
<flip214>
which is quite awful to check in vimscript.
nly has quit [Read error: Connection reset by peer]
<flip214>
therefore I'm pondering whether ":return" as a string would be good enough -- or what would be the best way to encode the package information.
<luis>
flip214: OK, I see what you mean. SLIME does pattern matching against these. What sort of pattern matching facilities do you have with JSON/Vimscript?
<flip214>
perhaps "\002RETURN", and |foo:bar|:|BaZ| would then be "foo:bar\002BaZ". might be good enough
<flip214>
luis: what I've seen so far all "pattern matching" is done via "if"s...
<sjl>
assuming nothing ever needs to actually send an ascii STX char in a string, that could work
<luis>
flip214: Emacs Lisp doesn't have packages, so treating symbols as strings seems like a safe bet.
<flip214>
my last change is a function vlime#KeywordList2Dict that converts such a list of {name: package:} dictionaries into a plain vim dict for processing
<flip214>
luis: yeah, but what about symbols containing a ":" in the name or package?
<flip214>
sjl: that's my hope, yeah. any better ideas? NUL doesn't feel that better - and JSON data with NULs needs special treatment again.
blackwolf has joined #lisp
<flip214>
luis: so, if you'd create some JSON or msgpack mode for swank, please tell me - I'll help rewrite vlime.
<luis>
flip214: Those symbols in swank messages are not arbitrary. Symbols from user code are encapsulated in strings when SWANK passes them around.
lnostdal has quit [Read error: Connection reset by peer]
<luis>
flip214: adding a hook for changing the protocol format with some sort of plugin seems like the most likely possibility.
nanoz has joined #lisp
<sjl>
There will always be pathological cases. Probably picking something like STX or DLE as a first magic byte and then encoding however you want after that is likely fine
<sjl>
If you wanted to be extra safe, you could also tag strings with a magic first byte, but then you'd have to strip it off everywhere user-facing, which would be pretty miserable.
kristof has joined #lisp
fikka has joined #lisp
m00natic has quit [Ping timeout: 260 seconds]
nly has joined #lisp
kristof has quit [Ping timeout: 252 seconds]
fikka has quit [Ping timeout: 244 seconds]
shka_ has joined #lisp
ski has quit [Ping timeout: 246 seconds]
nly has quit [Ping timeout: 268 seconds]
Sauvin has quit [Remote host closed the connection]
scymtym has joined #lisp
masterdonx has joined #lisp
igemnace has joined #lisp
masterdonx has quit [K-Lined]
smasta has quit [Ping timeout: 240 seconds]
smasta has joined #lisp
anamorphic has quit [Quit: anamorphic]
fikka has joined #lisp
<p_l>
copy-pasting code from Genera kernel can have unexpected consequences :/
<p_l>
SBCL is too good at opencoding defconstant lists ;)
groovy2shoes has quit [Quit: moritura te salutat]
fikka has quit [Ping timeout: 240 seconds]
rumbler31 has joined #lisp
hhdave has quit [Ping timeout: 268 seconds]
frodef has quit [Ping timeout: 260 seconds]
smasta has quit [Ping timeout: 245 seconds]
smasta has joined #lisp
rumbler31 has quit [Remote host closed the connection]
kristof has joined #lisp
Kaisyu has quit [Quit: Connection closed for inactivity]
angavrilov has quit [Remote host closed the connection]
nanoz has quit [Ping timeout: 252 seconds]
SaganMan has quit [Quit: WeeChat 1.6]
anamorphic has joined #lisp
smasta has quit [Ping timeout: 260 seconds]
xrash has joined #lisp
eddof13 has joined #lisp
orivej has quit [Ping timeout: 268 seconds]
fikka has joined #lisp
groovy2shoes has joined #lisp
asarch has joined #lisp
fikka has quit [Ping timeout: 252 seconds]
<flip214>
sjl: luis: please see my topmost commit for some small enhancement re JSON keyword translation.
eddof13 has quit [Quit: eddof13]
eddof13 has joined #lisp
ski has joined #lisp
orivej has joined #lisp
dueyfinster has joined #lisp
<luis>
flip214: where?
saturn2 is now known as skeleton2
eddof13 has quit [Quit: eddof13]
frodef has joined #lisp
eddof13 has joined #lisp
slyrus2 has joined #lisp
<anamorphic>
When I create a defun with keyword arguments, e.g. (defun foo (&key bar baz) ...), can I expect to find the keys ("BAR" and "BAZ") interned into the keywords package afterwards? Or, does that happen the first time I call the function (i.e the first time I call (foo :bar 231)
slyrus2 has quit [Read error: Connection reset by peer]
smasta has joined #lisp
Patternmaster has joined #lisp
anamorphic has quit [Quit: anamorphic]
papachan has joined #lisp
anamorphic has joined #lisp
<Bike>
anamorphic: what do you have depending on this?
emaczen has quit [Ping timeout: 268 seconds]
<sjl>
I'd be surprised if they weren't, but I don't know whether the standard *requires* it.
<anamorphic>
I was playing with symbol property lists, and the possibility of using them to attach metadata to keyword args. e.g. if I have some a keyword arg, :foo-callback, I was experiementing attaching metadata about the shape of the callback's argument list
emdeesee has joined #lisp
Lycurgus has joined #lisp
pjb has joined #lisp
eddof13 has quit [Quit: eddof13]
<shka_>
anamorphic: that wont work
<shka_>
#'(setf car) is a function, yes, but its name is not a symbol
<shka_>
you can hack around it
<shka_>
but you are better off doing this differently probably
<shka_>
also, symbol can name more then just a function, therefore possibility of collision exists
jmercouris has joined #lisp
Salvakiya has joined #lisp
<Salvakiya>
any good lisp/scheme game engines out there?
<Salvakiya>
maybe something like raylib for C or Love2D for lua?
<sjl>
Salvakiya: might want to check out #lispgames
<Salvakiya>
thanks =)
<pjb>
shka_: (setf car) may happen to be a function in your implementation, but it is not necessarily the case in Common Lisp.
nly has joined #lisp
<pjb>
It's not because you can write (setf (car k) a) that you can write (let ((vk k) (va a)) (funcall (fdefininition '(setf car)) va vk)).
<makomo>
anamorphic: hmm, interesting question. keyword symbols are by definition symbols interned within the KEYWORD package. this happens either when the code is read (if your keyword symbols appears within the source) or when you call INTERN.
<anamorphic>
I tried (defun foo (&key bar baz quux) (values bar baz quux)) and then (find-symbol "QUUX" (find-package "KEYWORD")) and it does seem to create the keywords before I using the function
<makomo>
what about this (evaluated one after another, at the repl)
<makomo>
i get #:THERE as the result of the last form :-)
<anamorphic>
Curious though, symbols can be internal or external to a package: in the case of the keyword package is there any point to an *internal* keyword?
smasta has joined #lisp
<makomo>
although, my example isn't accessing the keyword symbol of the keyword argument
<makomo>
of the keyword formal parameter*, or w/e
eddof13 has joined #lisp
<makomo>
i'm accessing the keyword symbol that was passed as the argument
<pjb>
makomo: when you unintern a symbol, it doesn't lose its identity. It is still referenced everywhere it's referenced (but its home package).
<jasom>
anamorphic: interning a symbol in the keyword package automatically makes it external, per the above referene
<pjb>
Also, &key doesn't take keywords, but symbols in general. An uninterned symbol is good for a &key keyword.
<makomo>
pjb: yeah, i understand. but the question is whether one can rely on it being interned in the KEYOWRD package
<pjb>
which symbol?
<makomo>
pjb: yes, i'm also aware of that, i mentioned it above, so it doesn't directly address his/hers concern
<makomo>
pjb: the keyword symbol which names the keyword parameter
<anamorphic>
Cool I did not know keyword package worked differently
<jasom>
anamorphic: I would guess that merely defining a function with the lambda list (foo &key bar) will not intern anything in the keyword package, but I don't know that it's defined one way or the other.
<jasom>
actually I can think of cases where it would; in order to optimize the function, it might need a reference to the keyword, which would require interning.
pfdietz has quit [Remote host closed the connection]
<jasom>
But I'm pretty sure doing it either way would be allowed under the spec.
<makomo>
but i'm curious as to why it fails without the PROGN. won't the third form intern :hello again?
<makomo>
pfdietz: ohhh right, i see
<jasom>
are any of these well-formed programs?
<makomo>
pfdietz: it will intern it, but it will be a different symbol
<makomo>
right
<makomo>
spooky as hell :-D
<pfdietz>
OOOOOoooooOOoooooo
<kristof>
I haven't read most of this discussion but why are we trying to unintern keywords
<makomo>
spooky scary keywords
<Bike>
is uninterning a keyword even allowed
<kristof>
does uninterning count as modifying a package?
<kristof>
I think keywords are effectively constants, anyway
<makomo>
does interning count as modifying a package? :D
<pjb>
makomo: because after the unintern, the test definition is: (defun test (&key ((#:hello hello))) (list #:hello (symbol-package :hello))) #| --> test |# (test :hello 'foo) #| ERROR: Incorrect keyword arguments in (:hello foo) . |#
<jasom>
ah, this is well defined; keyword parameters are not required to be keywords, they can be any symbol
<makomo>
pjb: that doesn't explain the crux of the problem, but i got it already
<jasom>
so yes, defining a function with a keyword parameter must intern the symbol into the keyword package, as it needs to resolve it to a symbol. It's at least strongly implied by the spec, so I was wrong.
<makomo>
i thought about that, but thought that "foo" automatically gets interpreted as ":foo" or something. neat!
<drmeister>
Stories about "Lost faith in Lisp" need counter stories.
<jasom>
(&key foo) gets interpreted as (&key ((:foo foo)))
<makomo>
jasom: mhm
kristof has quit [Quit: WeeChat 2.1]
<makomo>
jasom: so by the time the function is called, you have the guarantee that the symbol is interned. what about CLOS methods though? :-) what about a :before method uninterning a keyword symbol for the primary method?
<pfdietz>
I wonder how many lisps parse ::x as :x. Undefined in the standard what happens there.
<pjb>
I get twice ((:hello :external) :hello (:hello #1=#<Package "KEYWORD"> 42) (:hello #1# 42)) I expected ((nil nil) #:hello (#:hello nil 42) (:hello #<Package "KEYWORD"> 42)) after unintern…
<pjb>
abcl reads :|:X| the others :x
<makomo>
"so by the time the function is called, you have the guarantee that the symbol is interned", scratch that, obviously not true
eddof13 has joined #lisp
parjanya has quit [Ping timeout: 252 seconds]
MichaelRaskin has joined #lisp
Zaab1t has quit [Quit: bye bye friends]
smasta has quit [Ping timeout: 240 seconds]
papachan has quit [Quit: WeeChat 2.2]
jxy has joined #lisp
<jasom>
makomo: when the function is called it *was* interned at some point previously
eddof13 has quit [Quit: eddof13]
<jasom>
actually you don't even have that; a macro could create a function with a gensym as an argument (it requires a macro because the key name is not evaluated in the lambda list)
eddof13 has joined #lisp
<makomo>
indeed :-)
jmercouris has quit [Ping timeout: 260 seconds]
<jasom>
(defvar *foo* (gensym)) (eval `(defun test (&key ((,*foo* foo))) foo)) (test *foo* 1) ;<-- example
vlatkoB has quit [Remote host closed the connection]
ubii has joined #lisp
anamorphic has quit [Quit: anamorphic]
<jcowan>
you definitely can unintern a keyword from the keyword package, and then it becomes a regular homeless symbol; if you recreate the keyword it is not eq to the uninterned keyword
<jcowan>
also, you can import a keyword into a package, which never occurred to me to try before
dueyfinster has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
dueyfinster has joined #lisp
emaczen has joined #lisp
cyberlard is now known as omg_creepy_spide
omg_creepy_spide is now known as spiderlard
maarhart has joined #lisp
shka_ has quit [Ping timeout: 272 seconds]
eddof13 has joined #lisp
<anamorphic>
sjl: How does that work? Hows k get set to NIL?
<pfdietz>
It doesn't
<sjl>
k doesn't get set to nil. Initiall (keywordp k) returns t, because it's a keyword. But after you unintern it from the keyword package it's no longer a keyword, because the definition of being a keyword is that it's interned in the keyword package
<anamorphic>
Oh I read that incorrectly...
blackwolf has quit [Quit: ERC (IRC client for Emacs 25.3.1)]
<sjl>
so the second (keywordp k) returns nil
<anamorphic>
What is the value of K if it were the last thing in the let form?
<sjl>
it would be the (now not interned anywhere) symbol
<anamorphic>
Ohhh... #:foo
<anamorphic>
Now I kind of get what uninterned keywords are handy... well not really
Roy_Fokker has joined #lisp
fikka has joined #lisp
<anamorphic>
Why /do/ we use uninterned keywords in (defpackage #:foo ...) ?
<aeth>
Microoptimization. "FOO" is even more of one
<sjl>
There's no real reason to unintern a keyword -- may as well just do (make-symbol "FOO") and you'll end up with an uninterned symbol with less screwing around
fikka has quit [Client Quit]
fikka has joined #lisp
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
<sjl>
well, it won't be bound to itself etc, but yeah
frgo has quit []
<pfdietz>
The issue with using "FOO" is you're assuming the lisp has readtable-case of :upcase
<anamorphic>
Is it done to not put things unnecessarilly in the keyword package?
<sjl>
yes
<sjl>
Or to not unnecessarily put it into ANY package
<pfdietz>
Right, to not create a symbol there. Less important in these days of cheap memory.
<pfdietz>
In practice, it doesn't matter.
<sjl>
Also: there's no such thing as an "uninterned keyword". Once a symbol has been uninterned from the keyword package, it's by definition no longer a keyword.
<rme>
yeah, these days you don't really have to worry about saving symbols in order to fit on a floppy.
<aeth>
I'm kind of surprised this remained. Usually Lisp libraries are happy to be inefficient :-p
<sjl>
#:foo is an "uninterned symbol", but it's not a keyword (any more)
<aeth>
rme: How many floppies is SBCL?
<aeth>
(64-bit)
<rme>
fortunately, you don't have to worry about it!
<pfdietz>
(looks at binary) sbcl.core is ~37MB
<pfdietz>
the binary itself, 1.7MB
<anamorphic>
So what is the general community preference around defpackage with string vs. keyword vs. uninterned keyword reader macro thing
<pfdietz>
My preference is to not worry about it.
<rme>
that's a good preference
<sjl>
Same. It's fairly evenly split, and in practice just doesn't really matter much any more.
<anamorphic>
OK cool. I feel like I'm learning a ton this evening
frgo has joined #lisp
<pfdietz>
We can argue about much more important and currently relevant things, like vi vs. emacs or Lisp-1 vs. Lisp-N.
<aeth>
no
<pfdietz>
:)
<aeth>
If you want to start a flamewar say "CL needs an updates standard"
<aeth>
*updated
makomo has quit [Quit: WeeChat 2.2]
<aeth>
Alternatively, even hint at your code not being fully portable.
<aeth>
Oh, another good one: ask a question about using a library via the CFFI instead of just using pure Lisp.
<xkapastel>
i really cannot understand the idea behind Lisp-N though
<pfdietz>
The choice of Lisp-N is valuing pragmatics over theoretical purity.
<xkapastel>
what is pragmatic about lisp-n?
<ecraven>
xkapastel: you can name a function and a value the same
<sjl>
Once you get used to naming your parameters with actual words, you'll weep when you have to go back to a language that makes you mangle them.
<pfdietz>
You don't have to worry about collisions between particular namespaces that are used separately anyway.
<ecraven>
pfdietz: the main problem I have with lisp-2 is that they are *not* in fact entirely distinct (see funcall)
<ecraven>
or mapcar, or any number of higher-order functions
<pfdietz>
Ah, funcall (and function) are explicit mappings between those namespaces, when you want to use one in positions that defaults to the other.
<pfdietz>
mapcar/etc. are not Lisp-1/N issues. Both have higher order functions.
<ecraven>
(mapcar #'+ ..) vs. (mapcar + ..)
<ecraven>
how is that not a lisp-1 / lisp-n issue?
<pfdietz>
That's nothing to do with mapcar
<pfdietz>
That's function/funcall.
anamorphic has quit [Quit: anamorphic]
<pfdietz>
#'+ ==> (function +)
<ecraven>
anyway, that's the point I was trying to make. sometimes it is useful that + can be both a value and a function (in lisp-1). but sometimes, it's nice that you can name a parameter 'list' and *still* use the function 'list'
<ecraven>
(define (foo list) (.. (list ..))) in Scheme has happened more than once to me
<ecraven>
why can't the compiler just magically figure out what I meant :P
cylb has quit [Ping timeout: 240 seconds]
anamorphic has joined #lisp
<xkapastel>
i'm also a fan of concatenative languages so this reasoning is so strange to me
<pfdietz>
CL could be properly criticized for not separating lexical and special variable namespaces. The ears convention is a way of doing that socially.
<xkapastel>
i want *less* variable naming, not more and fancier names that even conflict with other things
<ecraven>
xkapastel: I've tried that, but keeping the stack layout in my mind isn't as easy as I had hoped :-/
<xkapastel>
if i thought my variables were gonna conflict with stuff i would write some combinators so there are just no variables at all
<ecraven>
xkapastel: ah, but they are still there, they just don't have names...
<xkapastel>
...
<xkapastel>
yeah, the variable is the name
<xkapastel>
maybe a terminology difference?
<ecraven>
maybe I'm misunderstanding what you mean
<xkapastel>
variable = name
<ecraven>
I'd say the variable's location is bound to the name
<xkapastel>
the name is bound to a value
kajo has joined #lisp
<xkapastel>
or i suppose a slot, in a mutable language
<sjl>
I have enough trouble remembering the correct order of gethash's arguments even with the (gethash key hash-table &optional default) arglist window staring me in the face. Not having names for parameters would be too much for my stupid brain.
<sjl>
I have no idea why gethash's parameter order consistantly trips me up more than any other function's.
arbv has quit [Ping timeout: 272 seconds]
arbv has joined #lisp
jmercouris has joined #lisp
eddof13 has quit [Quit: eddof13]
semz has quit [Quit: Leaving]
<Xach>
sjl: i have the ordering internalized but i often swap arguments anyway
<Xach>
it's not like i forget, i just write it wrong
<Xach>
"just"
LiamH has quit [Quit: Leaving.]
Bike has quit []
eddof13 has joined #lisp
eddof13 has quit [Client Quit]
eddof13 has joined #lisp
<cgay>
it's backwards compared to elt and aref. (elt sequence index) (aref array subscripts) (gethash key table)
<anamorphic>
I think it's also unlike getf
greenb has quit [Ping timeout: 250 seconds]
<anamorphic>
I just remember it as "It's not what you thought"
<cgay>
chuckle
dueyfinster has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<cgay>
(defun hashget (table key) ...)
jmercouris has quit [Ping timeout: 268 seconds]
Essadon has quit [Quit: Qutting]
anamorphic has quit [Quit: anamorphic]
anamorphic has joined #lisp
anamorphic has quit [Client Quit]
sjl has quit [Quit: WeeChat 2.3-dev]
sjl has joined #lisp
<aeth>
I think I know why it's backwards. Symbol plists! (get 'foo 'bar) gets the 'bar associated with the symbol 'foo. (gethash 'foo bar) gets the 'foo associated with the hash-table bar. GET is properly ordered (assuming that you want to match the order of aref, which has to be in the order it is). GETHASH is not.
<aeth>
But apparently, at least according to someone in #scheme who was looking into it, archaic Lisp used GET like a hash table, so (get 'foo 'bar) was used as if it was (get 'key 'table) because there probably wouldn't be too many "tables" for any given key.
<aeth>
If this is right, then (get 'turtle 'animals) could be refactored into (gethash 'turtle *animals*) fairly easily.
robotoad has quit [Read error: Connection reset by peer]
eddof13 has quit [Quit: eddof13]
jmercouris has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
robotoad has joined #lisp
eddof13 has joined #lisp
Lycurgus has quit [Quit: Exeunt]
rk[ghost] has joined #lisp
<aeth>
And it was probably (get 'turtle 'animals) as an optimization. Turtle would probably only have (ANIMALS #<TURTLE-OBJECT>) as its symbol plist but if it was the other way around as (get 'animals 'turtle) then you might have to walk through 100 animals on a computer weaker than today's Raspberry Pi.
Bicyclidine is now known as Bike
shifty has joined #lisp
vutral has quit [Ping timeout: 250 seconds]
<aeth>
So, basically, I now think that GETHASH is in the wrong order because people intentionally used GET in the wrong order so they could get to their turtle faster.
<aeth>
(This also explains why a name as valuable as GET is wasted on a now-niche feature.)
actuallybatman has joined #lisp
frodef has quit [Ping timeout: 252 seconds]
|3b| has quit [Ping timeout: 250 seconds]
vutral has joined #lisp
fikka has joined #lisp
jmercouris has quit [Ping timeout: 240 seconds]
fikka has quit [Ping timeout: 268 seconds]
vtomole has quit [Ping timeout: 256 seconds]
smasta has joined #lisp
on_ion has joined #lisp
oni-on-ion has quit [Ping timeout: 252 seconds]
fikka has joined #lisp
<cgay>
Why is GET a valuable name? What would you use it for?
<Bike>
getting
fikka has quit [Ping timeout: 252 seconds]
smokeink has joined #lisp
varjag has quit [Quit: ERC (IRC client for Emacs 26.1)]
kajo has quit [Ping timeout: 264 seconds]
quazimodo has joined #lisp
kajo has joined #lisp
gral has joined #lisp
gral has left #lisp [#lisp]
fikka has joined #lisp
parjanya has joined #lisp
Lycurgus has joined #lisp
parjanya has quit [Remote host closed the connection]
parjanya has joined #lisp
fikka has quit [Ping timeout: 245 seconds]
malm_ has joined #lisp
ealfonso has joined #lisp
<cgay>
That is important.
<ealfonso>
if I lost a reference to a usocket-server created via (usocket:socket-listen host port), is there a way to forcefully shut it down so I can start listening again on the same port?
jcowan has quit [Quit: Connection closed for inactivity]
<White_Flame>
or, use a heap walker testing for a socket type. But not after a ful GC
anewuser has joined #lisp
<ealfonso>
was trying to look at the source with slime-describe-function but all I get is: Source file: SYS:SRC;PCL;DLISP3.LISP... White_Flame in that case I will probably just try to keep a reference to it in a global var
<ealfonso>
and hope it doesn't get lost or redefined
fikka has quit [Ping timeout: 268 seconds]
robotoad has quit [Quit: robotoad]
<fe[nl]ix>
ealfonso: fix your code
phenoble has joined #lisp
malm_ has quit [Quit: Bye bye]
neirac has quit [Remote host closed the connection]