Xach 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>
selwyn has quit [Read error: Connection reset by peer]
Qwnavery has quit [Quit: WeeChat 3.2]
makomo has joined #commonlisp
raeda has joined #commonlisp
raeda_ has quit [Read error: Connection reset by peer]
waleee has quit [Ping timeout: 240 seconds]
bpanthi977 has joined #commonlisp
bpanthi977 has quit [Quit: bpanthi977]
yitzi has quit [Quit: Leaving]
lisp-newbie has joined #commonlisp
dlowe has quit [Remote host closed the connection]
akoana has quit [Quit: leaving]
dsk has quit [Ping timeout: 240 seconds]
brettgilio has joined #commonlisp
nij- has joined #commonlisp
<nij-> Has anyone tried sbcl on windows? SBCL's official site says it's experimental there. What's the implementation that supports Windows the best?
<hayley> I once "deployed" a program on SBCL on Windows, and it appeared to work fine.
<hayley> We'll say a dozen users using the networking and threading implementation without issues.
<nij-> Sounds promising.. which program is that? (a secret?)
makomo has quit [Ping timeout: 258 seconds]
<hayley> Yes, a secret. Sorry.
lad has quit [Ping timeout: 252 seconds]
<nij-> No worries :) I'm encouraged enough to get a VM and test it on Windows. Thanks!
<hayley> Though I never actually tested it on Windows, funnily enough.
raeda has quit [Ping timeout: 258 seconds]
<nij-> Oh wow. It works.. though it's sbcl 1.4.14.. it still works.
<nij-> Getting my hands on windows reminds me the "good old days" :))
sander has quit [Quit: So long! :)]
sander has joined #commonlisp
lisp-newbie has quit [Quit: This computer has gone to sleep]
lisp-newbie has joined #commonlisp
lisp-newbie has quit [Quit: This computer has gone to sleep]
lisp-newbie has joined #commonlisp
lisp-newbie has quit [Remote host closed the connection]
taiju has quit [Ping timeout: 258 seconds]
lisp-newbie has joined #commonlisp
lisp-newbie has quit [Remote host closed the connection]
lisp-newbie has joined #commonlisp
lisp-newbie has quit [Remote host closed the connection]
lisp-newbie has joined #commonlisp
lisp-newbie has quit [Remote host closed the connection]
taiju has joined #commonlisp
prxq_ has joined #commonlisp
prxq has quit [Ping timeout: 256 seconds]
pranavats has left #commonlisp [#commonlisp]
beach has quit [Killed (NickServ (GHOST command used by beach`!~user@2a01:cb19:150:3400:bf91:f21a:87da:7f64))]
beach has joined #commonlisp
dave_ has quit [Read error: Connection reset by peer]
<beach> Good morning everyone!
<phantomics> Morning beach
<Josh_2> 'mornin
pranavats has joined #commonlisp
karlosz has joined #commonlisp
z3t0 has quit [Read error: Connection reset by peer]
kakuhen has joined #commonlisp
lisp-newbie has joined #commonlisp
z3t0 has joined #commonlisp
dsk has joined #commonlisp
taiju has quit [Ping timeout: 258 seconds]
taiju has joined #commonlisp
<sm2n> Bike, I just updated to sbcl 2.1.7 and PARSE-COMPILER-MACRO from INTROSPECT-ENVIRONMENT appears to be erroring out on build, just wanted to make sure you were aware (I don't actually use the library directly, but I noticed it with quickload :verbose t)
lad has joined #commonlisp
<Bike> i can take a look. that function is always going to be brittle as hell, though.
<sm2n> I thought as much looking at it
cjb has quit [Ping timeout: 256 seconds]
taiju has quit [Ping timeout: 245 seconds]
taiju has joined #commonlisp
lisp-newbie has quit [Quit: Leaving]
karlosz has quit [Ping timeout: 240 seconds]
nirnam has quit [Read error: Connection reset by peer]
karlosz has joined #commonlisp
nirnam_ has joined #commonlisp
nirnam_ is now known as nirnam
z3t06 has joined #commonlisp
z3t0 has quit [Ping timeout: 240 seconds]
z3t06 is now known as z3t0
Bike has quit [Quit: Lost terminal]
easye has joined #commonlisp
Inline has quit [Quit: Leaving]
karlosz has quit [Quit: karlosz]
karlosz has joined #commonlisp
karlosz has quit [Client Quit]
karlosz has joined #commonlisp
wilfred has joined #commonlisp
karlosz has quit [Quit: karlosz]
rgherdt has joined #commonlisp
amb007 has quit [Ping timeout: 272 seconds]
amb007 has joined #commonlisp
gaqwas has joined #commonlisp
notzmv has quit [Read error: Connection reset by peer]
Lord_of_Life has quit [Ping timeout: 258 seconds]
Lord_of_Life_ has joined #commonlisp
silasfox has quit [Ping timeout: 252 seconds]
Lord_of_Life_ is now known as Lord_of_Life
silasfox has joined #commonlisp
retropikzel has joined #commonlisp
rain3 has joined #commonlisp
bpanthi977 has joined #commonlisp
Wairu_Goodman has joined #commonlisp
nirnam has quit [Quit: leaving]
pve has joined #commonlisp
tfeb has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
gaqwas has quit [Ping timeout: 258 seconds]
amb007 has quit [Read error: Connection reset by peer]
tfeb is now known as tfb
nature has joined #commonlisp
selwyn has joined #commonlisp
amb007 has joined #commonlisp
rgherdt_ has joined #commonlisp
nature has quit [Ping timeout: 258 seconds]
selwyn has quit [Read error: Connection reset by peer]
peterhil has joined #commonlisp
z3t00 has joined #commonlisp
selwyn has joined #commonlisp
rgherdt has quit [Ping timeout: 258 seconds]
z147 has joined #commonlisp
z3t0 has quit [Ping timeout: 258 seconds]
z3t00 is now known as z3t0
tfb has quit [Quit: died]
<phoe> how is readtable-case :INVERT useful? what are its main benefits?
<pjb> phoe: it provides end-to-end case sensitive symbols, while allowing lower-case entry of symbol named in uppercase.
nature has joined #commonlisp
<pjb> phoe: (let ((*readtable* (copy-readtable))) (setf (readtable-case *readtable*) :invert) (mapcar (function symbol-name) (read-from-string "(all-lower ALL-UPPER MixedCase)"))) --> ("ALL-LOWER" "all-upper" "MixedCase")
<pjb> phoe: so that (not (eq 'foo 'FOO)) and (not (eq 'foo 'Foo)) but (eq 'if (find-symbol "IF" "CL"))
<jackdaniel> phoe: it is in linked issues afair
<pjb> phoe: as extensions, you may mention "modern" (allegro) mode (which is similar to :invert, but different), and eg. clisp case sensitive package (eg. symbols interned in LINUX are case sensitive, so that (symbol-name 'LINUX:open) -> "open".
lisp123 has joined #commonlisp
<lisp123> is the CLHS wrong re description of prog2? Based on the syntax it seems to return the result of the second form not the first form
<jackdaniel> basically: make foobar to be recognized like ordinary lisp as FOOBAR and have FooBar recognized as such (for parsers of other languages, like Java)
<phoe> lisp123: yes
<pjb> lisp123: yes, it's a known spelling error. See wscl
<phoe> jackdaniel: thanks
<lisp123> phoe & pjb: thanks
<lisp123> What's wscl?
<phoe> mingus: tell lisp123 about wscl
<phoe> oops sorry
<phoe> minion: tell lisp123 about wscl
<minion> lisp123: wscl: Well-Specified Common Lisp. Pronounce it as "whistle". A project to revise the Common Lisp standard in a non-controversial way. See https://github.com/robert-strandh/Well-Specified-Common-Lisp
<lisp123> thanks minion
<hayley> Hm, shouldn't that link to the S-expressionists repository?
<pve> phoe: at one point, I used :invert when reading code for that smalltalk-like language I'm working on. It was quite convenient to have, so I was happy that it was built-in.
<phoe> pve: thanks!
<phoe> hayley: possibly
<phoe> beach: what do you think? should you point the contents of your repository towards s-expressionists, or should minion be modified?
<pve> phoe: oh right, basically exactly what jackdaniel said
robin has quit [Quit: Leaving]
<jackdaniel> it is hinted in the linked issue, but I think that I've read somewhere about this design decision in more detail
<beach> phoe: The latter now, I think.
dsk has quit [Ping timeout: 240 seconds]
retropikzel has quit [Remote host closed the connection]
retropikzel has joined #commonlisp
rt has joined #commonlisp
hendursa1 has joined #commonlisp
hendursaga has quit [Ping timeout: 244 seconds]
rgherdt_ has quit [Read error: Connection reset by peer]
rgherdt_ has joined #commonlisp
<phoe> minion: add wscl as "Well-Specified Common Lisp. Pronounce it as "whistle". A project to revise the Common Lisp standard in a non-controversial way. See https://github.com/s-expressionists/wscl"
<minion> OK, done.
<phoe> minion: tell phoe about wscl
<minion> phoe: wscl: Well-Specified Common Lisp. Pronounce it as "whistle". A project to revise the Common Lisp standard in a non-controversial way. See https://github.com/robert-strandh/Well-Specified-Common-Lisp
<phoe> uh oh, let me try to fix minion in private
<beach> Hmm.
<beach> Maybe remove the old one first.
<phoe> ah-ha, yes, that solves it
<phoe> minion: tell phoe about wscl
<minion> phoe: wscl: Well-Specified Common Lisp. Pronounce it as "whistle". A project to revise the Common Lisp standard in a non-controversial way. See https://github.com/s-expressionists/wscl
<beach> Perfect!
<beach> Thank you!
<phoe> for future reference: the command is "forget"
<beach> I notices that minion joined other channels like #clschool as well. That can come in very handy.
<beach> ... and #sicl.
rt is now known as robin
<phoe> hmmmm
<phoe> that is useful!
makomo has joined #commonlisp
selwyn has quit [Read error: Connection reset by peer]
silasfox has quit [Quit: WeeChat 3.2]
notzmv has joined #commonlisp
retropikzel has quit [Ping timeout: 256 seconds]
<phoe> mutating a string that is a package name invokes UB, right?
<beach> Good question. I would think so.
<phoe> CLHS Function PACKAGE-NAME and System Class PACKAGE do not mention this
<phoe> it does confuse SBCL, as the altered package can no longer be FIND-PACKAGEd
<beach> Nor does MAKE-PACKAGE.
<phoe> UB enough, then
<phoe> ;; maybe it's worth WSCLing this topic
<beach> Absolutely!
<phoe> :D
<hayley> While a "controversial" change, it wouldn't hurt to have the implementation copy the string?
<beach> Right, both times. Or stick the string in read-only memory.
<hayley> I see that INTERN states it is UB to alter the string that names a symbol.
<hayley> "the HyperSpec page for INTERN" rather
icer has quit [Ping timeout: 250 seconds]
<hayley> You don't tend to INTERN much in a loop, let alone MAKE-PACKAGE in a loop, so I don't think there are huge performance raisins for not copying. But again, my suggestion is evidently not what Lisp implementations already do.
<kakuhen> what's the deal behind WSCL? it looks like i misinterpreted what it was supposed to be
bpanthi977 has quit [Remote host closed the connection]
<kakuhen> i thought it was going to be something like a modernized version of the hyperspec but without all the pesky restrictions attached to it
nature has quit [Ping timeout: 268 seconds]
<hayley> The result would be presentable like the HyperSpec (though, if you can use an extension which lets you add CSS to websites, it can be made to look nice), but I believe the idea is to clean up ambiguities left in the HyperSpec and ANSI standard.
<kakuhen> Has there been discussion on the behavior of RANDOM yet? It seems that there could be better elaboration on "[a]n approximately uniform choice distribution"
<kakuhen> say you want to generate random floats, one implementation may generate floats with uniform distribution over R but another one may not (although it may give a uniform distribution over the set of floats that it can possibly generate)
<kakuhen> there's no way to tell without actually seeing how the implementation handles RANDOM
<shka> kakuhen: i think that this nitpicking at this point
<kakuhen> well, coming from a math background, this seems like a perfectly reasonable question to me
<shka> the intention seems to be "not Gaussian distribution or anything like that"
<shka> from the practical standpoint CL:RANDOM is perfectly well suited for most applications that require uniform random number, but probably not for the cryptography
<shka> and i don't think that anything would change that
<shka> besides, cl:hashtable can be implemented with linear scan and nobody seem to freak about it
<kakuhen> OK. Let's say I decide to implement RANDOM such that we generate random floats that converge in distribution at an awfully slow rate (i.e. we need a very large N to be within even a rather large epsilon of a uniformly distributed RV with the same image)
<beach> kakuhen: The main idea with WSCL is to make sure that the Common Lisp LANGUAGE is safe, in addition to the majority of the implementations. As it turns out, there are many situations in the standard where the behavior is undefined, and in many of those situations, it is not necessarily justified to leave the behavior undefined.
<kakuhen> as long as there is a convergence in distribution, this seems to quality as "approximately uniform" but in practice that's obviously not going to be good enough for people who want something like a uniform dist
<kakuhen> seems to qualify as*
<kakuhen> beach: I see. So WSCL is more about clarifying corner cases of the spec, right?
<shka> kakuhen: sure, in such case, you are getting bug requests to fix your cl:random
<phoe> kakuhen: the fact that it's conforming doesn't mean that it's bug-free
<phoe> (or useful)
<kakuhen> OK there we go
<beach> kakuhen: Slightly more ambitious than that. It's about defining behavior in safe code (term defined by the glossary) in a way that most implementations already do.
<kakuhen> phoe: That answers my question perfectly, actually
<kakuhen> I was mistakenly believing conformity to the spec implied some level of correctness when I shouldn't have done so
<phoe> you can conform by setting CL:ARRAY-TOTAL-SIZE-LIMIT to 1024 in your implementation
<phoe> but you really, really do not want to do this
<beach> kakuhen: I think you are confusing "correctness" with "completeness".
<phoe> ;; and regarding randomness there's always this https://www.incibe-cert.es/sites/default/files/blog/comprobando-aleatoriedad/dilbert.png comic
<beach> kakuhen: If the standard explicitly says that in some situation, the behavior is undefined, then any behavior an implementation chooses to do is conforming.
<beach> kakuhen: But, if it is not justified to have that situation imply undefined behavior, it is better to alter the specification to specify what happens in that situation.
<shka> also, specifying things like random to such details in practice often in practice enforces the implementation strategy
<jackdaniel> The random numbers are too important to leave them to chance.
<shka> jackdaniel: nice one
<jackdaniel> thanks
<kakuhen> phoe: I've seen that comic several times before, and I've always had an issue with it, but I don't want to post too much offtopic ramblings in here, heh.
<jackdaniel> right, there are passages where in the safe code virtually every implementation will signal a condition - the problem is that each implementation will signal something different since it is not specified
<phoe> kakuhen: #lispcafe welcomes you
nirnam has joined #commonlisp
tfeb has joined #commonlisp
tfeb has quit [Client Quit]
makomo_ has joined #commonlisp
scymtym has quit [Ping timeout: 258 seconds]
makomo has quit [Ping timeout: 272 seconds]
<beach> kakuhen: For example, the standard for the C language leaves the behavior unspecified in many situations. Most C compilers take advantage of this situation to do whatever gives the highest performance, resulting in a language that is unfit for most programming tasks.
<beach> kakuhen: The Common Lisp standard has many such situations as well, but the tradition for Common Lisp systems is to detect the situation and signal an error, at least when performance is not an issue. So it seems reasonable at this point to transfer this tradition to the language specification, and very little needs to be done in implementations to conform.
<beach> kakuhen: A similar thing would not work in the C language, because every existing compiler would then be in violation of the new specification, and C programmers seem to not mind using an unsafe language anyway, preferring maximum performance (for reasons I fail to understand, but hey).
<nij-> Can't believe this happening. WSCL might be the first major hard fork of Common Lisp. Thanks for the work <3
<nij-> (I mean it's going to be an effective fork. Similar, but effectively a new standard.)
<beach> It is neither a fork nor major, which is the point.
<nij-> Hopefully the diff won't be too large, and will be clearly doc in a file.
<nij-> Not a fork?
<beach> nij-: Not really. Since every implementation of WSCL is also an implementation of Common Lisp, I wouldn't call that a "fork".
<beach> It will be similar to the "strict HTML" tag that some web sites announce.
<beach> An implementation would say "WSCL conforming".
<nij-> What really defines Common Lisp? Is it CLHS?
<beach> Sort of. The standard, and the Common Lisp HyperSpec is pretty much the same as the standard.
<nij-> I might being too picky - forgive me - but if CLHS is the definition of CL, and if CLHS contains some error, and if WSCL corrects those errors, then an impl of WSCL isn't really an impl of CL..
<nij-> (It would be better, of course. But strictly speaking it won't be a CL impl...)
<beach> nij-: The ambition is not to "correct errors". It is to define situations where the standard explicitly says the behavior is undefined.
kevingal has joined #commonlisp
<nij-> I see
<beach> nij-: So if the standard says that some behavior is undefined, and WSCL defines it, WSCL is still Common Lisp.
wilfred has quit [Quit: Connection closed for inactivity]
<nij-> Yes. Going through the commit history again of WSCL indeed I haven't seen any error to be fixed.
<beach> nij-: When a standard or a specification says that some behavior is undefined, it doesn't mean that an implementation of the standard has to behave in some unpredictable way. It means that an implementation is free to behave in whatever way it sees fit. So by taking such situations in the Common Lisp standard where a particular behavior seems reasonable, even though the standard doesn't say that, WSCL is still conforming.
<nij-> My false impression could come from previous discussion..
<nij-> Yep
<nij-> Some time ago, iirc (hopefully), you mentioned there are some errors in clhs..
<beach> Having said that, I admit that there are things in the standard, like PROG2, that are obvious mistakes, and we can correct those. It would be uncontroversial as well.
<beach> Yes, and those obvious errors have mostly been turned into WSCL issues by Bike.
<nij-> Great work! :)
<beach> nij-: Thanks!
<nij-> Does the wscl team plan to document the differences between wscl and other specs?
<beach> nij-: Already done.
<beach> nij-: Let me see if I can find some versions of it...
<nij-> I can see so far many suggestions have been made.
<beach> I can't find it now, but scymtym has an HTML version of the dpANS where WSCL issues are indicated so that when the pointer is hovered above the text, you get to see the issue.
<nij-> When does it plan to be released?!?! (the time when clhs will be "freed")
<beach> There is no planned release date.
<nij-> And do you still want to use a doc system in CL?
<nij-> I see. What's the main crux now for releasing?
<nij-> What are the major undone works?
<beach> Each issue has to be examined. Behavior of existing implementations must be documented. Then, experienced Common Lisp programmers should discuss each issue and ultimately vote on it.
retropikzel has joined #commonlisp
<beach> pjb and jcowan have already started doing this with many issues.
<nij-> I remember that tex macros were in your way before. Is that solved?!
<beach> nij-: It doesn't have to be complete for it to be released. It would be in several steps. So we can just stop at some point and declare WSCL version 1 as frozen.
<nij-> <3 <3 <3 2021
<beach> nij-: Yes, scymtym now parses the entire dpANS specification, which is what allowed us to finally start the WSCL effort.
<phoe> ultraspec done right
<beach> nij-: The thing is that you won't notice the difference. Your implementation is very likely already WSCL conforming, or nearly so.
<nij-> macros issues have been solved?
<nij-> phoe: <3 <3
<nij-> beach: I'm sure I won't notice XD I just hope that the old Bible can be smoothly transitioned into a new one.
<nij-> The legacy must be well preserved!
victor has joined #commonlisp
victor has quit [Changing host]
<Shinmera> Anyone here using Parachute and GitHub actions?
<lisp123> To me this is bad style, what do you guys think? (The outer let can be replaced by default values or a conditional statement in the return form)
<phoe> I'd LOOPify the whole thing, but that's me
<beach> lisp123: What is the return value of PROCESS-WAIT?
<beach> lisp123: Apparently, it can be a function, so it is not a Boolean value. Therefor using that return value with OR or WHEN is a violation of the rule stated on page 13 of the LUV slides.
<nij-> I'd use when for if, and setf for setq. But that's just me (noob). THrowing my ideas out to be flamed and learn something ;)
<beach> And, yes, an IF with only a `when' branch is suspect.
<beach> Er, with only a `then' branch, I mean.
<beach> So either the value is used, and there should be an explicit `else' branch, or the value is not used, and the IF should be turned into a WHEN.
<beach> lisp123: And what is TRUE?
selwyn has joined #commonlisp
<beach> As in (let (... (value-1 true)) ...).
<nij-> true seems to be a global variable @@?
<nij-> should be named +true+ or *true* at least
<beach> I see no reason for its existence at all.
<beach> lisp123: Where did you find this?
amb007 has quit [Read error: Connection reset by peer]
<nij-> Is there a better logical operator XYZ that does (or (not A) B) == (XYZ A B)?
amb007 has joined #commonlisp
<nij-> Or rather, what's the proper name for such XYZ?
amb007 has quit [Read error: Connection reset by peer]
z147 has quit [Quit: z147]
<phoe> you want side effects only, or a meaningful return value?
<lisp123> beach: On Lisp, page 280
<phoe> because this looks like UNLESS
<lisp123> I'm just reading the comments above now
<beach> lisp123: As we have said before, the style of Paul Graham should not be used as a model for good style.
<nij-> oh i see yes it's unless
amb007 has joined #commonlisp
<nij-> beach: who to turn to then?
<nij-> I was trying to understand continuation.. but gave up with his presentation.
<beach> nij-: As I recall, PCL is much better.
<nij-> I plan to use a cl implementation for continuation and learn from there..
<lisp123> beach: but that's cant be a blanket statement right :) there's always pros & cons to each style
<nij-> But On Lisp covers more in depth topic than pcl..?
<beach> lisp123: I don't see that. Style is mainly about following conventions.
<beach> lisp123: Which one did you take to be a "blanket statement"?
<lisp123> "the style of Paul Graham should not be used as a model for good style"
<beach> nij-: I didn't say you should avoid the book. Just compensate for the often not conventional style being used.
<nij-> I see!
<phoe> he does a lot of interesting stuff in On Lisp that quirks brows nowadays - at least around here
<beach> lisp123: Right. But as phoe says, there are some recurring quirks that should be avoided. For one thing, he doesn't use generic functions or standard classes.
<nij-> He also had some rants about CL.. which is a question that I dare not bring up here.
<nij-> I wish I dare.
<nij-> OK I will do that now -
kakuhen has quit [Quit: Leaving...]
<lisp123> beach: fair enough
<phoe> nij-: well, pg in his book ANSI CL said that CLOS is too heavy and not really all that useful
<phoe> and that statement did not age well
<mfiano> Ha
<phoe> that's the most extreme example I can find
<phoe> s/find/remember off the top of my head/
<beach> phoe: It sounds like he is a victim of the "Blub paradox".
<mfiano> That is much more extreme than the opinions found in Let Over Lambda
<phoe> beach: xD
<lisp123> nij-: but he wrote two of the best books (not the best, but in the collection of books that can be deemed best), so I think he can be regarded as a supporter, regardless of any other comments he might have made :)
<nij-> http://www.paulgraham.com/popular.html :: PG in this essay rants about CL and how the older lisps are better. Given his devoted writings into CL, I am very curious why those rants.. like really what did (does) CL lack of?
<phoe> lisp123: sure, the books are pretty valuable and useful
<phoe> just don't take them as holy scriptures
<phoe> ;; mostly because the position of holy scriptures is reserved by the CL standard :D
<nij-> lisp123 i think so too
<lisp123> beacH: do you have a link to the LUV slides?
<beach> Thanks mfiano.
<lisp123> phoe: and I heard a new testatement is being done (WISL if I spelled it correctly) for those holy scriptues :D
<phoe> WSCL
<phoe> and it's more like an errata than a new testament
<mfiano> We just need the one true new testament
<mfiano> We can call it monocl
<phoe> every WSCL implementation is a CL, which can't be said about every christianity being a judaism
<phoe> mfiano: okay that was a terrible pun
<mfiano> :/
<beach> I like the name.
<phoe> I like it too
<lisp123> yeah it sounds nice off the tongue
<nij-> x'D
<phoe> but I do not like the fact that I like it
<beach> Heh.
<nij-> me either
<beach> Anyway, all these religious references made me want to take a long-ish break.
<nij-> but I do like the fact that I don not the fact that I like it
<shka> my understanding is that WSCL is just maintenance revision of the standard
<phoe> yes, I am sorry for those
* phoe goes back to doing LaTeX
<nij-> poor phoe
waleee has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
<lisp123> beach: I am curious on why OR / AND should be boolean only, if I read that correctly. Isn't (or A B), better than (if A A (if B B))? As it avoids double evaluation
scymtym has joined #commonlisp
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
<phoe> AFAIU it's more about NOT than it is about OR
<lisp123> Ah okay
pillton has quit [Quit: ERC (IRC client for Emacs 27.2)]
<nij-> Yeah I don't understand that (not (..) (..)) either.
<mfiano> That's unary?
amb007 has quit [Ping timeout: 258 seconds]
amb007 has joined #commonlisp
<phoe> NOT is unary, so (not (...) (...)) is invalid CL
<mfiano> That's what I meant
<phoe> OK
<mfiano> Also bear in mind, the LUV slides style suggestions are pretty old and a lot are out of use.
<lisp123> lol...well the funny part is that was a typo in my transcription
<lisp123> *ducks & runs*
<nij-> Do you mean (or (not A) B)?
<lisp123> yeah that's what it is
<nij-> "unless"?
<lisp123> I just had a typo
<lisp123> unless definitely sounds better there
<mfiano> IIRC it even recommends choosing either "?" and "!", over "-p" and "n" if it will improve consistency.
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
<mfiano> Which is funny, because doing so makes your code inconsistent with standard predicates
<mfiano> (or potentially destructive variants)
<nij-> wait.. unless seems to be different
<nij-> logic is hard
<lisp123> very :)
<mfiano> Boolean logic is simple but requires care to do anything non-trivial, and lots of unit tests :)
<mfiano> Just ask phoe. Can't remember how many times I asked him to verify my boolean logic
peterhil has quit [Ping timeout: 258 seconds]
<mfiano> It happens to the best of us (not that I'm the best at anything)
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
<nij-> I see.. at least using the truth table, (or (not A) B) is (imply A B) ;; https://en.wikipedia.org/wiki/IMPLY_gate
<nij-> Which is weird..
<phoe> why weird
random-nick has joined #commonlisp
bpanthi977 has joined #commonlisp
tfeb has joined #commonlisp
tyson2 has joined #commonlisp
tfeb has quit [Quit: died]
<jackdaniel> nij-: all boolean logic operators may be expressed in a form of some combination of 'or' and 'not'
<phoe> ;; no, it's 'or' and 'nand'
<phoe> ;; actually 'or' and 'and'
<phoe> ;; ...wait, no, I cannot into logic today
<sm2n> or and not also works
<jackdaniel> 'or' and 'not' are sufficient
<jackdaniel> nand gates are just more convenient
<jackdaniel> i.e (not (and a b)) -> (not (not (or (not a) (not b)))) -> (or (not a) (not b))
<sm2n> well, even easier is that both nand gates and nor gates are individually sufficient, and making nor from not and or is trivial
<sm2n> nij-, if you find that odd you should study some propositional logic, it's more useful than you'd think
<jackdaniel> right you are
<pjb> phoe: (nand a b) = (or (not a) (not b)) = (not (and (a b)))
<pjb> and the thing with NAND, is that they have 1 less transistor than AND.
<pjb> But you can also just use diodes…
Guest40 has joined #commonlisp
Bike has joined #commonlisp
<nij-> jackdaniel: phoe every thing there can be expressed with NAND xD
<nij-> sm2n: oh yeah you just said that
<nij-> it's fun
<nij-> I wonder how non-conventional logic can bring to the humanity
<nij-> s/how/what
rgherdt_ has quit [Ping timeout: 250 seconds]
<jackdaniel> fuzzy logic gives more flexibility where you have more variables (in a decision making process); also it allows you to represent uncertainity
<jackdaniel> these things already have uses in technology
<jackdaniel> neural networks are also kind of gates with somewhat even less comprehensible logic behind them
makomo_ has quit [Ping timeout: 276 seconds]
<hayley> nij-: Perhaps implement Hegel's logic in CL?
Guest40 has quit [Quit: Client closed]
<beach> lisp123: It is not about semantics. It's about using a value that is not a Boolean, and instead is either an interesting object, or a default value (which happens to be NIL) as argument to an operator that takes Boolean values.
aeth has quit [Ping timeout: 272 seconds]
aeth has joined #commonlisp
peterhil has joined #commonlisp
<pjb> nij-: well, humanity uses non-conventional logic, every day.
<pjb> nij-: if we only used logic, we couldn't make any generalization…
aeth has quit [Ping timeout: 258 seconds]
PinealGlandOptic has quit [Quit: leaving]
aeth has joined #commonlisp
makomo_ has joined #commonlisp
yitzi has joined #commonlisp
john-a-carroll has joined #commonlisp
hendursa1 has quit [Quit: hendursa1]
Wairu_Goodman has quit [Ping timeout: 258 seconds]
hendursaga has joined #commonlisp
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
hendursa1 has joined #commonlisp
rgherdt_ has joined #commonlisp
hendursaga has quit [Ping timeout: 244 seconds]
<nij-> Guy Steele gave a talk back in 2010 with a main message that programming language should take care of parallelism itself; programmers shouldn't worry that.
<lisp123> beach: Thanks. However, I thought it was an accepted paradigm to use logical operators as control structures and not just for boolean. Per CLTL: Common Lisp provides three operators on Boolean values: and, or, and not. Of these, and and or are also control structures because their arguments are evaluated conditionally. The function not necessarily examines its single argument, and so is a simple function.
<nij-> I think it would be nice if SBCL can achieve that. Imagine having SBCLs on multiple nodes in a network, handling the parallelism themselves.
<nij-> The question now is that - is it possible?
<lisp123> So I thin Norvig's suggestion to use and, or only for boolean values seems a bit heavy handed in that context
<phoe> nij-: swank-crew maybe
<nij-> O_O my eyes wide opened. Thanks phoe
<beach> lisp123: Sure, but that's not the point. The fact that an expression always yields a Boolean value is an issue that is orthogonal with the time it is evaluated.
nature has joined #commonlisp
<shka> nij-: bolting DSL for distributed programming is possible, but non-trivial
<beach> lisp123: Here is an example of the distinction...
<beach> lisp123: Suppose you have an operator like FIND-CLASS.
<beach> lisp123: It can either return a class object, or a default value when there is no class with the name you supply. That default value happens to be NIL.
<beach> lisp123: But FIND-CLASS is not returning a Boolean value.
<nij-> phoe: Do you know the internal of swant-client? Like how it works?
<nij-> I've asked multiple times here if there's a way to serialize functions well, and the answer was always negative.
<lisp123> beach: And in this case we don't want to associated the default object with false?
<nij-> In this case, how can multiple lisp repls work together?
<beach> lisp123: So, if you do (let ((potential-class (find-class ...))) (when potential-class ...)) you are using a non-Boolean in a position where a Boolean should be used.
<beach> lisp123: The good way of doing that is (unless (null potential-class) ...)
<lisp123> I see. Because I always do the former on the basis that any value not nil is T
<beach> lisp123: Because then NULL is the operator that tests whether the default value was returned, and NULL returns a Boolean, which can then be used in the UNLESS form.
<beach> lisp123: I am not talking about what you always do. I am talking about the expectations that the person reading your code might have, as discussed by Pitman and Norvig on page 13 of the LUV slides.
<phoe> nij-: swank-client?
<lisp123> But I can see how the second version is a bit more explicit. My bigger question is (or A B) --> If you have to separate the the test for boolean from the evaluation, doesn't that mean you have to evaluate twice?
<phoe> it's a client for swank, nothing surprising there
<beach> lisp123: When I see (WHEN POTENTIAL-CLASS ...) I have to stop and mentally turn it into the other variant before I understand it and that slows me down.
<phoe> where swank here means swank-the-network-protocol that swank-the-server uses
<nij-> Yeah. I understand the difference of slime, swank, swank-client, and swank-crew.
<nij-> Hmm
<beach> lisp123: You would not evaluate twice obviously.
<nij-> So the code itself still have to make sure that the global state of one repl isn't used.
<phoe> nij-: what do you mean, global state of one repl
<phoe> if some code refers to a REPL for its global state then something is seriously broken
rgherdt__ has joined #commonlisp
<beach> lisp123: There is always a configuration with IFs, WHENs, UNLESSes, etc, that will do the same thing semantically, and evaluate just once.
<nij-> don't we usually use package-name:*global-default*?
<lisp123> beach: Oh, so if I do (if A A (print "else")), A is only evaluated once?
<nij-> Ah! I now see why people want purely functional code more nowadays..
<nij-> It's exactly because repls and repls cannot really understand each other (serialization failure)
<beach> lisp123: No, but (let ((a A)) (if a a (print "else")) ) works.
<lisp123> but then you are adding some minor overhead no? since its creating an additional frame?
<nij-> phoe: CLOS is huge in CL and can not be easily made purely functional iiuc..
<nij-> How would we take care of that fact then?
<nij-> Most of the time, CLOS info can be serialized.. but not always.
<beach> lisp123: Absolutely not. You need to know how a compiler works.
<beach> lisp123: Only a very naive compiler would create a frame for the LET.
<lisp123> fair enough, I guess it gets optimised out
<mfiano> likely register allocated
<beach> lisp123: And what do you think the expansion of (OR (F X) (G Y)) is?
rgherdt_ has quit [Ping timeout: 240 seconds]
<phoe> nij-: uhhh, wait a second
<lisp123> touche
<phoe> what do you mean
<phoe> you seem to be touching the topic of network communication, which requires serialization and deserialization
<nij-> Yes
<phoe> it's hard to have a distributed object system that spans network boundaries, but hayley has been working on one
<nij-> To achieve parallel programming, we either need perfect serialization or pure functions, no?
<phoe> "perfect" serialization isn't hard
<nij-> ??!
<phoe> it's just cumbersome at times
<beach> lisp123: This discussion reminds me of the reason I introduced a compiler course in the undergraduate program. Programmers need to know what compilers are capable of, or they will make their code worse according to an incorrect model of how things work.
<nij-> How do you serialize a closure?
silasfox has joined #commonlisp
<nij-> perfectly
<phoe> you don't, you send the other computer a unique token that allows the other computers to refer to it
<phoe> and then, when you receive that token back, then you can e.g. funcall that closure and return the result back
<phoe> I remember we talked about that some time ago
<hayley> phoe: You won't get a speedup from Netfarm. And the type system is mediocre.
<phoe> you cannot send e.g. device access around
<phoe> hayley: in this case it's less about speedup and more about possibility
<phoe> since we're talking Lisp farms now
<hayley> Usually when I write parallel code, it still uses shared memory (i.e. we run everything on the same process). If you only have one fast computer, you aren't making a mistake to assume shared memory in my opinion.
<beach> lisp123: For example, in C my students would avoid introducing a local variable inside a `for' loop, because "then the variable had to be created in each iteration", so they increased the scope instead, making the code harder to understand.
nij- has quit [Ping timeout: 258 seconds]
<lisp123> beach: its a valid point - i agree with you
<hayley> On the other hand, I get a sort of happy middle ground between shared memory and isolation, wherein I can run a lot of threads on a machine with one database, then I can just add more machines and partition the work. Such a paradigm (if you can call it that) could be useful.
aleamb has joined #commonlisp
<hayley> If one, say, wrote a very parallel chess AI program, it could be useful to have a cache for intermediate values (which tend to be for eliminating redundant evaluations of the same board) on each machine.
<beach> lisp123: Good. And that's why every serious programmer should know how a modern compiler works.
<hayley> phoe: Okay. I just don't like to see it brought up, because the programming style is still strange in a way. It isn't at all like programming a serial or non-replicated program.
<lisp123> beach: I have started getting into that a bit. I didn't draw the connection that or macroexpands to an IF and also that a LET would be optimised (even though I read parts of that - I think it was SICP?), takes a few tries to make all the connections
nij- has joined #commonlisp
<nij-> (Lost of connection. Back.)
<hayley> Also, I am still not really working on it. So I'd prefer not to let anyone down with that information.
<nij-> Is your project a secret, hayley ?
<beach> lisp123: But as I recall, you have been programming for quite some time, in other languages, right?
<nij-> phoe: I see that you can use unique tokens.. hmm but that also means that in a network of nodes, there should still be one MASTER?
<hayley> No, this project is not a secret. I am just not motivated to work on it at all.
<nij-> oh..
<phoe> nij-: no, not really
<phoe> look up at content-addressable networks
<nij-> phoe: also, is there any implementation for cl that makes it work?
<phoe> you can use e.g. a UUID that can be generated without a master key
<nij-> ! lemme see
<phoe> nij-: makes *what* work
<lisp123> beach: No that was someone else perhaps - I have been programming for some time but _without_ any formal training, all from google :D
peterhil has quit [Ping timeout: 240 seconds]
<beach> lisp123: I wasn't referring to formal training. Just that there are programmers out there who make a living of it, but who do not know how compilers work.
<hayley> The token system is for representing a closure on another process, right?
<nij-> phoe: *what* - it allows me to dispatch the work to another lisp repl
<hayley> So I assume that the token would only correspond to anything for that process. It is not really a "master" process, as ...
<phoe> nij-: it's called swank-crew and it runs on other implementations
<phoe> there's also erlangen that is CCL-specific
<beach> Plus, I also have colleagues who were against introducing a compiler course, because "these students are never going to write a compiler anyway".
<hayley> Why are we talking about using another Lisp REPL?
<nij-> beach: sigh
<phoe> also what hayley said, REPLs are not really happening there
<lisp123> beach: I'm sure there are and its an increasing amount - after all, so much is just an electron app now. And now there are pushes for 'no code' solutions & GitHub Pilot.
silasfox has quit [Quit: WeeChat 3.2]
<nij-> hayley: I hope that a network of lisp repl can all work together toward some goal easily.
<nij-> I will look into swank-crew and how to use it then. Thanks phoe !
<nij-> ?
silasfox has joined #commonlisp
<lisp123> beach: well good you are doign it :) I'm sure your students will be very grateful to have that knowledge for the rest of their careers
<hayley> As I understand it (note: I absolutely don't) you just want to run tasks in parallel. So you don't need another REPL, just some threads or something.
<phoe> nij-: it seems that you want s/repl/process/
<phoe> you can have ten REPLs running inside a single process, and you can have ten processes all running without a single REPL.
<hayley> nij-: If they were all REPLs, then you'd have to type in the goal into each. With my 12 thread machine that would get boring quickly :)
<hayley> Also, do you have more than one machine you want to give work to? If not, you don't need to serialize anything.
<nij-> I'm not sure. Just thinking about the possibility ..
<nij-> phoe: By process you mean a lisp process?
<phoe> yes
<phoe> a standalone, executing lisp image
<hayley> With only one machine, it is perfectly fine to use mere threads, which share an address space, and thus you can literally just give a thread the object in question.
<nij-> I see, phoe, and one working implementation is swank-crew right? I will look into it :)
<hayley> If the work is trivial to parallelize, then I would look into lparallel and toy with PMAP, PREDUCE, PREMOVE-IF-NOT, etc. If not, then you might want to brush up on parallelism before anything.
<nij-> Back to compiler. beach, do you recommend noobs like me to start with understanding how C codes are compiled into assembly? Or can I just try to understand how it's done for CL? I have much more patient for CL than for C.
<hayley> Maybe I should write another chess AI some day. My first and last one nearly worked, but I messed up the negamax thing and it ended up playing the worst move half the time.
<nij-> hayley: thanks for the keywords too!
<lisp123> hayley: Are you working on rule based AI?
srhm has joined #commonlisp
taiju has quit [Ping timeout: 258 seconds]
<phoe> nij-: yes, swank-crew builds over swank-client which is an implementation of swank protocol in CL.
<hayley> lisp123: No, a chess program does state space search.
<lisp123> hayley: Nice!
<hayley> But I haven't written one for years.
<beach> nij-: OK, there are (at least) two aspects to a compiler. One is translating the source language to intermediate form. The other is optimizing the intermediate form.
<beach> nij-: The first part is specific for each language of course.
<phoe> and for this particular issue you're more interested in the second aspect
<hayley> Seriously, I remember messing with threading in...2018 while I was waiting for a meeting to pick classes for my final year at high school.
<beach> nij-: You can do that for Common Lisp if you want, there are several ways.
<beach> nij-: And, as phoe points out, for the points about OR and LET, the second part is more interesting.
<phoe> stuff like narrowing variable lifetimes, figuring out constants, eliminating dead code, etc..
<beach> nij-: And then the source language doesn't matter much.
<phoe> a good thing is that this is mostly language-indepe--exactly what beach said
<beach> nij-: I recommend Steven Muchnick's book for that.
<beach> nij-: That book is a good overview of techniques, and the general descriptions are good. But if you ever want to write a compiler, whatever you do, don't base it on his code.
<shka> beach: that bad or just overly complicated?
<nij-> The intermediate lang is almost universal?
<shka> or just overly simplistic
<beach> shka: Very bad. The man wrote a compiler, but he doesn't know about pointers.
<beach> shka: It is as if he wrote the compiler in Fortran.
<shka> that is... interesting
<Josh_2> casual 800+ pages
<beach> nij-: All books assume a simple source language like C without closures and stuff, so languages like Common Lisp complicate stuff, but you still get the general idea from his book.
<shka> moment
<hayley> nij-: I think that the parts an application programmer needs to know about are relatively language independent, at least if you have a reasonable language. Otherwise hell no.
<shka> old version of fortran lacked what compiler people call "pointer aliasing" right?
<beach> nij-: I second what hayley says.
<nij-> You mean the ~900-page book 😂😂😂?
<shka> could this is be why code uses pointers in weird fashion?
<beach> shka: I am talking about his data structures. They are all arrays indexed by integers.
cosimone has joined #commonlisp
<beach> shka: Exactly the way you would write a compiler if all you know is Fortran.
taiju has joined #commonlisp
<Josh_2> nij-: fortunately its mostly code
<shka> it honestly astonish me that anybody would try to teach anything non-numeric with Fortran of all things
<hayley> Well, to some extent, you do also have different intermediate languages and representations (words you don't need to care about: SSA, CPS, ANF, basic blocks, sea of nodes...) but I guess the optimisations are invariant still.
<shka> but ok, i guess
silasfox has quit [Ping timeout: 276 seconds]
<beach> hayley: Yes, I agree.
silasfox has joined #commonlisp
<shka> the book was first published in the 1997?!?!?!?!
<shka> and Fortran?
<_death> the fortran style has its own advantages sometimes, though in Lisp we tend to use (maybe overuse) the pointers approach a lot.. you can read about it in http://www.the-adam.com/adam/rantrave/st02.pdf
<hayley> nij-: I would guess a book would not cover the specific IR of some real compiler, so you are welcome to imagine your own IR to think about optimisations with.
<beach> shka: The man just doesn't know how to program.
john-a-carroll has quit [Quit: Connection closed]
<shka> beach: i would not dare say such thing, i mean he somehow became very well acquainted with compilers
<shka> but this is just so weird
<beach> Very strange indeed.
<beach> But then, I hear there are people using languages such as C++ to write compiler frameworks such as LLVM. That's weird too.
john-a-carroll has joined #commonlisp
<shka> yeah, C++ is not the best choice, but again given the selection of the mainstream languages and corporate politics it is understandable
<shka> you wanna automatic management? C# or java, both of which are very much connected to MS and Oracle respectively.
<shka> and neither is exactly a "stable standard"
<beach> Like I often say, people go to a lot of trouble, and waste a lot of time and energy, to avoid learning Common Lisp.
<shka> true
<Josh_2> very true
<hayley> According to Wikipedia, LLVM originated as a project to investigate dynamic compilation techniques. With the exception of KleinVM for Self, I don't think there were any "just in time" compilers not written in C++ at the time.
<shka> hayley: i don't think that "exists only in C++" is a valid excuse
<pl> I think Python would count too, even if arguably it uses older logical framework than LLVM
<hayley> Ironically now it seems LLVM is too slow to use for a JIT, with the exception of optimizing the hottest loops.
peterhil has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
<hayley> shka: What I mean is that metacircular dynamic compilers were mostly non existent. But as pl said, Python the compiler did exist then.
amb007 has joined #commonlisp
<beach> hayley: I have been wondering whether the slowness of LLVM is due to this phenomenon that I often cite, namely that it is impossible to write a C++ program that is both fast and modular.
<scymtym> beach: Aaron Hsu's thesis has a more well-founded position on avoiding pointers in compilers than "only knowing fortran": https://scholarworks.iu.edu/dspace/handle/2022/24749 . i'm not sure whether it contains his statement about pointers being "the refined sugar of programming", though
<beach> I mean, I can't imagine that the LLVM people attempted to write a monolithic program of that size.
<beach> scymtym: I see, yes. I don't think that's what Muchnick is up to though.
<beach> hayley: But I haven't studied the LLVM code to see whether they make heavy use of things like smart pointers and/or reference counting.
<scymtym> beach: very likely true. i was pointing out (ha) other possible reasons for wanting to avoid pointers
<beach> scymtym: Yes, thank you!
<beach> ... smart pointers, reference counting, or perhaps just a lot of copying to keep the reference count to 1 or 0.
bpanthi977 has quit [Remote host closed the connection]
<beach> Either "technique" could explain a lot of slowness.
peterhil has quit [Ping timeout: 250 seconds]
<hayley> I don't know what the LLVM developers do, but I watched a presentation on the Java C2 compiler, in which Cliff said he did a lot of hash consing in order to keep everything in cache.
tyson2 has joined #commonlisp
<shka> compilers are that cache performance sensitive?
<hayley> And in the context of a compiler, you could be slack and use an arena allocator, assuming no IR or other temporary data outlives compilation.
nij- has quit [Quit: Using Circe, the loveliest of all IRC clients]
<hayley> shka: Apparently so. But I suppose going slow hurts more in a JIT compiler.
<shka> i would never thing so
<shka> *think
peterhil has joined #commonlisp
<beach> Didn't GCC used to use obstack and then switched to Boehm or something like that?
<hayley> I believe so.
tyson2 has quit [Remote host closed the connection]
peterhil has quit [Ping timeout: 240 seconds]
<hayley> C2 apparently uses an arena allocator, and so does the frontend of Clang.
<beach> But that gives more responsibility to the programmer to determine liveness.
<hayley> So garbage collection could be somewhat better on the cache, provided that there are temporary objects which die.
<beach> So it's an unwanted source of the same kinds of bugs that manual memory management has. Right?
<hayley> But if the compiler doesn't run for long, and nothing outlives compilation, the programmer can be lazy and remove the arena at the end of compilation.
peterhil has joined #commonlisp
<beach> Maybe so.
<hayley> Still, you could achieve much better locality of reference if there is any garbage produced. And for sufficiently large compilation units, the memory usage would become a problem, so I doubt that LLVM solely uses arenas.
bpanthi977 has joined #commonlisp
<beach> Sounds right.
* hayley imagines this isn't far off how an explicit memory management fan would talk about a program with a GC.
<shka> maybe allocates multiple chunks
<hayley> Maybe, but any chunks would only be provably dead when compilation finishes.
<shka> hmmm
<hayley> If there were cleanly separated passes, you could have separate allocators for each pass.
<shka> yeah, wanna suggested that
<hayley> Still, I expect there to be some other memory management technique.
<shka> *yeah, i wanted suggest that
<shka> honestly, memory management is not all that interesting :/
<shka> it is like tetris
hendursa1 has quit [Quit: hendursa1]
<shka> for programmers
hendursaga has joined #commonlisp
hendursaga has quit [Client Quit]
<hayley> It's boring stuff that makes the rest of my life boring. 10/10 would study again
<beach> I am always in favor of general-purpose techniques rather than special-purpose ones. So it seems to me work should be put into a good tracing GC.
hendursaga has joined #commonlisp
<hayley> shka: w.r.t the cache, I think the example of hash consing was for type inference. As that compiler also does something like Kildall's algorithm, it also makes a fair few intermediate types, and getting that done with quickly would be good.
john-a-carroll has quit [Quit: Ping timeout (120 seconds)]
cage has joined #commonlisp
nij- has joined #commonlisp
<nij-> Ah - the link to the internal manual for sbcl in this site is down - http://www.sbcl.org/manual/#Internals-Documentation
<nij-> Does anyone have a copy of the internal manual?
<nij-> Btw, as wscl is going on - can we expect a program that checks if an implementation satisfies spec wscl?
tfeb has joined #commonlisp
<beach> Augmenting the ANSI test suite would be a good thing.
tfeb has quit [Client Quit]
copec has joined #commonlisp
silasfox has quit [Ping timeout: 258 seconds]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
nature has quit [Ping timeout: 272 seconds]
lisp123 has quit [Quit: Leaving...]
cosimone has quit [Remote host closed the connection]
makomo_ has quit [Quit: WeeChat 3.0.1]
makomo has joined #commonlisp
ramHero has joined #commonlisp
ski has joined #commonlisp
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
z3t05 has joined #commonlisp
z3t0 has quit [Ping timeout: 240 seconds]
z3t05 is now known as z3t0
ramHero has quit [Quit: Bye]
santiagopim has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
peterhil has quit [Ping timeout: 258 seconds]
amb007 has joined #commonlisp
asarch has joined #commonlisp
peterhil has joined #commonlisp
retropikzel has quit [Ping timeout: 245 seconds]
lad has quit [Remote host closed the connection]
sonnaz has joined #commonlisp
santiagopim has quit [Quit: Bye]
retropikzel has joined #commonlisp
sonnaz has quit [Remote host closed the connection]
santiago` has joined #commonlisp
santiago` has quit [Client Quit]
santiagopim has joined #commonlisp
bpanthi977 has quit [Quit: bpanthi977]
santiagopim is now known as santiagopim_
attila_lendvai has joined #commonlisp
santiagopim_ is now known as santiagopim
sonnaz has joined #commonlisp
sonnaz has quit [Remote host closed the connection]
peterhil has quit [Ping timeout: 258 seconds]
sonnaz has joined #commonlisp
sonnaz is now known as Guest8263
Guest8263 has quit [Remote host closed the connection]
peterhil has joined #commonlisp
dsz has joined #commonlisp
dsz is now known as sonnaz
sonnaz is now known as dsz
dsz has left #commonlisp [#commonlisp]
zos has joined #commonlisp
OlCe` has quit [Quit: ERC (IRC client for Emacs 27.1)]
OlCe has joined #commonlisp
peterhil has quit [Ping timeout: 252 seconds]
yitzi has quit [Quit: Leaving]
tfeb has joined #commonlisp
trufas has quit [Ping timeout: 252 seconds]
trufas has joined #commonlisp
tfeb has quit [Quit: died]
ec has joined #commonlisp
vats has joined #commonlisp
vats has quit [Client Quit]
vats has joined #commonlisp
vats has quit [Client Quit]
cosimone has joined #commonlisp
gaqwas has joined #commonlisp
rain3 has quit [Ping timeout: 258 seconds]
vats has joined #commonlisp
cosimone has quit [Remote host closed the connection]
copec has quit [Remote host closed the connection]
copec has joined #commonlisp
<mfiano> 99999999999999999999999999999999999999999999999999999-098iu77777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<moon-child> 7?
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 7777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777
<mfiano> 77777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777788888888888888888888888888888888788888888888666666666666666666666666666666666666
<lotuseater> oh hm something went wrong :)
kevingal has quit [Remote host closed the connection]
<_death> I expect the culprit has paws
ec has quit [Ping timeout: 244 seconds]
vats has quit [Remote host closed the connection]
vats has joined #commonlisp
vats has quit [Remote host closed the connection]
vats has joined #commonlisp
vats has quit [Remote host closed the connection]
vats has joined #commonlisp
vats has quit [Remote host closed the connection]
vats has joined #commonlisp
ec has joined #commonlisp
<shka> i did this once because i was cleaning keyboard
<shka> and i forgot to unplug the thing
vats has quit [Remote host closed the connection]
<mfiano> Wow, sorry. Guess this keyboard is dead if it's doing things without me
vats has joined #commonlisp
lisp123 has joined #commonlisp
<edgar-rft> on the contrary: your keyboard is alive - it's taking over your computer now!
vats has quit [Remote host closed the connection]
vats has joined #commonlisp
vats has quit [Remote host closed the connection]
vats has joined #commonlisp
ec has quit [Ping timeout: 244 seconds]
ec has joined #commonlisp
<Josh_2> if I have a list with 100 different elements, each element has a slot whose value is a colour like orange, green, blue, is there a quick way I can sort them into individual lists by that colour?
<lisp123> Josh_2: So to understand correctly, you have a list, say (A B C D E F G), and you want to split it into (A B) (D F) (E) (G) where each of the sublists are of a certain color?
<Josh_2> yes, I can do this by looping, was just curious if there is a quick way to do this
<phoe> oh goodness
<phoe> that is a really big integer
<Josh_2> sometimes there are sneaky ways you can do this in CL without realizing, no point reinventing the wheel
<phoe> Josh_2: I remember that pjb had a utility for that
<Bike> you're describing a partition
<lisp123> http://www.lispworks.com/documentation/HyperSpec/Body/f_mem_m.htm - then use a lambda function to test for equality
<Bike> there's nothing for it in the standard, but some utility libraries have it, i'm sure
<lisp123> I'm sure you could use a mapping function also
<Bike> not alexandria though as far as i can tell
<phoe> serapeum:partition
<zephyr> i've also seen that called group-by
<phoe> sorry, serapeum:partitions
<phoe> (serapeum:partitions (list (lambda (x) (= 0 (mod x 3))) (lambda (x) (= 1 (mod x 3))) (lambda (x) (= 2 (mod x 3)))) '(1 2 3 4 5 6 7 8 9))
<phoe> ;=> ((3 6 9) (1 4 7) (2 5 8))
<Josh_2> hmm
<Bike> hm, well that's slightly more involved
<phoe> only because the predicates are there
<phoe> you can generate them on the fly via closing over your colors
<phoe> something that can turn '(:green :red :blue) into a list of lambdas that check if the color of an object is :green, :red, :blue
<pjb> phoe: (com.informatimago.common-lisp.cesarum.list:equivalence-classes '(1 2 3 4 5 6 7 8 9) :key (lambda (n) (mod n 3))) #| --> ((9 6 3) (8 5 2) (7 4 1)) |#
<Bike> sure, but maybe you don't know the colors to begin with
<phoe> pjb: exactly this
<phoe> thanks
<lisp123> Bike: (which is probably likely) - I guess then the trick would be to CDR through the list and push to a hash table for that color?
<Josh_2> the colours are unknown in this case
shka has quit [Read error: Connection reset by peer]
shka has joined #commonlisp
<lisp123> Josh_2: see above, loop through the items, and push each object onto a hash table with that color as a key (appending to the list for each color as you go on)
retropikzel has quit [Quit: Leaving]
<jcowan> That's when autovivification would be a great thing to have
<pjb> (defmacro generate-keyword-predicates (&rest keywords) `(progn ,@(mapcar (lambda (keyword) `(defun ,(intern (concatenate 'string (string keyword) "P")) (object) (eql object ',keyword))) keywords))) (macroexpand-1 '(generate-keyword-predicates :red :green :blue)) #| --> (progn (defun redp (object) (eql object ':red)) (defun greenp (object) (eql object ':green)) (defun bluep (object) (eql object ':blue))) ; t |#
<Bike> well there's a two dollar word
<pjb> Josh_2: if the colors are not known at compilation-time, then you don't want to generate functions for each of them.
<lisp123> Bike: yay, i'm beocmign smarter
<lisp123> guessed it right :D
<Bike> "the automatic creation of new arrays and hashes as required every time an undefined value is dereferenced" eck
<pjb> Josh_2: no code compiled can know what those function names would be if the color keywords are only known at run-time.
nij- has quit [Quit: Using Circe, the loveliest of all IRC clients]
selwyn has quit [Quit: Leaving]
<phoe> but you can close over them at runtime
<phoe> (mapcar (lambda (color) (lambda (x) (eq x color))) colors)
<phoe> this gives you a list of predicate objects that you can freely funcall
<Josh_2> got some more complicated answers than I expected
<Josh_2> heres my bad solution
<Josh_2> I can easily display this as a table in HTML
<Josh_2> Thanks for the suggestions :D
<zephyr> i'll throw in https://plaster.tymoon.eu/view/2586#2586, looks similar to other suggestions
z3t0 has quit [Read error: Connection reset by peer]
z3t0 has joined #commonlisp
<pjb> phoe: this is correct, but more often it will be enough to use (member x colors).
zos has quit [Quit: WeeChat 2.8]
<pjb> or (position x color)
<pjb> or (position x colors)
<phoe> oh right, sure
<pjb> (it'd be better to have some specifications).
ec has quit [Ping timeout: 244 seconds]
shka has quit [Ping timeout: 272 seconds]
scymtym has quit [Ping timeout: 250 seconds]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
pve has quit [Quit: leaving]
z3t0 has quit [Ping timeout: 250 seconds]
ec has joined #commonlisp
brettgilio has quit [Quit: The Lounge - https://thelounge.chat]
brettgilio has joined #commonlisp
scymtym has joined #commonlisp
ecraven has quit [Quit: quit]
ecraven has joined #commonlisp
ec has quit [Ping timeout: 244 seconds]
asarch has quit [Quit: Leaving]
lisp123 has quit [Remote host closed the connection]
lisp123_ has joined #commonlisp
<Bike> sm2n: i just loaded introspect-environment on sbcl 2.1.7 and don't see any errors. there is a compiler note but i am pretty sure it is harmless.
lisp123 has joined #commonlisp
lisp123_ has quit [Ping timeout: 256 seconds]
lisp123 has quit [Read error: Connection reset by peer]
ec has joined #commonlisp
santiagopim has quit [Ping timeout: 272 seconds]
gaqwas has quit [Ping timeout: 258 seconds]
lisp123 has joined #commonlisp
ec has quit [Ping timeout: 244 seconds]
pillton has joined #commonlisp
flip214 has quit [Ping timeout: 255 seconds]
taiju has quit [Ping timeout: 258 seconds]
kakuhen has joined #commonlisp
taiju has joined #commonlisp
ec has joined #commonlisp
lisp123 has quit [Ping timeout: 256 seconds]
akoana has joined #commonlisp
cjb has joined #commonlisp
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
attila_lendvai has quit [Ping timeout: 245 seconds]
froggey has quit [Ping timeout: 252 seconds]
froggey has joined #commonlisp
dsk has joined #commonlisp
ec has quit [Ping timeout: 244 seconds]
ec has joined #commonlisp
ec has quit [Quit: ec]
kakuhen_ has joined #commonlisp
random-nick has quit [Ping timeout: 258 seconds]
kakuhen has quit [Ping timeout: 258 seconds]
dsk has quit [Ping timeout: 258 seconds]
rgherdt__ has quit [Ping timeout: 258 seconds]
robin has quit [Ping timeout: 258 seconds]
Guest29 has joined #commonlisp