libera/#commonlisp - IRC Chatlog
Search
4:40:34
etimmons
So I've always assumed that it's called "burgled batteries" since, as a Python/CL bridge, it's stealing Python's batteries
4:41:37
jmercouris
I kind of want to make my own lisp which is a superset of Common Lisp by including some of my favorite CL libraries
4:42:09
jmercouris
I wouldnāt make a new compiler or anything, just ship an image with some libraries added
4:43:54
hayley
Because another language breaks compatibility with everything, whereas just having "CL with some nice libraries" doesn't.
4:44:28
hayley
Yeah. Good chance that (defpackage :blah (:use :cl)) is going to do something very bad.
7:18:55
jackdaniel
yesterday I wrote a short post about the macro do and tail recursion https://turtleware.eu/posts/How-do-you-DO-when-you-do-DO.html
7:19:07
jackdaniel
that was prompted by the yesterday discussion about do (however only remotely relevant to it)
7:33:21
jackdaniel
I don't have any strong preference - if something can be expressed clearly in terms of do then it is fine
7:33:41
xaotuk
jackdaniel: Wow! I always observed "do" as some ancient iteration construct, never being aware that it's compact tail recursion. You opened my eyes, thanks!
8:49:37
Colleen
borodust: drmeister said at 2021.10.11 20:25:12: Thanks - I wasn't sure if I was just not thinking about it properly
11:08:13
skeemer
hello all, i am quite new to common lisp, i was wondering why most of the people uses sbcl, and what are the reasons to prefer it to clisp ?
11:09:18
hayley
SBCL compiles to machine code, so it is (almost?) always faster, and it is more maintained.
12:38:09
icer
My working remote slime/swank debugging broke after trying to update sbcl to the downloaded latest from Ubuntu 20.04's default. I've tried reverting, recompiling, but now it's always complaining about swank-io-package stuff missing and swank indentation things missing. Any ideas?
12:45:55
beach
icer: You can use completion to get the full IRC handle of the person you are addressing.
12:51:34
icer
jackdaniel: Ok, I can connect to the binary running on my local machine, but to the same binary over ssh port forwarding, the same errors occur.
12:55:50
icer
jackdaniel: I md5summed the binary to confirm its the same. There is no ~/.slime on the remote system.
13:01:17
_death
jackdaniel: when I think of DO, I tend to recall the little box on PG's ANSI Common Lisp, I think with the headline "The point of DO".. in it he quotes from the paper "The Evolution of Lisp"
13:03:26
icer
I still connect and get the "Can't locate module: SWANK-IO-PACKAGE::SWANK-INDENTATION", which is odd considering it's the same binary.
13:03:56
_death
the quotation is about how iteration over a single variable is often not very useful on its own, and how DO allows iterating multiple variables, and consequently the DO body can often be empty
13:07:40
_death
icer: a while ago I added a restart to be able to continue from this error, btw.. https://github.com/death/slime/commit/9f5cc8c7cf042f821ee3f2c838c6b617e8aeaf6d
13:09:53
icer
_death: nice retart idea. So, are fasls not built into the image? My Makefile uses (asdf:make). Or is swank something I need to manually quickload on the remote?
13:14:56
icer
_death: I don't do an explicit load, just a ql:quickload of the project's asd system, then build, which shouldn't call the entrypoint. At one point I tried adding --eval '(swank-loader:init)' before the build command.
13:33:57
icer
_death: It takes a couple minute to deploy - slow connection. In the meantime I tried sshing in to the remote and trying to emacs/slime locally on the remote and got a swank version mismatch 24 vs 26.1, which apt tells me 24 is on the remote, and I know 26.1 is local to my dev machine. May be the issue.
13:43:36
icer
_death: how do I make slime recompile after I patch the file for your restart? I did a slime C-c C-c, and compiled, but that didn't seem to be enough.
13:46:46
icer
_death: odd, the swank-loader line doesn't seem to have an effect, the remote is still looking for the v24 swank rather than what I tried to build into the image.
13:53:38
icer
_death: yes, I forgot to "purge" it, I'll see if that works. I've also quickloaded swank, but that didn't work.
14:17:44
icer
_death: so.. same as dev machine, used quicklisp to install swank and melpa in emacs to install slime on remote. Tried using emacs/slime on remote for a remote-local connection, and it fails, same failure to load swank-indentation :(
14:29:27
_death
icer: in fact I do this for all lisp-related things.. I have a "third-party" directory of CL code repos (it's a subdirectory of quicklisp, ~/quicklisp/third-party due to historical reasons, as I started by converting all QL libraries I had.. https://gist.github.com/death/2fb6218858c6212ebea052f2e3d4f0b3 )
14:31:38
_death
icer: well, it's just the way I work.. maybe others can help you do it in a way that is more practical for you
14:36:46
_death
to pick up new changes, I have a basic program that fetches for each repo, and I can then review the changes and merge/rebase
14:42:09
_death
I do use melpa for emacs packages (not slime), but also keep them in a big git repo, so that I can review changes, revert, etc.
15:21:10
gin
if I just need to do a boolean check for whether an item exists in list, is either of FIND or POSITION more preferred than the other?
15:57:48
beach
There is an irritating contradiction of terminology in the Common Lisp standard that would be good to fix some day. Usually "bound" means "has a value", so that BOUNDP returns true if and only if the variable has a value and MAKUNBOUND makes the variable have no value. But that terminology is not great, as is evident in the dictionary entry on PROGV.
15:59:17
beach
So it is possible to have a binding for a special variable, but it has no value in that binding.
16:00:49
beach
1. Let "bound" mean that a binding exists, but it can have no value. That solution would require renaming BOUNDP and MAKUNBOUND which makes this solution hard.
16:01:50
beach
2. Keep "bound" to mean "has a value", but introduce a new term for what we now call a "binding".
16:08:39
beach
The glossary does not mention "having a value" in association with "bind", "bound", "binding", so that suggests solution 1.
16:08:59
Nilby
How about accepting that natural language is imprecise and adding a denotational semantics definition like scheme?
16:11:27
Nilby
beach: I know. It makes my head swim to to think of it for all of CL. Even the scheme version is challenging.
16:11:37
beach
MichaelRaskin: There is no glossary entry for "bindings". Do you mean for "binding"? For lexical variables, they are the same.
16:11:45
MichaelRaskin
I have an impression that mentioning the remaining variables being bound (which is against the glossary definition, which asks these names to denote something, which they don't withing dynamic extent) is just so that Ā«bindings are undoneĀ» covers them
16:12:24
MichaelRaskin
beach: I mean entry for Ā«bindingĀ» that gives examples of different kinds of bindings
16:13:49
MichaelRaskin
The spec for progv says Ā«The bindings of the dynamic variables are undone on exit from progv.Ā»
16:13:59
Nilby
Also it's not clear how useful denotational semantics is to anybody, since I and many others wrote a scheme without looking too much at it.
16:14:55
MichaelRaskin
This seems to cover the variables that are deprived of their values for the dynamic extent of progv
16:16:01
MichaelRaskin
I am not yet suggesting, I am trying to understand why the phrase Ā«bound and then made to have no valueĀ» was written
16:16:21
Nilby
I agree there's more to it than just being bound and unbound which it would be nice to have a precise term for.
16:17:22
beach
If it has no value, then makunbound did not undo the binding introduced by the inner LET.
16:18:57
beach
_death: Exactly, so the PROGV page says *x* is still bound, but BOUNDP returns false.
16:19:56
MichaelRaskin
Technically speaking. doesn't Ā«then made to have no valueĀ» have power to also make the variable unbound there?
16:20:00
beach
_death: If that is what you think, you have to invent a new term for what (let ((*x* 234)) does