phoe changed the topic of #commonlisp to: Common Lisp, the #1=(programmable . #1#) programming language | Wiki: <https://www.cliki.net> | IRC Logs: <https://irclog.tymoon.eu/libera/%23commonlisp> | Cookbook: <https://lispcookbook.github.io/cl-cookbook> | Pastebin: <https://plaster.tymoon.eu/>
dra_ has joined #commonlisp
dra has quit [Ping timeout: 240 seconds]
dra_ has quit [Quit: Leaving]
dra has joined #commonlisp
occ has joined #commonlisp
masinter has quit [Ping timeout: 240 seconds]
karmichammer has joined #commonlisp
karmichammer has quit [Ping timeout: 240 seconds]
dra has quit [Remote host closed the connection]
molson has joined #commonlisp
akoana has quit [Quit: leaving]
ec has joined #commonlisp
morganw has quit [Remote host closed the connection]
pranavats has left #commonlisp [Error from remote client]
tyson2 has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
mon_aaraj has quit [Ping timeout: 240 seconds]
mon_aaraj has joined #commonlisp
ec has quit [Ping timeout: 276 seconds]
Colleen has quit [Quit: Colleen]
Colleen has joined #commonlisp
ec has joined #commonlisp
random-nick has quit [Ping timeout: 240 seconds]
jealousmonk has joined #commonlisp
lispy has quit [Quit: Leaving]
pjb has quit [Ping timeout: 268 seconds]
Jing has joined #commonlisp
ec has quit [Ping timeout: 276 seconds]
ec has joined #commonlisp
jealousmonk has quit [Remote host closed the connection]
wheelsucker has quit [Remote host closed the connection]
wheelsucker has joined #commonlisp
occ has quit [Ping timeout: 256 seconds]
dre has quit [Quit: Leaving]
ec has quit [Ping timeout: 276 seconds]
waleee has quit [Ping timeout: 240 seconds]
lisp123 has joined #commonlisp
<beach> Good morning everyone!
dre has joined #commonlisp
masinter has joined #commonlisp
<lisp123> Good Morning Beach!
pranavats has joined #commonlisp
Guest9625 has joined #commonlisp
karmichammer has joined #commonlisp
Guest9625 has quit [Client Quit]
karmichammer has quit [Ping timeout: 256 seconds]
[w] has joined #commonlisp
s-liao has joined #commonlisp
occ has joined #commonlisp
euandreh has quit [Ping timeout: 250 seconds]
scymtym has quit [Remote host closed the connection]
scymtym has joined #commonlisp
semz_ has joined #commonlisp
semz has quit [Ping timeout: 250 seconds]
lisp123 has quit [Remote host closed the connection]
s-liao has quit [Ping timeout: 256 seconds]
lisp123 has joined #commonlisp
aartaka has joined #commonlisp
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
lisp123 has quit [Ping timeout: 256 seconds]
opcode has quit [Ping timeout: 250 seconds]
mon_aaraj has quit [Ping timeout: 240 seconds]
mon_aaraj has joined #commonlisp
<lisp123w> pjb: Thanks for that. Definitely need to get into using APROPOS more
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
Bike has quit [Quit: Connection closed]
elderK has joined #commonlisp
spiaggia has joined #commonlisp
masinter has quit [Ping timeout: 250 seconds]
White_Flame has quit [Ping timeout: 240 seconds]
opcode has joined #commonlisp
Cymew has joined #commonlisp
White_Flame has joined #commonlisp
attila_lendvai has joined #commonlisp
Algernon69 has joined #commonlisp
parjanya has quit [Ping timeout: 268 seconds]
shka has joined #commonlisp
mon_aaraj has quit [Read error: Connection reset by peer]
pranavats has left #commonlisp [Error from remote client]
mon_aaraj has joined #commonlisp
spiaggia has quit [Quit: ERC (IRC client for Emacs 26.3)]
s-liao has joined #commonlisp
pranavats has joined #commonlisp
lisp123w has left #commonlisp [ERC (IRC client for Emacs 26.3)]
<ns12> Why do Common Lispers tend to (:use :alexandria) instead of using package local nicknames or using the full form (e.g. #'alexandria:extremum)?
<ns12> Is there a good reason, or is it just laziness on the part of the programmer?
<White_Flame> alexandria predated PLNs
<White_Flame> and the symbol names are pretty importable and very commonly used
<White_Flame> however, a:foo is a newer common PLN
<ns12> Before the existence of PLN, why didn't CL programmers use the full name of Alexandria symbols (e.g. #'alexandria:extremum)?
<White_Flame> the symbol names are pretty importable and very commonly used ;)
<ns12> White_Flame: "a:foo is a newer common PLN" - Is this the recommended style nowadays?
<White_Flame> it's effectively treated as an extension to the standard CL functions
karmichammer has joined #commonlisp
<White_Flame> do what you want, that seems sensible :)
<ns12> "the symbol names are pretty importable and very commonly used" - Oh. Sorry. It didn't click for me. What do you mean by symbol names being "importable"?
<White_Flame> it is recommended style to use PLNs for ease of use nowadays. the actual abbreviation is up to you
<White_Flame> they don't conflict, as they're named pretty globally appropriately to what they do
<White_Flame> and if you have your own personal suite of library functions that do conflict with alexandria, it's recommended to use alexandria instead and standardize your code
<ns12> "it's effectively treated as an extension to the standard CL functions" - I guess this is the answer.
<ns12> s/answer/answer to my main question/
<White_Flame> yep, but I do predict that a: will become more used as people port things to and write new things with PLNs
karmichammer has quit [Ping timeout: 240 seconds]
<ns12> Suppose I am using library X, which USEs function F from Alexandria. If I USE Alexandria in my main program and accidentally define my own function having the same name as function F from Alexandria, will there be disaster?
pjb has joined #commonlisp
<White_Flame> your (defun f () ..) will read as (cl:defun alexandria:f () ...), and your defniition will overwrite it (unless you reload alexandria later)
<White_Flame> your lisp might very well warn you
<White_Flame> ( SBCL generally does, if there's a double defun somewhere)
<ns12> "your (defun f () ..) will read as (cl:defun alexandria:f () ...)" - Why does this happen? When I USE a package, its symbols are merged into the current package's symbol table?
<White_Flame> yes
<White_Flame> your package will map "F" to the symbol ALEXANDRIA:F
<White_Flame> that's what an import is
<White_Flame> just like "+" maps to CL:+ in your package
<White_Flame> CL isn't special at all in that regard
<ns12> Oh, but what happens when I USE two packages that define the symbol?
<ns12> s/the symbol/the same symbol/
<moon-child> kaboom :)
<Krystof> well, using two package that export the *same* symbol is fine
<Krystof> using two packages that export different symbols with the same name leads to conflict
<moon-child> (this is one reason why it is no longer considered good practice to use packages, and use of PLNs is encouraged)
<ns12> Understood. Thanks.
<ns12> "your (defun f () ..) will read as (cl:defun alexandria:f () ...)" - Is there a way to display this interactively? As in "(defun f () ..)" -> "(cl:defun alexandria:f () ...)"
<beach> ns12: You can do (symbol-package 'f)
<Krystof> (let ((form (read-from-string "(defun f () ...)")) (*package* (find-package "KEYWORD"))) (prin1 form))
<beach> Or you can bind *package* to the keyword package.
<beach> Right.
<moon-child> Krystof: why not just: (let ((form '(defun f () ... ))) ... )?
<ns12> Wonderful. Thank you White_Flame, moon-child, Krystof, and beach.
<White_Flame> np
<ns12> Why set *package* to "KEYWORD" instead of "CL"?
<beach> Because you wanted the cl: prefix.
<pjb> while printing.
<beach> You won't get that if *PACKAGE* is the CL package.
<pjb> (let ((form (read-from-string "(defun foo (x) (if (minusp x) (- x) x))"))) (let ((*package* (find-package "KEYWORD"))) (print form))) #|
<pjb> (common-lisp:defun common-lisp-user::foo (common-lisp-user::x) (common-lisp:if (common-lisp:minusp common-lisp-user::x) (common-lisp-user::- common-lisp-user::x) common-lisp-user::x)) --> (defun foo (x) (if (minusp x) (- x) x)) |#
<pjb> (let ((form (read-from-string "(foo if :keyword)"))) (let ((*package* (find-package "KEYWORD"))) (print form))) #|
<pjb> (common-lisp-user::foo common-lisp:if :keyword) --> (foo if :keyword) |#
wheelsucker has quit [Remote host closed the connection]
<pjb> you don't get a keyword: prefix, but keywords are still printed as :keyword so it's clear.
wheelsucker has joined #commonlisp
pve has joined #commonlisp
elderK has quit [Quit: Connection closed for inactivity]
<ns12> I see, out of the three standardized packages, only the keyword package is suitable causing the printing of prefixes. http://www.lispworks.com/documentation/lw50/CLHS/Body/11_ab.htm
<ns12> s/prefixes/common-lisp: and common-lisp-user: prefixes/
mon_aaraj has quit [Ping timeout: 240 seconds]
mon_aaraj has joined #commonlisp
mgl has joined #commonlisp
frgo has quit []
xaltsc has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
occ has quit [Read error: Connection reset by peer]
Jing has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
Cymew has quit [Ping timeout: 250 seconds]
MajorBiscuit has joined #commonlisp
Jing has joined #commonlisp
semz_ is now known as semz
Cymew has joined #commonlisp
cosimone has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 240 seconds]
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
Lord_of_Life has joined #commonlisp
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
random-nick has joined #commonlisp
[w] has quit [Quit: nyaa~]
vats has joined #commonlisp
Algernon69 has quit [Ping timeout: 268 seconds]
santiagopim has joined #commonlisp
perrierjouet has quit [Quit: WeeChat 3.4]
rain3 has joined #commonlisp
Lord_Nightmare2 has joined #commonlisp
Lord_Nightmare has quit [Read error: Connection reset by peer]
rogersm has joined #commonlisp
Lord_Nightmare2 is now known as Lord_Nightmare
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
karmichammer has joined #commonlisp
Cymew has quit [Ping timeout: 250 seconds]
attila_lendvai has quit [Read error: Connection reset by peer]
karmichammer has quit [Ping timeout: 240 seconds]
attila_lendvai has joined #commonlisp
mon_aaraj has quit [Ping timeout: 240 seconds]
vats has quit [Ping timeout: 240 seconds]
wheelsucker has quit [Remote host closed the connection]
wheelsucker has joined #commonlisp
morganw has joined #commonlisp
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
perrierjouet has joined #commonlisp
Jing has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tyson2 has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
pranavats has joined #commonlisp
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
mon_aaraj has joined #commonlisp
occ has joined #commonlisp
Algernon69 has joined #commonlisp
mon_aaraj has quit [Ping timeout: 250 seconds]
mon_aaraj has joined #commonlisp
wyrd has quit [Ping timeout: 276 seconds]
wyrd has joined #commonlisp
wheelsucker has quit [Read error: Connection reset by peer]
wheelsucker has joined #commonlisp
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
scymtym has quit [Remote host closed the connection]
attila_lendvai has quit [Read error: Connection reset by peer]
scymtym has joined #commonlisp
attila_lendvai has joined #commonlisp
mon_aaraj has quit [Ping timeout: 250 seconds]
mon_aaraj has joined #commonlisp
|smlckz| has quit [Ping timeout: 250 seconds]
|smlckz| has joined #commonlisp
mon_aaraj has quit [Ping timeout: 256 seconds]
euandreh has joined #commonlisp
mon_aaraj has joined #commonlisp
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
aartaka has quit [Ping timeout: 240 seconds]
aartaka has joined #commonlisp
IPmonger has joined #commonlisp
occ has quit [Remote host closed the connection]
occ has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
wmblathers has quit [Quit: Leaving...]
Cymew has joined #commonlisp
Bike has joined #commonlisp
<phoe> Which part of the specification mentions that (MULTIPLE-VALUE-CALL (LAMBDA (ONE TWO) (LIST ONE TWO)) (VALUES 1 2 3)) should be an error?
<phoe> clhs multiple-value-call
Jing has joined #commonlisp
<phoe> clhs program-error
djuber has joined #commonlisp
<beach> You are passing three values to a function that takes two, no?
<phoe> yes
<beach> er, three arguments.
<phoe> clhs 3.5.1.3
<phoe> found it
<Alfr> phoe, maybe 3.5.1.3? Note that your lambda takes exactly three arguments.
<phoe> Alfr: yes, thank you
<Alfr> *two
* phoe nods, files a bugticket
waleee has joined #commonlisp
<ns12> Is it valid to add a particular keyword to *features* more than once? e.g. (push :foo *features*) (push :foo *features*)
<ns12> Or is it better to use PUSHNEW instead of PUSH in this case?
karmichammer has joined #commonlisp
<Bike> i don't think there is any restriction, but you might as well use pushnew.
<Bike> less confusing.
<ns12> Is it conventional to prefix custom feature symbols with the name of the library that adds the feature symbol to *features*?
waleee has quit [Ping timeout: 240 seconds]
ec has joined #commonlisp
s-liao has quit [Quit: Client closed]
_73 has joined #commonlisp
<_73> Is it possible to handle a condition that is internal to another package?
<beach> Conditions are neither internal nor external to packages.
<beach> Only symbols are.
<beach> So if you use the correct symbol for its name, there is no problem.
<_73> The symbol that denotes the condition type is internal, so I get an undefined symbol error.
<beach> Symbols can not be undefined. If the symbol is internal, you need to use a double package marker to refer to it. That's not great with respect to modularity, but that's what you need to do.
<pjb> You don't even have to use the right symbol in the handling form, if you know a superclass of those conditions that is named in another package!
<pjb> (define-condition foo::condi () ()) (define-condition bar::error (foo::condi) ()) (handler-case (will-signal-bar-error) (foo::condi (err) (handle-bar-error-here err)))
<_death> you can also consider whether the name should actually be external and if so export it and possibly submit a patch
<_73> pjb: ohh I see, that should work for me.
Cymew has quit [Ping timeout: 250 seconds]
<phoe> _73: which package/condition is that? what are the supertypes of that condition?
<phoe> maybe the condition itself is something like si::simple-reader-error and you are actually supposed to handle cl:reader-error instead
<phoe> or maybe somebody forgot to export the condition name/accessors if it's some publicly available library, which would warrant a bugticket
<_73> the condition is LEX-ERROR with supertype error: https://github.com/massung/lexer
rogersm has quit [Ping timeout: 250 seconds]
<phoe> yep, time to file a bugticket - maybe even a PR.
santiagopim has quit [Ping timeout: 256 seconds]
<phoe> in particular, package LEXER should export lex-error along with lex-error-{reason,line,source}
<_73> ok Ill work on this
<phoe> for whatever reason people tend to forget that conditions and their accessors are also a part of a library's API
* phoe is one of those people
wmblathers has joined #commonlisp
IPmonger has joined #commonlisp
mon_aaraj has quit [Ping timeout: 268 seconds]
mon_aaraj has joined #commonlisp
karmichammer has quit [Quit: leaving]
ec has quit [Ping timeout: 276 seconds]
lispy has joined #commonlisp
ec has joined #commonlisp
karmichammer has joined #commonlisp
lisp123 has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
lisp123 has quit [Ping timeout: 250 seconds]
alvaro121 has joined #commonlisp
alvaro121_ has quit [Ping timeout: 250 seconds]
karmichammer has quit [Ping timeout: 256 seconds]
karmichammer has joined #commonlisp
karmichammer has quit [Ping timeout: 256 seconds]
Catie has joined #commonlisp
wheelsucker has quit [Read error: Connection reset by peer]
wheelsucker has joined #commonlisp
huckleberry has joined #commonlisp
lispy has quit [Quit: Leaving]
<huckleberry> Are bit-vectors and bit-xxx ops worth using over their logxxx counterparts if I'm planning to convert the result into an integer? I've got an algorithm I can make far simpler with a vector but it's invoked so often I have efficiency concerns
alvaro121_ has joined #commonlisp
alvaro121 has quit [Ping timeout: 240 seconds]
lispy has joined #commonlisp
<phoe> not really, I guess
<phoe> the bit-smasher library might be useful but I have no idea about efficiency
<phoe> unless your bit fields are going to be longer than a machine word, at which point it might be useful to have these rather than bignums
karmichammer has joined #commonlisp
iamFIREc1 has joined #commonlisp
iamFIREcracker has quit [Ping timeout: 240 seconds]
karmichammer has quit [Ping timeout: 256 seconds]
aartaka has quit [Ping timeout: 256 seconds]
cosimone has quit [Remote host closed the connection]
cosimone has joined #commonlisp
lisp123 has joined #commonlisp
AeroNotix has joined #commonlisp
gjvc has joined #commonlisp
lisp123 has quit [Client Quit]
masinter has joined #commonlisp
djuber has quit [Remote host closed the connection]
cosimone has quit [Remote host closed the connection]
<huckleberry> phoenominal, thanks
<phoe> xD
MajorBiscuit has quit [Ping timeout: 240 seconds]
<Xach> huckleberry: bit-* can take a target result vector so it needn't cons
<Xach> i used that for a little search engine
rain3 has quit [Ping timeout: 268 seconds]
mon_aaraj has quit [Ping timeout: 240 seconds]
cage has joined #commonlisp
<huckleberry> xach: a bloom filter?
Jing has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
huckleberry has quit [Quit: disconnected]
pillton has quit [Ping timeout: 260 seconds]
Algernon91 has joined #commonlisp
<Xach> it was a straight bitmap
Algernon69 has quit [Ping timeout: 268 seconds]
mon_aaraj has joined #commonlisp
<_death> but such a representation would only work for a small corpus
<Xach> yep! fortunately that's exactly what i have, around 5k usenet articles.
<_death> and thanks for that :)
ec has quit [Quit: ec]
gamaliel has joined #commonlisp
<gamaliel> Hi, common lisp newbie here. Is it possible to do (ql:uninstall) on a system plus its dependencies? I'm kind of confused by the information I've been looking online.
<Xach> gamaliel: not really. what prompts the desire?
<gamaliel> @Xach: I was testing out a system that turned out not to be the one I needed. So I want to purge the system from it, plus any systems it may have installed.
<Xach> gamaliel: why?
<Xach> (I can think of reasons but curious about yours)
<gamaliel> Don't want it, I guess.
<Xach> gamaliel: there isn't a short way to do it, sorry. possibly the easiest thing is to delete the "installed", "software", and "archives" directories in ~/quicklisp/dists/quicklisp/ - this will clear out everything.
<Xach> you also don't have to delete it - it doesn't do anything (except take up some space)
<White_Flame> I presume QL doesn't track which systems have been explicitly vs dependently downloaded
<Xach> White_Flame: no.
<Xach> it doesn't
<White_Flame> which would be required for such a feature
<_death> a cheap way that still offloads some management to the user could be to have a quicklisp.log that contains "installed foo" entries
ec has joined #commonlisp
<gamaliel> I think I found something that could help: ql-dist:dependency-tree. I checked on it and it seems to provide *all* dependencies. I guess it's a matter of choosing the ones to uninstall.
<gamaliel> Not sure about the *all* though
<White_Flame> and if you uninstall too much, your normal QL dependencies should reload what's needed anyway
<White_Flame> should download the exact same version as you had before, unless you upgraded the dist
<gamaliel> Tried it, and it seems to work.
<gamaliel> (mapc #'ql:uninstall '(foo bar baz))
<gamaliel> Thank you all for the answers.
nij- has joined #commonlisp
Dynom has joined #commonlisp
Algernon91 has quit [Read error: Connection reset by peer]
Algernon91 has joined #commonlisp
artchad has joined #commonlisp
waleee has joined #commonlisp
karmichammer has joined #commonlisp
ec has quit [Ping timeout: 276 seconds]
ec has joined #commonlisp
myrrh has joined #commonlisp
shozo has joined #commonlisp
Bike has quit [Quit: Connection closed]
karmichammer has quit [Ping timeout: 250 seconds]
mon_aaraj has quit [Ping timeout: 268 seconds]
mon_aaraj has joined #commonlisp
vats has joined #commonlisp
Algernon91 has quit [Ping timeout: 268 seconds]
dilated_dinosaur has quit [Ping timeout: 250 seconds]
dilated_dinosaur has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 27.1]
varjag has joined #commonlisp
mon_aaraj has quit [Ping timeout: 256 seconds]
wmblathe_ has joined #commonlisp
karmichammer has joined #commonlisp
mon_aaraj has joined #commonlisp
wmblathe_ is now known as wmblathers_
wmblathers_ has quit [Client Quit]
Dynom has quit [Ping timeout: 256 seconds]
wmblathers has quit [Ping timeout: 256 seconds]
Dynom has joined #commonlisp
karmichammer has quit [Ping timeout: 256 seconds]
Inline has quit [Ping timeout: 268 seconds]
shozo has quit [Ping timeout: 250 seconds]
karmichammer has joined #commonlisp
wmblathers has joined #commonlisp
Bike has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
cosimone has joined #commonlisp
phantomics has quit [Read error: Connection reset by peer]
vats has quit [Ping timeout: 256 seconds]
<AeroNotix> disk space is cheap tho
<AeroNotix> Xach: is this a feature you'd consider?
<AeroNotix> tracking the reason something was installed
phantomics has joined #commonlisp
aartaka has joined #commonlisp
<nij-> Does ASDF support customizable fetcher? Something like (:depends-on (nyxt :host github :repo "atlas-engineer/nyxt" :hash "0a9sd0a9sd"))
<nij-> That CL is frozen in time provides the community a chance to make use of code written 30 years ago. However the liquidity of dependencies may break this.. thus the question.
<AeroNotix> you can use a snapshot of a quicklisp tree though
klimnbrk has joined #commonlisp
<AeroNotix> you can even make your own
<AeroNotix> which contains versions of whatever dependencies, at whatever versions
<semz> nij-: ASDF doesn't fetch at all.
<nij-> Is it one of the development goal for asdf to do this?
<nij-> I really hope any code in CL could still easily work in the far future (assuming the code and all its dependencies still exist).
<semz> https://asdf.common-lisp.dev/ suggests that it's considered out of scope (which makes sense to me)
karmichammer has quit [Ping timeout: 256 seconds]
<qhong> I do see a problem here. Seems that asdf specifies dependencies only with name, but with no version information? (at least I don’t see people writing such in asd) Then in the far future, systems might break because of accumulation of tiny incompatible changes in their dependencies
aartaka has quit [Ping timeout: 250 seconds]
voidbrkd has joined #commonlisp
<nij-> qhong: As suggested by semz, it seems that asdf dev team doesn't think it's an issue (at least for asdf to solve).
klimnbrk has quit [Ping timeout: 256 seconds]
<nij-> But indeed, that does break the dream of having codes that work *forever* (assuming existence, again).
<qhong> nij-: fetching is out of scope, but I’m unsure about versioning
<nij-> Got it, yeah.
shka has quit [Ping timeout: 240 seconds]
<qhong> ah, asdf3 actually support versioning
<qhong> I hardly see it in use though, and seems that it only ensure newer version (so not exactly solving the bit rotting problem)
<nij-> Does it support hash-specific versioning?
<EdLangley[m]> The solution is to not make breaking changes
<EdLangley[m]> I consider this a feature
<dre> you pay more for features
<nij-> EdLangley[m]: The solution is to make everyone to not make breaking changes?
<qhong> EdLangley[m]: hyrum’s law
<qhong> it’s pretty much impossible
<nij-> qhong: Hmm...... I only see version-specifier - https://asdf.common-lisp.dev/asdf.html
<EdLangley[m]> Package versioning makes it easy to make breaking changes
<nij-> But hash-specifier should be much more reliable.
<EdLangley[m]> Which results in things like pip and npm where people just go around breaking things
<nij-> It's ok. With hash-specifier I can just stick with the older version, which works.
<EdLangley[m]> Anyways, as far as hyrum’s law goes
<EdLangley[m]> If you’re using :: things breaking are your fault
<EdLangley[m]> If you’re using :, it’s on the dependency
<moon-child> that's for symbols
<moon-child> what about behaviour?
<EdLangley[m]> What about it?
<EdLangley[m]> External symbols that name functions should only change behavior in strictly additive ways
artchad has quit [Read error: Connection reset by peer]
<EdLangley[m]> If you want to break all your users, fork your package and rename it
<nij-> You're imposing other people to all do that, which is fine.
<nij-> But in reality, not everyone will do that.
<EdLangley[m]> semver-major changes are rude
<nij-> But as a community, we need to have a reliable way to use libraries.
Dynom has quit [Quit: WeeChat 3.4]
<nij-> I don't see a problem in hash-specifiers in this.
<moon-child> supposing I did not specify some behaviour in one version of my protocol?
<moon-child> specifying it is a strictly additive change
<EdLangley[m]> Yeah, and my point is, as a community, if we expect libraries never to push breaking changes, then we set up incentives to keep it that way.
<moon-child> but the unspecified way I behaved was relied upon by some user of my library
<qhong> EdLangley[m]: There’s no such thing as strictly additive. E.g. I might rely on a specific function to produce an error, and a later version that does not produce error breaks my code
<nij-> EdLangley[m]: that's too ideal.
<EdLangley[m]> No it’s not
<EdLangley[m]> I’ve never missed version bounds in CL
<nij-> That doesn't mean you won't in the later 50 years.
<EdLangley[m]> Over the last six years of using quicklisp
<nij-> CL needs to survive *forever*!
<EdLangley[m]> I can run forty year old code just fine
<nij-> All of them?
<moon-child> fwiw I don't think semver is the solution either
<EdLangley[m]> So, I assume things will mostly work as expected in fifty years
<moon-child> I agree if you break compat you make a new package name
<nij-> moon-child: what do you think about hash-specifier?
<moon-child> I just don't think it's reasonable to dismiss hyrum's law so
<moon-child> nij-: I hope common lisp will outlive git
shka has joined #commonlisp
<nij-> moon-child: ? It has nothing to do with git.
<EdLangley[m]> Well, my view is that if you’re depending on unspecified behavior, breakage is your fault
<moon-child> nij-: what does the hash identify then?
<nij-> Compute a hash of the whole system with a fixed algorithm, say md5sum.
<nij-> And when loading the system, first check if the hash agrees.
<qhong> EdLangley[m]: I also run 40 years code from say CMU AI repo just fine, but that’s because there were no ASDF, and they are self containing tarballs using `load`
<moon-child> so content-addressibility. Ok
<nij-> Yeah, things like this is very secure, and will ensure the code to keep working 50 years later. How sexy is that?
<moon-child> there is an interesting mailing list post by joe armstrong about that
<EdLangley[m]> Anyways, the problem with this scheme is it breaks the best feature of lisp
karmichammer has joined #commonlisp
<EdLangley[m]> It is fundamentally at odds with lisp’s interactive development
<nij-> EdLangley[m]: You cannot expect every major libraries to behave as you wish in your ideal for 50 years, can you?
<nij-> in your ideal way*
<EdLangley[m]> Why not?
<EdLangley[m]> This isn’t JavaScript
<EdLangley[m]> We don’t break things because we’re bored of them
<qhong> moon-child: ha, like “wiki-based development” which got brought up over and over again on LtU?
<nij-> EdLangley[m]: I see the merit in it.
<nij-> However, that also limits the numbers of usable libraries.
<phoe> how?
<nij-> Sure, the most important libraries will always be like that.
<nij-> But currently there are lots of libraries written that only acquired little popularity.
<nij-> If you want those to grow incrementally, the better way is to come up with a way that encourages people to use and extend it.
pve has quit [Quit: leaving]
<phoe> will breaking backwards compatibility increase their popularity in any way though?
waleee has quit [Ping timeout: 250 seconds]
<phoe> if by "usable libraries" you mean "not broken by the developers" then I think it's actually the reverse
<nij-> If the main building system in CL doesn't encourage that, those will be harder to be used.
<nij-> phoe: what do you mean?
<nij-> (and what do you think about hash-specifier, btw?)
<AeroNotix> you seem super hung up on using a hash-specifier like it's unique
tyson2 has joined #commonlisp
<AeroNotix> content-addressable stores are fine, I guess?
waleee has joined #commonlisp
<AeroNotix> _how_ you specify a version isn't really the interesting thing
<AeroNotix> you can require that versions take the form `banana-:digit:-apple`
<AeroNotix> same difference?
<nij-> AeroNotix: Yeah, in the end I just want content-addressability. This is how the functional package managers work.
<AeroNotix> nij-: so build it
<nij-> AeroNotix: I want to first understand why this isn't what's wanted in the major build system (asdf).
<AeroNotix> summing up the answers so far: ASDF doesn't have this functionality and it appears it does not intend to grow the functionality.
<nij-> AeroNotix: Well, in asdf3 they introduced version-specifier.. maybe hash-specifier or other type of content addressing tools are to come.
<AeroNotix> yeah again, not sure if you understood what I mentioned - the string format the version takes really isn't the important part
<AeroNotix> just 'does this string thing point to the same code over time'
<AeroNotix> things being content-addressable make it seem super duper megawow important, but ehh... ? Not really.
<nij-> yeah, that's why I think hash-specifier is the answer
<sveit> is there a way to get the "~G" format directive to not output trailing spaces? it seems in the spec that there is some "ee" parameter which gets used as "~ee@T" and "ee" is always set to at least 2.
<etimmons> nij-: :version has been around longer than ASDF 3
<nij-> Why not? consider 100 years later
<nij-> etimmons: Errrgh sorry my bad.
<etimmons> And there are no plans I'm aware of to add hash-specifier or similar
<AeroNotix> nij-: alright, I considered it
<AeroNotix> my main concern isn't around what the version string is, but rather, does the store that hold the code even still exist
<nij-> etimmons: Good to know. Do you know why they don't plan such tool?
<etimmons> My personal opinion is that such a thing belongs outside the ASDF system definition
<nij-> AeroNotix: That's another problem, which will never be solved.
voidbrkd has quit [Remote host closed the connection]
<nij-> etimmons: Got it. I respect that. I'm just curious why they also don't think it's a nice idea to use hash-specifiers.
<etimmons> A sufficient reason to not include it is how do you reconcile two systems that depend on the same system but at different versions/hashes
<etimmons> we can't simultaneously load two different versions of the same system
<qhong> FYI: I just tried loading hunchentoot 1.2.0 (from ~10 years ago). Loads fine, I run (asdf:test-system "hunchentoot"), test fails
<qhong> I'm afraid contemporary projects based on ASDF will not work after a dozen of years, totally unlike the projects 40 years ago
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
<qhong> etimmons: it can be done, at least for systems that don’t do wacky stuff like introspecting symbol-package. `rename-package` hack
<masinter> 2022-40 = 1982 but there wasn't CLtL1 until 1984
Algernon69 has joined #commonlisp
<_death> qhong: does the test fail because of asdf?
<mgl> Is there a way to get the default values of &optional and &key arguments of a function on CCL?
<mgl> (ccl:arglist (lambda (&optional (o 1)))) => (&OPTIONAL O)
<qhong> _death: no. It seems like changed behavior in `drakma`
<qhong> hyrum's law in action, probably
<_death> qhong: so why do you say "based on ASDF"?.. besides, saying they're "based" on asdf is a bit of a stretch.. sure, they have an .asd file and old projects may have had a different defsystem file, but that doesn't mean they're "based" on it.. the actual difference between hunchentoot and the older projects is the number of dependencies
mgxm has quit [Quit: ....]
<qhong> _death: you are correct.
<_death> qhong: many old projects are self-contained.. some however depend on mcclim or genera code or whatever, so those are less likely to work without changes
karmichammer has quit [Ping timeout: 256 seconds]
<_death> *depend on clim
mgxm has joined #commonlisp
<qhong> I still think this should and can be fixed, say, if projects document the exact version of their dependencies, so that a working system in the past can always be reproduced in the future
<_death> mgl: why not use alexandria's function? it gets you the init forms
<mgl> _death: which function?
<_death> parse-ordinary-lambda-list
<mgl> I don't have a lambda list. I have a function object.
<_death> function-lambda-expression?
<qhong> _death: ccl seems to typically yeet nil,nil,nil for anything
<_death> I see
<mgl> _death: nice. f-l-e seems to do the trick
<mgl> argh, it was on allegro. ccl indeeds returns nil
<random-nick> I agree it would be nice if CL library releases would include a file which lists versions of their dependencies at the time of release/testing
<random-nick> however I don't think it should be respected by default because of the version conflict issue
<random-nick> but nowadays it seems many libraries don't do releases/versioning at all
<phoe> ...or they try to be fully backwards compatible, which limits the amount of damage that non-versioning can do
<EdLangley[m]> I sort of think the best thing to happen to a CL package is for it to be basically done and then become unmaintained
<phoe> or, in other words, "complete"
<EdLangley[m]> Yeah
Inline has joined #commonlisp
<EdLangley[m]> Code doesn't rot
<_death> well, I'd say that even if the interface is not perfect, there are usually many improvements that can be made on the implementation side.. and exposing a new interface without breaking the old one is often possible too.. these things take more effort and imagination and require an anti-churn attitude that respects users.. and outside CL all kinds of pressures lead to the opposite attitude
<EdLangley[m]> Yeah, I don't mind improvements
<EdLangley[m]> And I'm a bit biased by writing JS professionally
mgxm has quit [Quit: ....]
<EdLangley[m]> But, it seems to me like maintainers often get sort of bored with something that works and then start breaking it
mgxm has joined #commonlisp
<EdLangley[m]> Python 2 -> 3, Perl 5 -> 6, Scala 2 -> 3, etc.
<AeroNotix> EdLangley[m]: code does rot
<EdLangley[m]> It doesn't
<AeroNotix> EdLangley[m]: it's just the reasons for the rot are irrelevant to CL because CL itself is unchanging
<EdLangley[m]> Unless your dependencies change under you
<AeroNotix> and that's not necessarily a good thing, but it is a benefit of basing your project on CL
<EdLangley[m]> Which means you picked the wrong dependencies, IMO
<qhong> _death: hyrum’s law again
<AeroNotix> I've said it previously when this channel was on freenode but imho CL is in need of a modernized standard
<EdLangley[m]> Why?
<EdLangley[m]> We have good-enough portability libraries for the gaps in the standard
<AeroNotix> on the face of it CL being so set in stone itself seems like a good thing but you end up with balkanization of useful features when they are implemented in poor libraries
<moon-child> EdLangley[m]: it would be better if those portability libraries were standardised
<EdLangley[m]> So, I've seen python people say things like "the standard library is where libraries go to die"
<AeroNotix> Modern concurrent programming is, imho, a large feature which CL lacks. Libraries are all over the place and maintained by the few, pushed to the limits by no-one
<phoe> if we had a standardization committee member every time this topic was mentioned then we would have multiple X3J13 by now :D
<EdLangley[m]> It's better for things not to be standardized so we can swap them out
<AeroNotix> and if they are reasonably halfway decent, they're supported by only a couple of implementations
<moon-child> EdLangley[m]: how can you swap out named readtables? package local nicknames?
<moon-child> and regarding threads, see boehm 'threads cannot be implemented as a library'
<EdLangley[m]> Named readtables is just a hash table of readtables
<AeroNotix> imho the fact CL is so stagnant is a big part of why its popularity stays so niche
<semz> phoe: and we probably still wouldn't have a new standard :-)
<EdLangley[m]> As far as threads goes, the implementations implement threads and the portability library standardizes the interface
<_death> what may be good is more specifications (extensions to the standard) that are agreed upon and implemented by lisp implementation vendors.. but it requires $$$.. if only there were some rich Lisp people who were interested in pursuing this ;)
<EdLangley[m]> Which works pretty well
<moon-child> AeroNotix: do not mistake stability for stagnation
<EdLangley[m]> bordeaux-threads is pretty good
<AeroNotix> threads are literally the most basic and error-prone concurrency mechanism
<EdLangley[m]> IMHO, people are used to churn in JS, Ruby, Python and similar
<EdLangley[m]> And miss it in CL
<AeroNotix> the industry has moved on, we're literally decades ahead of simple threads
<moon-child> EdLangley[m]: the interface is not standardised to the level of quality I would like
<EdLangley[m]> AeroNotix: Sure, and you can build your CSP library on top of them
<AeroNotix> EdLangley[m]: have you USED the popular CSP libraries?
<AeroNotix> guessing you have not
<AeroNotix> because they are rubbish
<EdLangley[m]> moon-child: So, make a PR to B-T or come up with a new portability library
<AeroNotix> they spin the CPU on the most basic of operations, for example
<EdLangley[m]> But, again, we don't need a standard here
<moon-child> we don't need any standard in the first place, again
<moon-child> but I think it provides a lot of value
<EdLangley[m]> We just need someone to write a good library and/or improve bordeaux-threads
<AeroNotix> my suggestion is that no standard in a platform and community such as CL's leads to terrible balkanization where no-one is the winner
<EdLangley[m]> It's a bit strange to complain about the standard causing stagnation and then suggest standardizing more things would help
<EdLangley[m]> Things that are standardized can't change, by definition
<moon-child> isn't this what you suggested? Append-only?
<EdLangley[m]> So, if we come up with better interfaces and/or techniques, they can only be implemented as libraries on top of the standard
<AeroNotix> EdLangley[m]: I think standardization is good, and CL in particular lends itself well to that model
<EdLangley[m]> Which, to me, suggests we make the standard as minimal as possible to support a healthy library ecosystem
<EdLangley[m]> And then let vendors add on things like sockets and threads
karmichammer has joined #commonlisp
<EdLangley[m]> And have libraries to sort out the vendor extensions into things that are portable between implementaitons
<moon-child> sure. For many things that works. But, again, _threads cannot be implemented as a library_
<AeroNotix> my opinion is that because the standard is coming up on quite literally 30 years old, it's missing out on a lot of progress
* moon-child shuts up
<semz> They aren't implemented as a library!
<EdLangley[m]> Yeah, they're vendor extensions
kevingal has joined #commonlisp
<AeroNotix> EdLangley[m]: we have the situation you mention, 'standard as minimal as possible'
<AeroNotix> since the standard is unchanging
<moon-child> sure. Where is my memory model? Can I be sure that abcl, ccl, and sbcl all implement the same semantics?
<EdLangley[m]> Exactly
<EdLangley[m]> And that's why I like CL
<AeroNotix> and we quite literally do not see a healthy library ecosystem
<EdLangley[m]> It's like #1 on the list of reasons why I like CL
shka has quit [Ping timeout: 240 seconds]
<phoe> I think this problem is always answered best by "who's supposed to do this and who's supposed to pay them"
<EdLangley[m]> And the library ecosystem is pretty great
<EdLangley[m]> There are lots of gaps
<contrapunctus> .o(Wasn't there some talk of restarting the CDR process?)
<phoe> until this is answered there's little point reliving the same debates over and over
<AeroNotix> EdLangley[m]: those two statements are in conflict
<EdLangley[m]> Not really
<phoe> and CDR is kinda meant to be append-only
<EdLangley[m]> "healthy" and "complete" are different
<phoe> "it would be nice if CL had a revised specification" is a truism; the real meat of that issue is who are the people and whence comes the money, everything else has already been said probably hundreds of times before
<phoe> and until this meat has an appropriately meaty answer we are bound to repeat history, except as farce
<EdLangley[m]> The reason I stopped using Python is that they revised the "specification"
<EdLangley[m]> I don't think it's obvious that updating the spec will improve things
<EdLangley[m]> It's more likely to cause a second-system effect that kills everything
lispy has quit [Quit: Leaving]
<qhong> EdLangley[m]: what’s your opinion on SRFI?
<phoe> EdLangley[m]: true
<contrapunctus> Maybe it's time to start something akin to XEPs and SRFIs? Sounds like that way the existing standard remains untouched, but there's a library standardization process...
<contrapunctus> qhong: aha ;)
<EdLangley[m]> I like SRFI because they're layered on top of the standard
<EdLangley[m]> But, I'd prefer them to be implementations rather than just docs
<phoe> contrapunctus: that's CDR, which are, again, meant to be append-only
<contrapunctus> phoe: I'm saying "something not append-only, then"
<qhong> EdLangley[m]: SRFIs are usually doc+a reference impl+real impls by vendors
<EdLangley[m]> Cool, that's the sort of process I'd prefer
szkl has quit [Quit: Connection closed for inactivity]
<EdLangley[m]> e.g. turning bordeaux-threads into a spec
morganw has quit [Remote host closed the connection]
<EdLangley[m]> And usocket
<moon-child> that's what I was suggesting
<qhong> Also MOP
<EdLangley[m]> MOP already is a spec
<EdLangley[m]> although, the effective spec is probable closer-mop
<EdLangley[m]> The second half or so of AMOP was intended to be a spec
<_death> EdLangley[m]: the updates could constitute clarifications etc. like WSCL.. but there's a lot of room for new specs, some of which don't actually require participation of lisp implementation vendors, but may require participation of lisp library writers in particular fields
<AeroNotix> I personally wouldn't care which form it takes... the above sounds reasonable to me
<AeroNotix> my point is more that people are off in the weeds implementing modern tooling on 30 year old software
<AeroNotix> and we have pockets of brilliance which are tarnished by the fact there's no cohesion between any thing
<contrapunctus> phoe: even append-only is fine, I guess, since newer ones can supercede older ones. cf. XEPs - each one gets a new number, it's just that the older ones are rarely changed and the current set of relevent XEPs changes; the older, deprecated XEPs don't go anywhere.
<AeroNotix> libraries fester, are incomplete or lack the performance or usability required because implementations are well, 30 years old and are unchanging to their needs
<_death> again, this requires time and will, and the fuel is $$$.. PG went back to roots with Arc and Bel.. maybe someone should point out that the next language starts with the letter "C" :).. there are potential patrons for such a process who were (or even are) part the Lisp world.. I dunno why, but I've not seen any of them talk about that, though they usually do show some interest in Lisp
<fe[nl]ix> I'm not sure what you mean by turning Bordeaux-threads into a spec
<fe[nl]ix> without buy-in from the implementors it won't go anywhere
<fe[nl]ix> and that's the main problem with the CDR process
karmichammer has quit [Ping timeout: 268 seconds]
<fe[nl]ix> if you look at past documents, they were introduced and marked as "final" within a month
<fe[nl]ix> just to be ignored by almost everybody
<EdLangley[m]> I just mean specifying the semantics of its exported symbols sufficiently
<_death> fe[nl]ix: maybe the problem there is that they were written by individuals
<contrapunctus> fe[nl]ix: hm...did implementation maintainers not participate in the CDR process? And did nobody request or aid CDR implementation? 🤔️
<EdLangley[m]> If we have the library and it's implementable on top of what existing implementations provide, it's mostly fine
<_death> there was no pressure to standardize from some entity with resources
pillton has joined #commonlisp
pillton has quit [Remote host closed the connection]
pillton has joined #commonlisp
<fe[nl]ix> the only implementors I see there are Xof and Sam Steingold, so SBCL and Clisp
<fe[nl]ix> I would be surprised if the others even heard about it
<_death> the "hyrum's law" stuff can be mitigated by things like section 1.6
occ has quit [Ping timeout: 256 seconds]
mon_aaraj is now known as mon
<_death> fe[nl]ix: what's interesting though is that something like PLN, which has no real specification, was implemented by several Lisp vendors..
mon is now known as mon_aaraj
<fe[nl]ix> what's PLN ?
<_death> package-local nicknames
<fe[nl]ix> that's not even a CDR :D
<_death> exactly
<fe[nl]ix> and yes, there was enough demand that mostly similar functionality was implemented
<White_Flame> that's how "Common" lisp formed, after all
<_death> so maybe a CDR for that is in order
<_death> ;)
<fe[nl]ix> you'll see what I mean by "mostly similar"
Algernon69 has quit [Ping timeout: 268 seconds]
<fe[nl]ix> if you're interested in precise semantics, the compatibility is crappy
<moon-child> I was told sbcl docs were canon
<moon-child> read them
<moon-child> they had holes
<moon-child> so I'm not surprised
karmichammer has joined #commonlisp
<fe[nl]ix> EdLangley[m]: most of the things that are important require changes to the implementations
<fe[nl]ix> MOP, threads, etc...
<_death> right, so this could be a first target.. the variants are not too different, and it's recent enough, and could improve via pressure of standardization
<fe[nl]ix> I'm working on making Bordeaux-threads APIv2 as good as possible, with lots of tests but there are limits
<moon-child> fe[nl]ix: hm, I think you can do completely portable clos/mop
<moon-child> no?
<fe[nl]ix> and I very much doubt that implementors are willing to change incompatibly
<moon-child> (well. I guess technically you can also do completely portable reader, and your own PLN. SO maybe it does not signify much)
<_death> (btw personally I don't use PLNs.. I just give it as an example of something not too complicated that's ready for standardization)
<_death> fe[nl]ix: right, the bigger the surface, the more funding would be required
<_death> fe[nl]ix: this all reminds me of what I wrote a while ago https://old.reddit.com/r/Common_Lisp/comments/j7vd25/a_curated_standard_library_for_common_lisp/g89544v/ .. if anyone's interested
<pillton> _death: Nicely written. People seem to confuse standards, libraries and language.
<nij-> >> etimmons> A sufficient reason to not include it is how do you reconcile two systems that depend on the same system but at different versions/hashes
<tyson2> join #wls
<nij-> Hmm I think you are right, etimmons, unless the system with two different hash-specifiers (versions) can be loaded simultaneously without name clashings..
<nij-> A hack of this seems to require a hack of how package works now. E.g. instead of 'nyxt:start, we need 'nyxt-0sa98d:nyxt:start. (where 0sa98d is the hash)
<mfiano> _death: Well said
<nij-> But then this couples the notion of systems and the notion of packages..
<nij-> qhong: what do you think about this?
<mfiano> We'll just have to wait for FCGE's to be a defacto standard
myrrh has quit [Ping timeout: 268 seconds]
shozo has joined #commonlisp
lispy has joined #commonlisp
<nij-> qhong: The usual strategy used by nix or guix doesn't work immediately here. By loading two different versions of the same system, the packages will be collided.
attila_lendvai has quit [Ping timeout: 256 seconds]
dra has joined #commonlisp
<qhong> nji-: It's good enough for retrofitting into CL.
<qhong> it actually sounds pretty cool to implement sth like nix/guix, but totally within a lisp process (like how make compare to asdf)
<nij-> qhong: Or maybe guix itself is the solution to this..
<EdLangley[m]> What you need is something like linux containers, but inside lisp
<qhong> nij-: one lisp image spawning lisp processes through UNIX shell? eww
cosimone has quit [Ping timeout: 256 seconds]
<EdLangley[m]> A way to have some sort of sub-lisp system where you can load all a system's dependencies and then only expose a specified set of packages to the "global" lisp
<mfiano> FCGEs
<EdLangley[m]> i.e. first-class global environments, or something like that
<qhong> or drop the global, just FCEs
<mfiano> No, FCGEs are a thing. Let's refer to them as their inventor intended
masinter has quit [Quit: ~ Trillian - www.trillian.im ~]
<qhong> it's restricted FCE? FCEs are also a thing
<mfiano> No relation
<nij-> qhong: Well I mean to install the packages through guix in the first place.
<nij-> Hmm but that's also kinda off.
<nij-> I don't know what FCGEs have anything to do with this..could someone explain?
<EdLangley[m]> It would let you load multiple versions of a single system into one lisp image
<qhong> mfiano: I'm pretty sure FCGE is a special case of general FCE
karmichammer has quit [Ping timeout: 240 seconds]
<EdLangley[m]> Because you could sandbox them from each other
<nij-> EdLangley[m]: :O !! What's the current status of FCGE in CL?
<fe[nl]ix> nij-: not happening
<nij-> :'( why not.. not even in SICL?
<EdLangley[m]> I think sicl can be loaded in sbcl and is somewhat usable? It's been a while since I've heard much about it
<EdLangley[m]> (because I've been off IRC for a while)
<nij-> It's not complete yet, at least.
gamaliel has quit [Quit: Client closed]
<fe[nl]ix> first-class environments means implementors have to rewrite their compilers, and requires new APIs
<Catie> "not happening" as in "not going to be a part of the standard"?
<fe[nl]ix> it will be a miracle if just one of the major implementations gets this feature in the next 5 years
varjag has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)]
<qhong> better just revive kernel instead if we have the effort ;D
<mfiano> qhong: That depends on which FCE you are referring to. There are several, each very different from each other.
karmichammer has joined #commonlisp
<nij-> fe[nl]ix: I see.. Hopefully SICL will be done soon.
<qhong> mfiano: I rather view it as very unambiguous. Like concretely different language may have very different semantics of lambda, but we in general agree that lambda is that one thing in lambda calculus, approximated to different extent by each language
<qhong> mfiano: FCE on the other hand is simply "the reification of the \rho in lambda calculus' standard denotational semantics"
<mfiano> Oh, you aren't familiar with the implementations.
<qhong> just like first class continuation is "the reification of the \kappa in lambda calculus' standard denotational semantics"
<nij-> Naive question: What ever FCGE is, it should be contained in itself, right? How does that work? Self pointing object?
<jasom> nij-: don't know how it works, but I would assume that it would make a tree (that is the root global-environment could contain pointers to other global environments and so on)
karmichammer has quit [Ping timeout: 268 seconds]
<jasom> It seems like it's optional for any given FCGE to contain a reference to itself. Imagine that you have a working FCGE, if you remove the pointer to itself, you only lose the ability to directly query and manipulate the environment, which you didn't have in a CL without the FCGE
myrrh has joined #commonlisp
<nij-> jasom: gotcha
<nij-> fe[nl]ix: I'm a bit confused. Suppose SBCL wants to introduce FCGE. What would be the hard work? Well, the global environment is stored in some format already. They just need to write some API to expose that global env, right?
<jasom> nij-: instead of "some format already" think "spread out all over the image, without any thought to making clones"