freenode/#lisp - IRC Chatlog
Search
19:48:02
pfdietz
That tweak reduced the run time of that by about 10%. eql hash tables are much faster than equal hash tables, I think because they can cache based on the previous key.
19:51:00
slyrus_
shka_: thanks for the comments on the github issues. I'll check out the rr thing. We need to focus on the developer experience. I'd like to make sure that we have easily understandable examples a la those on the teddy README page.
20:19:19
_death
pfdietz: well, it looks good to me (there's some extra whitespace & commented code though).. I can merge it, but perhaps you should also send a PR to cffi maintainers
20:47:06
benjamindc
Every time I reload a file in the REPL in which I've used defconstant I get the redefinition warning. Is it possible to muffle this warning in my .sbclrc?
20:58:31
shka_
actually alexandria is based on utils described in "on lisp" and the author of the book is a notorious schemer
20:59:19
jackdaniel
define-constant is a very nice lispy name, I don't find it more schemish than lispish
21:00:13
jackdaniel
(define-condition, define-symbol-macro, define-method-combination, define-anything-what-is-not-defsmth-due-to-backward-compatibility)
21:12:11
slyrus_
shka_: refresh my memory about the filter thing. We're talking about the macro I wrote yesterday, right?
21:13:14
shka_
no question, just wanted to suggest that assuming that filter is supposed to be placed inside bind-row would make that macro significantly simpler
21:14:55
slyrus_
bind-row is nice and efficient and all but I think we should provide "wrapper" functions that hide its use for things like filter.
21:17:09
shka_
and perhaps write some macro that works accepts table, bind-row lambda-list and bind-row body as it's own &body
21:18:28
slyrus_
if we take for a moment that we want something dplyr-ish (which is reasonable for my needs), the things I use a lot are the various df/tibble creation routines, select, filter, mutate, rename, inner_join, arrange, pivot_..., etc...
21:18:51
slyrus_
I'd like to see an interface like that exposed to developer/users that would presumably use bind-row under the covers
21:19:19
shka_
since drop-row performs non-local-exit, you can just stick every operations in bind-row
21:19:45
shka_
slyrus_: if one would really want to make it compact, i think that reader macro is the solution
21:21:02
slyrus_
Don't get me wrong, bind-row is cool and there are certainly going to places to use it, but I'd like to see a higher level interface as well.
21:25:33
slyrus_
This is a good question. dplyr has it's approach to this that works reasonably well. The poorly-articulated question that's running around my mind is can we do better in the lisp world given the tools at our disposal?
21:27:00
shka_
but on the other hand, people are used to writing (lambda (something other-thing) ...) so why not imitate lambda?
0:45:28
moon-child
is there a good way to do forward declarations, to keep sbcl from getting uppity with me about co-recursive functions?
0:56:13
Alfr_
moon-child, by any chance you're loading the file directly? Can't it reproduce with (load (compile-file ..)).
0:57:28
Alfr_
moon-child, but you still can wrap these mutually recursive defuns in a (with-compilation-unit () ..) .
2:18:59
pfdietz
Or, you can declaim the later functions to have an ftype. Or, you can make the later functions be generic, and put defgenerics at the top of the file, above the defmethods.
4:38:44
beach
gendl: Starting in 2000, my colleague organized the "Libre Software Meeting" or "Rencontres Mondiales de Logiciel Libre" in Bordeaux. It was a strange "conference" where people did not pay to attend, and some where in fact invited so they had their trip paid for.
4:38:51
beach
I volunteered to chair the track called "Very high-level languages for application development", which I turned into a mostly Common Lisp track. So from the start we had danb, Krystof, gilberth, and many others present.
4:38:55
beach
This meeting was were McCLIM was essentially created. We sketched how special variables were to be implemented in the presence of threads in SBCL. danb did Bordeaux threads and maybe also ASDF then. Over a few years, probably, because we organized the LSM/RMLL for a few years in Bordeaux before it became an even that moved every year.
5:53:53
ck_
I looked it up because I wasn't sure; there are two US islands in UTC-12. And also I did the arithmetic the wrong way, it's six hours from now.
6:01:11
beach
Most islands in that zone made a choice to be among the first to celebrate the new year.
6:19:44
ck_
According to a map, most of them are in +12, or even +13, that's what I meant earlier, was surprised that there even are marked islands in UTC-12. But ok. I guess it's off topic unless they do lisp
6:37:44
thmprover
Say, is there an abstract machine (or virtual machine) that's particularly well suited for Lisp to target?
6:43:39
aeth
You're talking about places where (= 12 (nth 8 (multiple-value-list (get-decoded-time)))) and talking about it like it's -12 while talking about (= -13 (nth 8 (multiple-value-list (get-decoded-time)))) like it's +13
6:46:22
thmprover
Lycurgus: I don't know much about the Lisp Machines, is there some "toy model" describing their architecture?
6:46:40
ck_
aeth: so your point is that I got the lisp terminology wrong with respect to delta to UTC, and 24.1.4.1?
6:47:00
thmprover
moon-child: ah, well, I'm more interested in the theory side, gc and caching are very...applied...
6:47:42
Lycurgus
thmprover, unclear what you mean but wouldn't know. FWIU, the ancient archives have complete sources
6:49:48
thmprover
Lycurgus: I mean, something similar to the SECD machine, in the sense of simple and minimal while demonstrating the key parts of the instruction set for a Lisp Machine. (Or is that just an SECD machine?)
6:52:01
Lycurgus
as an implementor, in practice either you want a real lisp machine to target or you will likely prefer a pragmatic approach to produce good code on
6:54:26
thmprover
I just wasn't sure if there was some "obvious virtual machine" like CAM/FAM/ZINC for ML, but for Lisp.
6:58:23
beach
thmprover: For a theoretical machine to be applicable, you also need a very simple "Lisp" language.
7:00:18
thmprover
Well, I know the SECD machine can be the target for a simple-ish Lisp compiler, which piqued my interest about what needs to be added to handle more complex Lisp constructs.
7:03:18
beach
thmprover: simple compiler, but also a very simple subset of what we think of as "Lisp" today.
7:04:39
thmprover
beach: I should also mention, my curiosity really is strictly academic (for use in a case-study in compiler correctness)
7:06:09
beach
thmprover: But then you are in trouble because 1. There is no widely agreed-upon definition of "Lisp", and 2. The channel topic is Common Lisp.
7:09:00
thmprover
beach: trouble is my business ;) In all seriousness, I've been thinking about how to move from "A simple toy Scheme interpreter" to "A simple toy Common Lisp interpreter", what would need to change.
7:10:38
beach
thmprover: Common Lisp is such a complex language, in particular with lots of imperative constructs, that I am pretty sure that there is no simple abstract machine that will help, unless, of course, you accept that the result will be so slow that it's unusable.
7:14:29
thmprover
beach: like CLISP? Yeah, I have no illusions about performance, my goal is correctness. This is more an experiment with literate programming plus formal proofs, than a fancy new tool for production.
7:20:25
thmprover
beach: true, but that may be too simple. I'm looking for a happy medium between the extremely simple pure lambda calculus VM, and the complicated real world.
7:20:59
beach
That's a very tough thing to help you with, because it is not obvious what is too simple and what is too complicated for you.