libera/#commonlisp - IRC Chatlog
Search
16:04:32
jjnkn
hi, i'm trying to understand how MAPCAN works and am slightly confused by differences in experiment results using SBCL and CLISP
16:08:26
jjnkn
as i understand it, the resulting list of MAPCAN will be the first list returned by the mapping function concatenated with the rest of the returned lists
16:09:34
beach
I don't understand that description. Each application of the function should produce a list, and all those lists produced are then combined using NCONC.
16:10:48
jjnkn
correct; combining with NCONC will destructively modify the first list though, right?
16:13:58
beach
And that means that it is undefined behavior if any of the lists given as an argument is in fact not a list.
16:16:26
_death
well, the last argument to nconc may be any object, so (mapcan #'1+ '(42)) => 43 .. but I would say that (mapcan #'1+ '(1 2)) would translate to (nconc 2 3) which has undefined consequences as it violates the nconc Arguments and Values constraints
16:18:08
jjnkn
what's interesting is that according to CLHS (mapcan f x1 ... xn) = (apply #'nconc (mapcar f x1 ... xn))
16:20:45
_death
beach: since the Arguments and Values constraint is violated, the consequences are undefined, and the behavior in Description doesn't matter..
16:22:49
Colleen
The ``arguments and values'' section of a dictionary entry http://www.lispworks.com/reference/HyperSpec/Body/01_ddc.htm
16:23:41
beach
_death: It does not say any like any further description of the operator is then invalid.
16:24:19
beach
jjnkn: People here usually don't recommend CLISP. Do you have any particular reasons to use it?
16:25:52
_death
beach: I'm not sure what you mean by "invalid".. since the behavior isn't explicitly specified, the consequences are undefined, and so the semantics described are irrelevant
16:28:04
jjnkn
beach: i started programming in Common Lisp a few months ago and chose CLISP for no particular reason; it probably appeared most attractive to me because it's part of GNU
16:28:51
jjnkn
but now that I know active development ceased around 2010, i might consider switching to another implementation
16:30:22
_death
jjnkn: active development goes further than 2010.. but they didn't release a new version for some reason
16:32:31
beach
jjnkn: I have a lot of respect for the FSF (I am a member) and the GNU project, but GCL (GNU Common Lisp) and CLISP are not great Common Lisp implementations.
16:34:48
_death
I would say clisp is a nice implementation but I would recommend sbcl because it does more checking and optimization and has frequent releases
16:37:29
enzuru
CLISP is a very common way to get started because it has a fast interpreter and REPL, but yeah, most people move on to SBCL prety soon after
16:38:06
enzuru
what sucks about CLISP is that dev activity continues on the Gitlab repo, but they refuse to make releases. maybe they are salty about being forced to become a GNU project? not sure.
16:38:16
jjnkn
random-nick: from their website: While GCL was originally designed to meet the CLtL1 standard, recent development has brought GCL much of the way toward its current goal -- full ANSI compliance. An ANSI regression test suite is being developed as part of this effort
16:38:24
enzuru
i actually contributed a CI pipeline to CLISP but they seem to basically ignore pull requests
16:43:03
edgar-rft
jjnkn: the original reason for GCL was running the Maxima Computer Algebra System on MS-Windows, but GCL is not considered the most reliable implementation. Some work was going on during the last 10 years to make it more ANSI compatible but no guarantee if really everything from ANSI works correctly.
16:50:21
jjnkn
i will probaby switch to SBCL soon; the only obstacle being the absence of built-in readline facility; what's the recommended way to achieve a nice REPL experience? or do you mostly evaluate code using SLIME or what have you ?
16:58:39
Josh_2
I have to have 2 clack servers, one that is serving my spinneret code, and then to integrate CLOG into it I have to create my own version of /js/boot.js where I manually specify the websocket port to be whatever the port for clog is...
17:07:05
enzuru
random-nick: good call, seems like Stallman brought them into GNU in 92 but their last stable release is 10
17:07:53
enzuru
jjnkn: best REPL experience is going to be SLIME or SLY, SLY is the newer of the two approaches
17:07:54
beach
jjnkn: You really should get something more than just readline. Like I said, most people recommend SLIME or SLY.
17:08:39
enzuru
I also recommend Lispy. It allows modal editing on parens. For instance, I can just hit "e" to eval the s-expression I am on: https://github.com/abo-abo/lispy
17:09:13
edgar-rft
jjnkn: from the shell I use rlwrap(1) like `rlwrap sbcl' but usually I'm using Emacs+Slime+SBCL
17:09:27
enzuru
Lispy is powered under the hood of course by the various Lisp IDEs (SLY/SLIME for Common Lisp, Geiser for Scheme, CIDER for Clojure, etc)
17:12:13
jjnkn
enzuru: i tried evil-mode in the past but I hadn't been programming Lisp then, so maybe will give it another shot
17:13:11
enzuru
also... i hear great things about Spacemacs from Vim converts as well, and it is "batteries included" unlike vanilla Emacs
17:13:53
enzuru
i use vanilla Emacs and do modal editing with Lispy instead of evil-mode, so i can't speak too personally about the vim-like approaches to Emacs
17:14:30
enzuru
Spacemacs comes with a "layer" for Common Lisp dev too: https://github.com/abo-abo/lispy
17:15:07
jjnkn
i find myself quite comfortable with NeoVim as it integrates nicely with Lua, which allows me to use Fennel for writing plugins
17:16:07
enzuru
Neat! Well, not trying to convert you necessarily, just letting you know your options. FYI, once you learn Common Lisp, Emacs Lisp becomes a breeze because it has imported about half the symbols in Common Lisp via the built-in cl-lib library
17:18:20
enzuru
If you like writing extensions in Lisp, and want vim keybindings, Emacs/Spacemacs/etc has top notch support for both. But stick with Neovim and Vlime if that's just the right thing for you.
17:20:40
jjnkn
well, you're slowly converting me to Emacs! i will definitely give evil-mode another shot, and rewriting some of my plugins in Emacs Lisp should be fun
17:22:39
jjnkn
i recall watching some StrangeLoop conference where the speaker was using Emacs for demonstrating code while performing some Emacs wizardry
17:24:39
enzuru
Emacs is quite addictive, because it becomes one of the easiest ways to experience the joy of interactive programming inside a running Lisp image. You evaluate bits of Lisp here and there and see your "editor" transform before your very eyes.
17:26:05
enzuru
StumpWM is also like that, I use that as my window manager on Linux. (Used to actually use Emacs for window management in the form of exwm: https://github.com/ch11ng/exwm )
17:27:45
beach
Emacs might be the best we have for Common Lisp programming (except perhaps what the commercial Common Lisp vendors propose), but it has a lot of shortcomings as well.
17:29:39
beach
Indentation is approximate. Syntax highlighting does not take symbol roles into account. I would like to see many more features that depend on analyses that Emacs can't do, like highlighting all occurrences of a particular lexical variable.
17:31:37
enzuru
i also dislike the default Emacs syntax highlighting. i prefer rainbow-blocks or prism, which highlight Lisp code based on its depth instead (which makes sense for a language with hardly any syntax): https://github.com/alphapapa/prism.el
17:50:45
jjnkn
there is a cool syntax-parsing project called tree-sitter, which has a solid integration with NeoVim
17:51:20
jjnkn
what's cool about it is that it provides syntax highlighting facilities that are based on the underlying language's structure, as opposed to primivite methods like relying on regex patterns
17:53:04
jjnkn
beach: why not? tree-sitter lets you define grammars in JavaScript that compile to parsers in C
17:53:38
beach
jjnkn: But Common Lisp does not have a fixed grammar because of macros and (even "worse") reader macros.
17:56:34
jjnkn
i see; actually, that's what has been irking me when i was creating all these grammar rules
17:57:00
beach
That's why I said: "But you can't really parse Common Lisp with anything other than READ."
17:57:10
jjnkn
for example, i had a rule for highlighting lambda lists, but it was limited only to the forms defined in the standard
17:59:03
jjnkn
btw, there is an integration of tree-sitter for Emacs too: https://emacs-tree-sitter.github.io/
17:59:53
beach
That's a bit different though. It is an example of extensions allowed by the standard. What I am saying is that you can't even parse standard Common Lisp program with a fixed grammar.
18:00:59
jjnkn
of course, i get your point; a real Common Lisp parses would need to have access to the environment of a running program
18:06:38
beach
That part we already do. But now I am working on analyses that require the first pass of a compiler too, like highlighting all occurrences of a particular lexical variable.
18:12:52
beach
Yes, it is public. But it's work in progress: https://github.com/robert-strandh/Second-Climacs
18:14:23
beach
Also, we are extracting lots of stuff to separate repositories, and I haven't really documented where those repositories can be found. It should be obvious after some search.
18:15:16
beach
Like the code corresponding to the paper is here: https://github.com/robert-strandh/Incrementalist