01:47 <whiteman809> is there common lisp social channel? i want ask you guys about your opinion about c++ compared to common lisp

01:47 <whiteman809> the nice thing in c++ is static typing but common lisp seems to have saner syntax for me

01:51 <aeth> #lispcafe

02:31 <beach> jackdaniel: Impressive.

04:06 <Pixel_Outlaw> I was fizzbuzzing with circular lists. Kind of fun idea. Probably not the /best/ way to do it. But modulus is pretty boring and direct. https://i.imgur.com/rLt3pMD.png

04:07 <Pixel_Outlaw> And now I see "items" is a bad parameter name. It should be "list". OOPS

05:37 <jackdaniel> thanks

05:54 <beach> I can't figure out the reason for the existence of METHOD-COMBINATION-ERROR and INVALID-METHOD-ERROR. If they were condition types, I could understand it, but functions? Maybe so that they can be traced?

05:58 <jackdaniel> isn't the crux covered in "Because an implementation may need to add additional contextual information to the error message (...)" ?

05:58 <jackdaniel> i.e the implementation constructs the condition and adds additional initargs that depend on dynamically bound /internal/ variables

05:58 <jackdaniel> (or at least it may do that)

05:59 <beach> Yes, I see. That would be a reason not to have them defined as condition types.

06:00 <beach> But I still don't see the utility of the functions.

06:00 <beach> Maybe it will come to me later.

06:04 <jackdaniel> perhaps you've already investigated that, but the long form of define-method-combination metnions that invalid-method-error may be used to "perform further filtering of methods in the body forms"

06:05 <beach> I did not investigate that. Thanks for pointing it out. I'll read up.

06:06 <jackdaniel> also, assuming that the processor of define-method-combination needs to do some cleanup in the handler above that depends on the dynamic context of the definition, then calling error would not be sufficient if you want to punt from inside your own method combination definition

06:09 <beach> I'll give that some thought. Not obvious to me (yet). Thanks again.

06:09 <jackdaniel> sure

06:13 <jackdaniel> and this remark may be a bit off, because I'm always forgetting method combination details, but if I recall correctly, there is involved implementation specific step to compile the effective method at runtime; so the signaled error may need to cross the RUNTIME <> COMPILE-EMF barrier, so you the implementation may chose to handle the appropriate condition at that boundary and resignal it outside of

06:13 <jackdaniel> the compilation context

06:14 <jackdaniel> s/you the/the/

06:18 <beach> Makes sense.

07:30 <Josh_2> Hi

07:58 <tfeb> beach: I have forgotten the details but I am reasonably certain that the CLOS *-error functions exist because the condition system did *not* reliably exist when CLOS was being designed, at least in the implementations they used. And then CLOS got dropped into the standard as a whole thing quite lat

07:58 <tfeb> e on. I can ask someone who was on the committee if I remember. Or KMP probably would know.

07:59 <beach> tfeb: Oh, that would make a lot of sense.

08:00 <beach> tfeb: Sure, if you know someone, that would be great! Thanks for the offer.

08:01 <tfeb> It does, but I could easily be misremembering: I was around but not involved.

08:01 <beach> I see. Interesting.

08:08 <tfeb> asked him, will come back if he replies

08:08 <beach> Thank you!

08:40 <beach> That theory explains the otherwise weird phrases in the specifications of both METHOD-COMBINATION-ERROR and INVALID-METHOD-ERROR: "Whether <mumble> returns to its caller or exits via THROW is implementation dependent" that I asked about the other day.

09:26 <jackdaniel> it would be nice if asdf/ccl could nicely follow symlinks