libera/#commonlisp - IRC Chatlog

1:56:43 mariari I wonder if nyxt can do anything with it

3:02:53 beach Good morning everyone!

3:46:16 etimmons beach: https://plaster.tymoon.eu/view/2554

3:46:28 etimmons That one is more interesting. Some non-type-errors in there

3:48:52 beach Thanks. Not yet sure what I am looking at. I haven't finished my morning coffee yet.

3:49:38 etimmons Tests for the aref-accessor-dimension-error issue on a bunch of implementations

3:50:01 beach That much I got. I need to study the format of the output.

3:50:44 etimmons ah. Sorry, my format foo is a bit weak so it's not as pretty as I wanted.

3:51:05 beach Mine is probably even weaker.

3:52:56 etimmons Long story short: each of those impls signals an error. But ccl and cmucl are just simple-error

3:54:22 beach I am slowly understanding it. Thank you very much!

5:17:31 mayuresh hello everybody. :)

5:21:29 beach Hello mayuresh.

5:35:29 susam Good morning, everyone!

5:35:39 susam Hello mayuresh! Hello beach!

5:35:40 mayuresh good morning susam. :)

5:35:46 beach Hello susam.

5:35:55 mayuresh susam, what time is it out there?

5:36:03 mayuresh out here it's 11:05.

5:36:25 beach etimmons: I am going to consult with scymtym with respect to the format of the particular section in the issues before I integrate your work.

5:36:47 mayuresh anyone has any idea why "clisp" has stagnated?

5:37:01 beach mayuresh: It happens.

5:37:03 mayuresh or is there only no public releases for a while now??

5:37:13 beach Lack of funding, people get busy with other stuff, etc.

5:37:21 mayuresh ah, okay.

5:37:30 beach I mean, those are just examples.

5:37:36 mayuresh how does clisp compare with sbcl?

5:37:49 beach Much slower, but more portable.

5:38:04 beach But recently, I have seen bhaible here, so maybe he is working on CLISP again.

5:38:25 mayuresh is bhaible, bruno?

5:38:40 beach I am assuming that, yes.

5:40:24 mayuresh cool. i think he's based out of germany (at last known point in time).

5:40:25 beach Also, since there has been less work on CLISP than on SBCL, it means SBCL is more close to being conforming.

5:40:54 mayuresh i am quite gung-ho about working under "clear linux" (clearlinux.org)

5:41:18 mayuresh and they requested a simple configure, make, make install like build process.

5:41:24 beach There was a lot of excitement generated when SBCL was forked from CMUCL and several very smart and very knowledgeable people worked on it for quite some time.

5:41:44 mayuresh so clisp is the only option i could recommend to the clear linux team.

5:42:01 beach mayuresh: Oh, but that's so oriented toward Unix static languages like C.

5:42:29 mayuresh beach: clear linux is highly optimised by intel for intel's processors.

5:42:39 beach Writing a Common Lisp implementation in C or C++ is unnecessarily difficult.

5:42:50 mayuresh beach: that's why they want natively configurable and buildable systems.

5:43:01 mayuresh hi treflip. :)

5:43:26 beach mayuresh: Don't greet people who do not speak please, or else there will be nothing but greetings in this channel.

5:43:28 mayuresh beach: clisp shows that building implementations in c/c++ is just okay.

5:44:00 beach mayuresh: CLISP shows that if you do it that way, you run the risk of ending up with a very slow resulting system.

5:44:02 treflip hi

5:44:03 moon-child mayuresh: abcl may be a better choice; it has a simple build process afaik, and is likely to have better compatibility

5:44:39 mayuresh beach: clisp was fast enough for paul graham to build his commercial portal.

5:44:44 moon-child and java is very popular; I assume they already package other java applications

5:45:39 beach mayuresh: Look, there are tons of people who aren't using Common Lisp because they think it is slow, and they think that because they think it is "interpreted". It is important that we have implementations that generate fast code so that we can point these people to those implementations.

5:45:51 beach mayuresh: If you can live with slow code, that's fine.

5:46:26 mayuresh beach: you are confused because you seem to be too involved in your own train of thoughts.

5:46:43 mayuresh beach: clisp has a compiler too.

5:46:58 beach I see. Thank you for pointing that out.

5:47:12 moon-child he has a point. If the point of clear linux is to have fast code (optimized for intel processors), then it's not a great look to package only one of the slowest cl implementations

5:47:15 mayuresh i don't know how to "pm", thanks for the note from mysterious. :)

5:47:19 moon-child (beach has a point, I mean)

5:48:00 mayuresh moon-child: you are missing the point, clisp might be interpreted, but it has a compiler too.

5:48:18 beach Common Lisp implementations that generate fast code (like SBCL) run just fine on Intel processors.

5:48:33 moon-child mayuresh: clisp does not generate highly performant code. Sbcl does

5:48:57 beach mayuresh: Nobody denies that CLISP has a compiler. We only mentioned the speed of the resulting code.

5:48:57 mayuresh beach: sbcl just can't have the optimisations that intel has introduced with native binaries under "clear linux".

5:49:26 susam mayuresh: You appear to be using ircII (the original or perhaps close-to-original IRC client). Wow! I believe /msg <nick> Hello should work but I don't know for sure. It has been a long time since I used ircII.

5:49:29 mayuresh beach: sbcl will always play catch-up with native code.

5:49:31 beach mayuresh: What is a "native binary"?

5:50:12 beach mayuresh: And what is "native code", if that is not what SBCL is generating?

5:50:39 mayuresh beach: a native binary in my terms is one which uses all the optimisations provided by a compiler build chain which is well supported by the processor's vendor.

5:50:48 mayuresh beach: in the case of clear linux it is intel.

5:51:00 beach Oh, so it's tied to a commercial company?

5:51:13 susam_ Joined via ircII just for nostalgia's sake

5:51:15 mayuresh beach: yes, but clear linux is fully open source.

5:51:34 susam_ Joined via ircII just for nostalgia's sake

5:51:39 mayuresh beach: and intel has a large team dedicated to working on gnu build tools.

5:51:45 susam_ Oops! Sorry for the spam.

5:52:09 mayuresh susam: it's okay, i love ircii. :)

5:52:44 mayuresh beach: intel's has a dedicated large team to improve the gnu toolchain for intel's processors.

5:53:15 mayuresh beach: in fact, intel brings out newer contributions to gnu toolchain in tandem with every release of their newer processors.

5:53:27 mayuresh beach: it's bloody marvellous. :)

5:53:56 beach mayuresh: I am indeed confused. You simultaneously claim that it is fine to have a Common Lisp implementation that generates slow code, because Graham got rich doing so, and you also claim that CLISP is the best alternative because it uses "native code". Yet, the code generated by CLISP is significantly slower than that generated by SBCL. Can you help me out here?

5:54:43 mayuresh beach: i looked around on google, and it seems clisp is working on improving their performance, just not making a loud noise.

5:55:01 beach I see, so it's an investment in the future.

5:55:16 mayuresh beach: paul graham chose clisp, only and only because it was faster than every other open source option when he worked on his commercial portal.

5:56:04 susam_ mayuresh: So checked again with this alternate nick. Both "/msg susam Hello" and "/query susam" work for private messages in ircII too.

5:56:48 beach mayuresh: I am looking forward to the day when CLISP is both more conforming and generates faster code than SBCL does.

5:57:01 mayuresh beach: same here. :)

5:57:15 mayuresh beach: and i think that day isn't far away. :)

5:57:22 beach Good to know.

5:57:47 mayuresh does anyone know if "rob warnock" hangs out around here?

5:58:26 susam Why the fondness for CLISP this morning? Why care about it when there is SBCL?

5:58:58 susam I like CLISP though for nostalgia reasons but these days SBCL is all I need.

5:59:03 beach susam: That was explained.

5:59:14 beach susam: Check the logs.

5:59:20 susam Okay. I have missed it then. Let me scroll up.

5:59:37 mayuresh susam: because it's difficult to build sbcl using automated systems without using a previous cl implementation.

5:59:45 beach susam: It is the only implementation that is good for "clear linux".

6:00:10 mayuresh susam and beach: and i'm really keen on working under clear linux. :)

6:00:25 beach mayuresh: Oh, but that's not the argument you gave before.

6:00:38 beach mayuresh: If that is the argument, you might consider our BOCL project.

6:00:40 mayuresh i tested it out and the performance under my machine is mind blowing.

6:00:52 mayuresh "bocl"?

6:01:24 susam Okay, that makes sense. I agree it is a good attribute to have.

6:01:31 beach Yes, Bootstrap Common Lisp. The idea is to have a slow Common Lisp implementation written in C, but the only purpose is to use it to build other Common Lisp implementations.

6:01:50 mayuresh beach: that's bloody brilliant.

6:02:02 mayuresh beach: i'll investigate this further.

6:02:11 mayuresh beach: thanks a million for that tip. :)

6:02:11 beach mayuresh: Then you can build everything using Make, but the main Common Lisp implementation is written in Common Lisp as it should be.

6:02:52 mayuresh beach: but still the main common lisp wouldn't have the optimizations provided by intel's team for the gnu toolchain, isn't it?

6:03:10 beach mayuresh: But, again, that's not the argument you first gave. That argument was that a Common Lisp compiler written in Common Lisp can never keep up with what Intel is doing, and BOCL won't fix that.

6:03:35 mayuresh beach: that's exactly what i have mentioned in the previous note.

6:03:46 susam As a thought experiment I wonder what it would take to build a usable computer from scratch. If hardware is given, I would probably write a Forth. Do away with the whole C-based computing infrastructure that is prevalent. If there is no hardware, then get Morris Mano's book, build a Mano CPU with NAND gates, then build a Forth.

6:04:06 mayuresh beach: intel's optimizations for the gnu toolchain would never get carried forward into sbcl, but will under clisp's interpreter.

6:04:21 beach mayuresh: I am not convinced that the GNU toolchain (and what Intel is doing) is good enough for a language that is so much more complex than C.

6:05:00 beach mayuresh: "interpreter"? I thought you said that CLISP used a compiler.

6:05:19 mayuresh beach: i think i'll take that up as an exercise in the future, to evaluate the difference between gnu toolchain built cl systems and sbcl-like systems.

6:05:29 beach mayuresh: Or are you saying that a bytecode interpreter can be faster than the native code generated by SBCL?

6:05:37 mayuresh beach: clisp is primarily interpreted, and also has a compiler.

6:05:51 beach But the compiler generates bytecodes, right?

6:06:10 beach Maybe it has a native compiler these days.

6:06:14 mayuresh beach: i think the clisp compiler outputs native binaries.

6:06:48 beach mayuresh: Oh, I mean when you type (defun ...) to the prompt. What kind of code is generated then.

6:06:59 beach mayuresh: I was not talking about the system build.

6:07:10 mayuresh beach: i am "pm"-ng you my email address, will you "pm" me yours?

6:07:30 beach I prefer to discuss things here.

6:07:44 mayuresh okay.

6:07:56 beach I think it is important for others to see and comment on the arguments.

6:07:58 mayuresh i just wanted to be in close touch regarding the evaluation.

6:08:42 beach So does CLISP generate native code when you type a DEFUN form at the top level? And if so, how does it take advantage of the GNU toolchain when it does that?

6:09:02 susam Yes, this is a good discussion. Keep the discussion here so that I and others curious about it can see it here. :)

6:09:29 jackdaniel clisp may generate native code with lightning jit, that said the compiler outputs a bytecode

6:09:39 beach Or, I guess, it would be good enough if COMPILE-FILE generates native code.

6:09:43 jackdaniel so clisp won't benefit from "highly optimized gnu toolchain"

6:09:49 mayuresh beach: they way i've understood it, clisp's interpreter is what gets optimised during the system build process, everything else is from within common lisp environment, so not the same optimisations might apply.

6:10:11 beach mayuresh: Oh, but that's very important.

6:10:11 jackdaniel ecl could partially benefit from it, because it compiles to c, and then the resulting c file is compiled with the c compiler

6:11:02 mayuresh hey, i'm a totally newbie to common lisp, yet i'm understanding most things pretty well.

6:11:14 mayuresh i'm in love with this group. :)

6:11:24 beach mayuresh: Common Lisp is a dynamic language, so code is generated as a result of user interactions. Not just when the system is built.

6:11:28 mayuresh pretty good people, and noble too. :)

6:12:00 mayuresh beach: the interpreter of clisp is statically built, that's what runs the common lisp environment for it.

6:12:18 beach mayuresh: So you can generate a very fast interpreter at build time, but it won't beat the native code generated as a result of user interactions in a system like SBCL.

6:12:19 mayuresh beach: including the common lisp compiler from within.

6:12:35 mayuresh beach: yes, you are correct.

6:13:00 mayuresh beach: but the clisp team *might* bring in the optimisation techniques from sbcl to clisp

6:13:17 mayuresh beach: for the compiler that is.

6:13:25 susam mayuresh: Curious. What attracted you to Common Lisp? Paul Graham's work and writings?

6:13:52 mayuresh susam: i worked with autolisp as an engineering intern at larsen & toubro ltd.

6:13:53 beach mayuresh: I think I now have a much better idea about the foundation of your opinions and convictions.

6:14:14 mayuresh beach: sure, that's great. :)

6:14:45 susam mayuresh: Oh yes. I remember you mentioning that the last time we talked on this channel. It is great to know that L&T was using AutoLisp.

6:15:01 mayuresh susam: then i forgot about lisp till i worked for cleartrip, where i initiated the formation of the lisp developer team.

6:15:19 mayuresh susam: then off-late i read the introduction of "on lisp" and i was sold.

6:15:40 susam mayuresh: Are you saying you established a Lisp development team in ClearTrip? Did that work out well for you? Were others skeptical?

6:16:09 mayuresh susam: my first interview got pretty involved because i mentioned lisp.

6:16:11 contrapunctus mayuresh: hello from Delhi :)

6:16:31 pranavats There's also a former ClearTrip employee who started a startup called deftask.

6:16:33 mayuresh susam: cleartrip hired me primarily because i was only person who had even heard about lisp.

6:16:37 pranavats Chaitanya Gupt

6:17:04 mayuresh pranavats: i am the ghengis khan of the technology group at cleartrip.

6:17:09 mayuresh :D

6:17:44 pranavats mayuresh: Haha. Awesome. Why did they drop Common Lisp though? If you can shed light on that.

6:17:46 susam mayuresh: Oh, wow! I had no idea ClearTrip was using Lisp. And which Lisp do they use? Common Lisp? What percentage of the code base is in Lisp (roughly), if you don't mind sharing.

6:18:33 mayuresh susam, pranavats: cleartrip's investors forced them to hire a team of java developers from another company that was funded by the investors.

6:19:02 pranavats I see.

6:19:07 mayuresh susam, pranavats: cleartrip's 'cto' sequence was hardcore java oriented.

6:19:20 mayuresh i left out of disgust.

6:19:45 mayuresh and then the whole lisp group just collapsed like a house of cards.

6:20:10 pranavats Sad.

6:20:46 mayuresh there were good guys like "baishampayan ghose", "vihang pande", "abhijit rao", etc.

6:21:20 mayuresh in fact, i was responsible for abhijit rao and prashant acharekar's hiring.

6:21:35 mayuresh and then it was just a long line of developers waiting to join in. :)

6:22:15 mayuresh contrapunctus: hello from mumbai. :)

6:24:26 d4ryus1 ** NICK d4ryus

6:24:46 pranavats mayuresh: I wonder what percentage of the code base was in CL, too. (susam's question)

6:25:55 mayuresh pranavats: when we started off, 100%, then down to 80% (rest was ruby+python).

6:26:14 mayuresh pranavats: then one fine day, 0% because java happened.

6:27:22 susam Sounds like the story of Reddit. It was 100% Common Lisp. The old source code is archived somewhere on GitHub. Then they decided to switch to Python for various reasons.

6:27:41 mayuresh pranavats: thinking back, i should not have left. if you run away, they'll keep chasing you away.

6:28:13 susam Meanwhile I have been moving all my personal scripts and tools from Python to Common Lisp. Primiarly because I cannot deal with my tools breaking everytime I upgrade a version of a dependency. This backward-incompatibility culture really bothers me now.

6:28:16 pranavats Naughty Dog's founder mentioned getting pressure from Sony (who bought them), to take their codebase off Lisp (GOAL), in one of the interviews iirc.

6:28:19 mayuresh better to stand your ground and fight back.

6:28:50 susam s/Primiarly/Primarily/

6:29:07 pranavats But they still used GOAL in The Last of Us for scripting. So I guess they haven't given up entirely.

6:31:17 pranavats mayuresh: I guess. I wonder if there are more closeted Common Lisp devs in Software Industry here (India).

6:31:32 beach mayuresh: So here is the thing. Common Lisp is a language that is sufficiently different from C and C++ that generating fast code for languages like C and C++ is not good enough for Common Lisp.

6:31:36 beach For example, those languages don't have generic functions, so a good Common Lisp system must optimize generic dispatch. Another aspect is that Common Lisp has a much more sophisticated function-call protocol with optional and keyword arguments.

6:31:37 beach It is not enough to generate fast code for those things. You also have to take into account optimizations specific to Common Lisp, and that I bet Intel is not working on.

6:31:38 pranavats I'm looking up the names you mentioned.

6:32:39 beach Furthermore, in Common Lisp you can redefine functions at run time, so you can't statically optimize callers the way you can in a language with at compile/link/run development cycle.

6:32:56 moon-child beach: the problem with function calls is not complexity but dynamism

6:33:13 beach moon-child: Fair enough. Thanks.

6:34:06 mayuresh beach: someone would have to specifically work on the common lisp compilers to produce optimised binaries as per the latest cpu architecture changes/improvements.

6:34:54 beach mayuresh: I often remark on many industrial projects I have seen that choose C++ because "it is known that the compiler generates fast code", but then they completely blow it, because what they need is really automatic memory management, and the stuff they do to compensate makes their code slower, and impossible to maintain.

6:34:56 moon-child well, no, I guess it's both

6:35:04 mayuresh beach: i have been studying 'bdi' based intent oriented compilation approaches, will probably use it for common lisp here on.

6:35:16 moon-child beach: yeah, gc can frequently be faster than naive manual memory management schemes

6:35:33 beach moon-child: Indeed.

6:36:21 moon-child (and where it's not, you can generally implement the same strategies in a language with automatic memory management at no cost)

6:36:40 moon-child (I mean, where gc is slower than sophisticated manual memory management schemes)

6:36:54 beach Yes, good remark.

6:37:05 mayuresh moon-child: good one.

6:39:21 mayuresh moon-child: can you recommend good books to help me go deeper into those techniques?

6:39:22 beach mayuresh: So, unless Intel addresses these issues (generic dispatch, non-trivial lambda lists, dynamic redefinitions, etc.) I don't see how what they do is every going to be good enough for a Common Lisp implementation.

6:40:07 moon-child mayuresh: I don't know of any, sorry. Perhaps other people in the channel do, though?

6:40:17 mayuresh beach: intel will never address those issues by themselves, they'll just produce processor manuals, and it would be upto 'cl' compiler developers to work things out for themselves and their implementations.

6:41:04 beach mayuresh: But that is precisely what the SBCL maintainers are doing.

6:41:47 beach mayuresh: I thought your argument for clear linux was that we could take advantage of Intel's contributions to the GNU toolchain to avoid this work.

6:41:48 beach No?

6:41:56 mayuresh beach: i hadn't known about that bootstrapping 'cl' you'd mentioned, else i would have suggested sbcl with that to the clear linux team.

6:42:13 mayuresh beach: no, that was not my argument.

6:42:28 beach OK.

6:42:29 mayuresh beach: sorry if i misconveyed my thoughts and position.

6:44:05 beach Well, BOCL is not finished, but either CLISP or ECL can serve the same purpose, thereby making it possible to build something like SBCL from C and Make.

6:44:43 mayuresh beach: i don't think the "clear linux" team would agree to having more than 1 full fledged 'cl' system on their distribution.

6:45:03 beach Ah, more constraints.

6:45:06 mayuresh beach: but i'll try suggesting sbcl to them.

6:46:15 beach I can tell that it's risky that I come across as being an SBCL fanatic. That is not the case. I am merely using SBCL as an example of a Common Lisp implementation written (mostly) in Common Lisp, which to me is the sane way of doing it.

6:46:54 mayuresh nothing risky. everybody is entitled to have their preferences and opinions.

6:47:25 mayuresh the same way that i believe in the "clisp" way more than the way of "sbcl".

6:48:37 beach Well, if you are right about the "clear linux" team, I think it is very sad, because that means that they only accept ways of creating software that forces us to be way less productive than we can be.

6:48:59 beach But that seems to be the state of the software world, so I am not surprised.

6:49:23 mayuresh no, the "clear linux" team doesn't want unnecessary hand tuning and manual intervention. they want as much automation as possible.

6:49:53 beach How does that prevent "more than 1 full fledged 'cl' system on their distribution"?

6:49:55 mayuresh as i said, i'll definitely ask the "clear linux" team regarding "sbcl".

6:50:42 mayuresh for "sbcl" to be buildable, they'll also need to have "clisp", so they *might* choose to run with "clisp" _only_.

6:50:49 mayuresh that's my point.

6:50:52 mayuresh not theirs.

6:50:58 beach I think I am not expressing myself very well.

6:51:01 mayuresh i might have not understood them fully.

6:51:44 mayuresh beach, are you requesting more than 1 "common lisp" system under clear linux?

6:52:03 mayuresh if yes, as i said, they *might* consider.

6:52:04 beach Suppose SBCL secretly includes CLISP or ECL in its distribution, so that when you type `make', what really happens is that CLISP or ECL is first built using the C compiler, and then SBCL is built using CLISP or ECL. Why would the clear linux team care?

6:52:07 mayuresh just not sure.

6:52:44 mayuresh beach: if sbcl does that, then yes, there would be no issues with the "clear linux" team accepting sbcl.

6:53:15 mayuresh beach: understand that the "clear linux" team wants as much automation as possible. or rather as little manual intervention as possible.

6:53:43 mayuresh beach: bocl would be a good idea once it's done.

6:54:01 mayuresh beach: is bocl using anything from sicl?

6:54:09 beach No.

6:54:27 pjb mayuresh: all CL implementations can be compiled automatically, once you've gathered all the required dependencies. Perhaps some are lacking some packaging on some distribution, but there are enough CL implementations that can be built with configure && make install.

6:54:28 mayuresh so bocl is building it's own stuff up from scratch!

6:54:58 mayuresh pjb: can you point out a few which are as automated as clisp?

6:55:00 pjb Well, I've copy-pasted and adapted some code from sicl and probably will some more into my bocl ;-)

6:55:20 pjb mayuresh: clisp, ecl, sbcl, abcl.

6:55:22 beach BOCL is going to be a pure C implementation of a conforming, but perhaps horribly slow, Common Lisp system.

6:55:51 pjb beach: well, "pure C" only for some kernel. A lot will be written in lisp…

6:55:52 beach mayuresh: The idea is that it would not be written for speed, but for simplicity and maintainability.

6:55:56 mayuresh pjb: sbcl requires a lot of manual intervention.

6:56:08 pjb You'd have to be terribly masochistic to write everything in C.

6:56:10 beach pjb: Right, but that's just data input to the rest of the system.

6:56:21 pjb Even the C I have is already partly generated from a lisp script!

6:56:25 pjb Yes.

6:56:40 beach Ouch, that last thing is not a good idea.

6:56:52 beach It means it is not "source code" as the FSF defines it.

6:57:28 pjb Now, about linux and lisp integration, it should be possible to write a linux module that would implement all the linux syscalls using lisp (tagged) data types. Some definition (kind of the CL POSIX definition) would have to be specified, because this could lead to some simplification of the syscall API.

6:57:43 pjb It is also quite possible that this would lead to more efficiency (for lisp processes).

6:57:46 moon-child yeah, it sounds like you're making a self-hosting lisp implementation part of which is compiled to c :)

6:57:50 shka yes, it would also be possible on windows

6:58:03 shka not quite on the OSX

6:58:51 beach pjb: I have an embryonic specification of a POSIX API for Common Lisp.

6:58:53 pjb beach: well, it's generated at "edit-time". The generated C code is commited into the repository.

6:59:21 beach Not sure I understand that, but I take your word for it.

6:59:34 shka honestly, not being glibc dependent would be benefit in itself

7:00:20 pjb shka: some C programmers also do that, using directly linux syscalls and bypassing the libc.

7:00:29 moon-child there was some work done to make sbcl binaries that were statically linked with musl

7:00:30 pjb shka: we would only need to define the FFI for syscalls.

7:11:51 beach pjb: Have you seen my suggested POSIX interface?>

7:13:12 beach http://metamodular.com/POSIX-API/

7:49:27 pjb beach: indeed. I also started working on something like that even earlier. We talked about that then.

7:50:59 beach I see. Sorry about my bad memory. :(

8:00:08 pjb No problem, it was a long time ago!

8:00:25 beach Whew! :)

8:00:37 pjb I started lisping seriously with CL in 1996, 25 years ago.

8:01:24 beach I guess we started roughly at the same time then. I did Scheme before that.

8:02:07 pjb Yes. But scheme didn't stick, each time I tried, it was a different implementation and even perhaps a different N of rNrs…

8:02:48 beach Yeah, same here. And I found myself implementing (bad) object systems.

8:03:01 pjb Yep.

8:03:34 beach I tried it in teaching too, but I didn't believe my own words: "Sure, it's slow, but, you see, it is *possible* to write a good Scheme compiler; I just don't know how...".

8:03:47 pjb Which is nice for students. I call scheme a pedagogical programming language. Sophisticated, but incomplete enough so that students have a lot of learning exercises.

8:04:07 beach Sure.

8:04:35 shka that was the initial point of the design IIRC

8:04:44 shka so it completes the goal

8:04:56 pjb Definitely. This may change with r7rs/big.

8:05:55 moon-child apparently r7rs large is getting predicate-based dynamic dispatch

8:18:10 beach Good for them.

8:20:48 shka eh, i don't know

8:21:08 shka it may hurt the educational angle scheme had going

8:21:23 shka but i guess you can use the older standard version of scheme for this purpose still

8:21:57 moon-child or the 'small' variant, which will (afaik) continue to be maintained

8:27:12 Lord_of_Life_ ** NICK Lord_of_Life

9:18:20 gin While typing code with paredit-mode, whenever I type #p"/foo", paredit changes it to #p "/foo" (note the extra space after #p added by paredit). Is that a correct convention being followed by Paredit?

9:18:43 gin I see most CL code has #p"/foo" (not #p "/foo"). how to stop Paredit from inserting the extra space between #p and the string?

9:22:53 ck_ are you sure that it is Paredit doing the inserting?

9:30:07 gin ck_: Yes, if I disable paredit-mode, this issue no longer occurs

9:30:07 ck_ oh, I was checking with the wrong buffer, sorry. I've only ever seen no space between the hash-p and the string

9:30:52 gin ck_: do you have paredit-mode enabled now? What happens if you type #p"foo"? Does it insert a space between #p and "foo"?

9:33:58 ck_ gin: yes, it does. Also between #2A and ((1)) for example.

9:34:07 ck_ I wonder if I've simply never noticed

9:34:22 jdz gin: I have some code for this, sec.

9:34:47 clintm I get that with paredit as well and just end up C-b'ing back and taking out the space. Still annoying though. I've never gotten around to figuring out what was going on.

9:34:48 gin ck_: maybe you just remove the space manually by habit. i have been doing that everytime I have to do that I feel the inconvenience

9:37:30 jdz gin: https://gist.github.com/jdz/bdcd4e20066ab7d743d81b115310d229 There's more code than necessary, but Emacs' `looking-back' is just wrong, so I tried to get around it. I've found what needs to be done on some wiki or paredit documentation itself.

9:38:36 clintm Hmmm... I'll try that. Thanks, jdz!

9:39:59 jdz clintm: Code not using my personal `usr:looking-back-at-p' should be available somewhere on the interwebs, you probably only need the last two forms.

10:24:38 pjb gin: #p"foo" doesn't insert a space for me…

10:25:05 gin pjb: Paredit enabled for you?

10:25:10 pjb yes.

10:25:39 pjb #2A() no space either.

10:26:18 pjb #2A are self-insert-command and ( is paredit-open-round and " is paredit-doublequote.

10:26:35 pjb gin: type C-h k ( to see your own binding in the paredit buffer.

10:29:44 gin pjb: ( is to (paredit-open-round &optional N)

10:30:05 pjb gin: perhaps https://github.com/informatimago/rc/blob/master/emacs-paredit.el is relevant. I'm not sure to understand paredit-space-for-delimiter-predicates anymore. I have: paredit-space-for-delimiter-predicates --> (pjb-paredit-space-for-delimiter-p/predicates)

10:30:06 gin pjb: " runs the command paredit-doublequote (found in paredit-mode-map),

10:31:39 pjb But it seems that paredit-space-for-delimiter-predicates indeed is what you want to customize.

11:32:35 kciN Hey, guys! Where can I find core common lisp specification, without the whole standard library bloat?

11:34:16 pranavats kciN: Not sure what you mean. You want just the special forms?

11:35:20 jackdaniel kciN: the common lisp standard covers all symbols found in the common-lisp package

11:35:37 jackdaniel i.e a function remove-if-not is part of the "core common lisp specification" as you put it - that is, the ansi standard

11:36:37 jackdaniel if you want to read online the document that is based on the final draft of the standard (and does not differ from the standard in any important way), you may use this website: http://www.lispworks.com/documentation/HyperSpec/Front/index.htm

11:37:14 jackdaniel most notably http://www.lispworks.com/documentation/HyperSpec/Front/Contents.htm

12:11:41 mayuresh hello! :)