<beach>
Hmm, maybe not. But, the function must produce a list.
<beach>
1+ does not produce a list
<jjnkn>
by literal data you mean the quoted list?
<beach>
Yes, but I think I jumped to conclusions.
<jjnkn>
because CLISP still gives 4 if given (list 1 2 3)
<beach>
That's not the problem.
<jjnkn>
according to CLHS, this usage of MAPCAN is indeed illegal
xaltsc has quit [Ping timeout: 245 seconds]
tyson2 has quit [Remote host closed the connection]
<beach>
So that means CLISP is not doing the right thing.
<beach>
The question is whether that is allowed.
<beach>
Let me consult the standard.
pfdietz has quit [Quit: Client closed]
<beach>
I think it is allowed, but not very nice.
<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
<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.
<jjnkn>
correct; combining with NCONC will destructively modify the first list though, right?
<beach>
It will destructively modify every list except the last one.
<jjnkn>
oh, you're right
<jjnkn>
glad I asked then, because I would've missed that
<beach>
It is unclear to me whether the behavior of CLISP is conforming.
<beach>
On the one hand, the dictionary entry on NCONC says "Exceptional Situations: None."
<beach>
And that means that it is undefined behavior if any of the lists given as an argument is in fact not a list.
<beach>
On the other hand, it defines NCONC in terms of RPLACD.
dino_tutter has quit [Ping timeout: 240 seconds]
<beach>
And RPLACD is required to signal an error in safe code.
iska has quit [Ping timeout: 264 seconds]
<beach>
But if your code is not safe, then it is not required to signal an error.
<_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
<beach>
_death: Yes, except that NCONC is defined in terms of RPLACD.
<jjnkn>
what's interesting is that according to CLHS (mapcan f x1 ... xn) = (apply #'nconc (mapcar f x1 ... xn))
<Josh_2>
Wish it was easier to integrate CLOG into an existing Spinneret based project :sob:
<jjnkn>
but (apply #'nconc (mapcar #'1+ '(1 2 3))) produces an error: NCONC: 3 is not a list
<jjnkn>
in CLISP
<_death>
beach: not sure why that matters?
semz has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
<beach>
_death: Because RPLACA is required to signal an error in safe code.
<beach>
Er, RPLACD.
<beach>
jjnkn: It is either a bug in CLISP, or at the very least, not nice behavior.
<_death>
beach: since the Arguments and Values constraint is violated, the consequences are undefined, and the behavior in Description doesn't matter..
<beach>
_death: What makes you conclude that? Is that a general rule in the standard?
<beach>
_death: It does not say any like any further description of the operator is then invalid.
semz has joined #commonlisp
<beach>
jjnkn: People here usually don't recommend CLISP. Do you have any particular reasons to use it?
<_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
<beach>
I see no mention that semantics describe are irrelevant.
<_death>
beach: how could they be relevant then?
<beach>
Forget about it.
<beach>
I don't feel like arguing.
<beach>
I am sure you are right.
<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
<beach>
jjnkn: I recommend you switch to something that is better maintained.
<jjnkn>
but now that I know active development ceased around 2010, i might consider switching to another implementation
<b00p>
But no other CL implementation has a better Menorah, we can all agree
<beach>
jjnkn: Most people here would recommend SBCL with either SLIME or SLY.
<jjnkn>
i didn't know this thing was called Menorah
<_death>
jjnkn: active development goes further than 2010.. but they didn't release a new version for some reason
<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.
<beach>
jjnkn: Perhaps because Stallman never really liked Common Lisp.
mgl has quit [Quit: Client closed]
<jjnkn>
haven't heard about GCL, thought CLISP was the only implementation from GNU
<jjnkn>
and latest GCL release is dated 2023-01-13
<jjnkn>
however, there was an 8 year gap between 2014 and 2022 in releases
<_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
<random-nick>
is GCL still pre-ansi?
<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
<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.
<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
<enzuru>
i actually contributed a CI pipeline to CLISP but they seem to basically ignore pull requests
<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.
<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 ?
<Josh_2>
Pita to get CLOG to integrate into my spinneret project
<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...
<random-nick>
enzuru: hasn't CLISP been a GNU project for a long time?
<Josh_2>
I think this means my system will need 3 different HTTP servers :skull:
<enzuru>
random-nick: good call, seems like Stallman brought them into GNU in 92 but their last stable release is 10
<enzuru>
jjnkn: best REPL experience is going to be SLIME or SLY, SLY is the newer of the two approaches
<beach>
jjnkn: You really should get something more than just readline. Like I said, most people recommend SLIME or SLY.
<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
<ixelp>
GitHub - abo-abo/lispy: Short and sweet LISP editing
<edgar-rft>
jjnkn: from the shell I use rlwrap(1) like `rlwrap sbcl' but usually I'm using Emacs+Slime+SBCL
<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)
<jjnkn>
i'm quite invested into Vim, so I'll first try some Vim alternatives to SLIME/SLY
pfdietz has joined #commonlisp
<enzuru>
I hear good things about Vlime
<enzuru>
(i hear better things about evil-mode ;) )
<jjnkn>
edgar-rft: rlwrap(1) is great, i was considering using it if nothing else
<jjnkn>
enzuru: i tried evil-mode in the past but I hadn't been programming Lisp then, so maybe will give it another shot
<enzuru>
also... i hear great things about Spacemacs from Vim converts as well, and it is "batteries included" unlike vanilla Emacs
<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
<jjnkn>
i find myself quite comfortable with NeoVim as it integrates nicely with Lua, which allows me to use Fennel for writing plugins
<jjnkn>
if you're not familiar, Fennel is a Lisp that compiles to Lua
<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
<enzuru>
And of course they are both Lisp-2, have similiar macro systems, etc
b00p has joined #commonlisp
<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.
<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
rendar has quit [Quit: Leaving]
<jjnkn>
i recall watching some StrangeLoop conference where the speaker was using Emacs for demonstrating code while performing some Emacs wizardry
<jjnkn>
Programming Should Eat Itself by Nada Amin
<jjnkn>
talks about the concept of towers of interpreters in Scheme
<jjnkn>
the contents of the talk could also be described as wizardry
<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.
rendar has joined #commonlisp
rendar has quit [Changing host]
rendar has joined #commonlisp
mrcom has quit [Read error: Connection reset by peer]
<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 )
<ixelp>
GitHub - ch11ng/exwm: Emacs X Window Manager
mrcom has joined #commonlisp
<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.
<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.
cosimone has joined #commonlisp
<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
<ixelp>
GitHub - alphapapa/prism.el: Disperse Lisp forms (and other languages) into a spectrum of colors by depth
<beach>
I would prefer to highlight lexical variables differently from function names.
<enzuru>
that would be an interesting plugin actually
<beach>
It would require an entirely new set of analyses.
waleee has joined #commonlisp
overclucker has quit [Ping timeout: 264 seconds]
<jjnkn>
there is a cool syntax-parsing project called tree-sitter, which has a solid integration with NeoVim
<beach>
But you can't really parse Common Lisp with anything other than READ.
<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
overclucker has joined #commonlisp
<jjnkn>
beach: why not? tree-sitter lets you define grammars in JavaScript that compile to parsers in C
<beach>
jjnkn: But Common Lisp does not have a fixed grammar because of macros and (even "worse") reader macros.
<jjnkn>
i see; actually, that's what has been irking me when i was creating all these grammar rules
<beach>
That's why I said: "But you can't really parse Common Lisp with anything other than READ."
<jjnkn>
for example, i had a rule for highlighting lambda lists, but it was limited only to the forms defined in the standard
<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.
<jjnkn>
of course, i get your point; a real Common Lisp parses would need to have access to the environment of a running program
<jjnkn>
i wonder if there has been any research or attempts at implementing of such parsers
<beach>
Yes, we are working on it.
<beach>
We wrote an ELS paper about incremental parsing using READ a few years back.
<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.
waleee has quit [Ping timeout: 240 seconds]
random-nick has quit [Ping timeout: 240 seconds]
chomwitt has quit [Ping timeout: 240 seconds]
<jjnkn>
interesting stuff, is it possible to access the code?
<ixelp>
GitHub - robert-strandh/Second-Climacs: Version 2 of the Climacs text editor.
<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.