<etimmons>
That one is more interesting. Some non-type-errors in there
char has joined #commonlisp
<beach>
Thanks. Not yet sure what I am looking at. I haven't finished my morning coffee yet.
<etimmons>
Tests for the aref-accessor-dimension-error issue on a bunch of implementations
<beach>
That much I got. I need to study the format of the output.
<etimmons>
ah. Sorry, my format foo is a bit weak so it's not as pretty as I wanted.
<beach>
Mine is probably even weaker.
vats has quit [Remote host closed the connection]
<etimmons>
Long story short: each of those impls signals an error. But ccl and cmucl are just simple-error
<beach>
I am slowly understanding it. Thank you very much!
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
isekaijin has quit [Ping timeout: 255 seconds]
isekaijin has joined #commonlisp
Bike has quit [Quit: Lost terminal]
peterhil has quit [Ping timeout: 276 seconds]
CrashTestDummy3 has joined #commonlisp
CrashTestDummy2 has quit [Ping timeout: 255 seconds]
mayuresh has joined #commonlisp
<mayuresh>
hello everybody. :)
<beach>
Hello mayuresh.
CrashTestDummy2 has joined #commonlisp
dsk has joined #commonlisp
CrashTestDummy3 has quit [Ping timeout: 255 seconds]
<susam>
Good morning, everyone!
<susam>
Hello mayuresh! Hello beach!
<mayuresh>
good morning susam. :)
<beach>
Hello susam.
<mayuresh>
susam, what time is it out there?
<mayuresh>
out here it's 11:05.
<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.
<mayuresh>
anyone has any idea why "clisp" has stagnated?
<beach>
mayuresh: It happens.
<mayuresh>
or is there only no public releases for a while now??
<beach>
Lack of funding, people get busy with other stuff, etc.
<mayuresh>
ah, okay.
<beach>
I mean, those are just examples.
<mayuresh>
how does clisp compare with sbcl?
<beach>
Much slower, but more portable.
<beach>
But recently, I have seen bhaible here, so maybe he is working on CLISP again.
<mayuresh>
is bhaible, bruno?
<beach>
I am assuming that, yes.
<mayuresh>
cool. i think he's based out of germany (at last known point in time).
<beach>
Also, since there has been less work on CLISP than on SBCL, it means SBCL is more close to being conforming.
<mayuresh>
i am quite gung-ho about working under "clear linux" (clearlinux.org)
<mayuresh>
and they requested a simple configure, make, make install like build process.
<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.
<mayuresh>
so clisp is the only option i could recommend to the clear linux team.
<beach>
mayuresh: Oh, but that's so oriented toward Unix static languages like C.
<mayuresh>
beach: clear linux is highly optimised by intel for intel's processors.
<beach>
Writing a Common Lisp implementation in C or C++ is unnecessarily difficult.
<mayuresh>
beach: that's why they want natively configurable and buildable systems.
treflip has joined #commonlisp
<mayuresh>
hi treflip. :)
<beach>
mayuresh: Don't greet people who do not speak please, or else there will be nothing but greetings in this channel.
<mayuresh>
beach: clisp shows that building implementations in c/c++ is just okay.
<beach>
mayuresh: CLISP shows that if you do it that way, you run the risk of ending up with a very slow resulting system.
<treflip>
hi
<moon-child>
mayuresh: abcl may be a better choice; it has a simple build process afaik, and is likely to have better compatibility
<mayuresh>
beach: clisp was fast enough for paul graham to build his commercial portal.
<moon-child>
and java is very popular; I assume they already package other java applications
<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.
<beach>
mayuresh: If you can live with slow code, that's fine.
<mayuresh>
beach: you are confused because you seem to be too involved in your own train of thoughts.
<mayuresh>
beach: clisp has a compiler too.
<beach>
I see. Thank you for pointing that out.
<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
<mayuresh>
i don't know how to "pm", thanks for the note from mysterious. :)
<moon-child>
(beach has a point, I mean)
<mayuresh>
moon-child: you are missing the point, clisp might be interpreted, but it has a compiler too.
char has quit [Ping timeout: 255 seconds]
xsperry has quit []
<beach>
Common Lisp implementations that generate fast code (like SBCL) run just fine on Intel processors.
<moon-child>
mayuresh: clisp does not generate highly performant code. Sbcl does
<beach>
mayuresh: Nobody denies that CLISP has a compiler. We only mentioned the speed of the resulting code.
<mayuresh>
beach: sbcl just can't have the optimisations that intel has introduced with native binaries under "clear linux".
<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.
<mayuresh>
beach: sbcl will always play catch-up with native code.
<beach>
mayuresh: What is a "native binary"?
<beach>
mayuresh: And what is "native code", if that is not what SBCL is generating?
<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.
<mayuresh>
beach: in the case of clear linux it is intel.
susam_ has joined #commonlisp
<beach>
Oh, so it's tied to a commercial company?
<susam_>
Joined via ircII just for nostalgia's sake
<mayuresh>
beach: yes, but clear linux is fully open source.
<susam_>
Joined via ircII just for nostalgia's sake
<mayuresh>
beach: and intel has a large team dedicated to working on gnu build tools.
<susam_>
Oops! Sorry for the spam.
cmack has quit [Ping timeout: 255 seconds]
<mayuresh>
susam: it's okay, i love ircii. :)
<mayuresh>
beach: intel's has a dedicated large team to improve the gnu toolchain for intel's processors.
wilfred has quit [Quit: Connection closed for inactivity]
<mayuresh>
beach: in fact, intel brings out newer contributions to gnu toolchain in tandem with every release of their newer processors.
<mayuresh>
beach: it's bloody marvellous. :)
<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?
<mayuresh>
beach: i looked around on google, and it seems clisp is working on improving their performance, just not making a loud noise.
<beach>
I see, so it's an investment in the future.
<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.
susam_ has quit [Client Quit]
susam_ has joined #commonlisp
<susam_>
mayuresh: So checked again with this alternate nick. Both "/msg susam Hello" and "/query susam" work for private messages in ircII too.
<beach>
mayuresh: I am looking forward to the day when CLISP is both more conforming and generates faster code than SBCL does.
<mayuresh>
beach: same here. :)
<mayuresh>
beach: and i think that day isn't far away. :)
<beach>
Good to know.
<mayuresh>
does anyone know if "rob warnock" hangs out around here?
<susam>
Why the fondness for CLISP this morning? Why care about it when there is SBCL?
<susam>
I like CLISP though for nostalgia reasons but these days SBCL is all I need.
<beach>
susam: That was explained.
<beach>
susam: Check the logs.
<susam>
Okay. I have missed it then. Let me scroll up.
<mayuresh>
susam: because it's difficult to build sbcl using automated systems without using a previous cl implementation.
<beach>
susam: It is the only implementation that is good for "clear linux".
<mayuresh>
susam and beach: and i'm really keen on working under clear linux. :)
<beach>
mayuresh: Oh, but that's not the argument you gave before.
<beach>
mayuresh: If that is the argument, you might consider our BOCL project.
<mayuresh>
i tested it out and the performance under my machine is mind blowing.
<mayuresh>
"bocl"?
<susam>
Okay, that makes sense. I agree it is a good attribute to have.
<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.
<mayuresh>
beach: that's bloody brilliant.
<mayuresh>
beach: i'll investigate this further.
<mayuresh>
beach: thanks a million for that tip. :)
<beach>
mayuresh: Then you can build everything using Make, but the main Common Lisp implementation is written in Common Lisp as it should be.
<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?
<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.
<mayuresh>
beach: that's exactly what i have mentioned in the previous note.
<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.
<mayuresh>
beach: intel's optimizations for the gnu toolchain would never get carried forward into sbcl, but will under clisp's interpreter.
<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.
<beach>
mayuresh: "interpreter"? I thought you said that CLISP used a compiler.
<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.
<beach>
mayuresh: Or are you saying that a bytecode interpreter can be faster than the native code generated by SBCL?
<mayuresh>
beach: clisp is primarily interpreted, and also has a compiler.
<beach>
But the compiler generates bytecodes, right?
<beach>
Maybe it has a native compiler these days.
<mayuresh>
beach: i think the clisp compiler outputs native binaries.
<beach>
mayuresh: Oh, I mean when you type (defun ...) to the prompt. What kind of code is generated then.
susam_ has quit [Quit: Leaving]
<beach>
mayuresh: I was not talking about the system build.
<mayuresh>
beach: i am "pm"-ng you my email address, will you "pm" me yours?
^[ has quit [Ping timeout: 276 seconds]
<beach>
I prefer to discuss things here.
<mayuresh>
okay.
<beach>
I think it is important for others to see and comment on the arguments.
<mayuresh>
i just wanted to be in close touch regarding the evaluation.
<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?
<susam>
Yes, this is a good discussion. Keep the discussion here so that I and others curious about it can see it here. :)
<jackdaniel>
clisp may generate native code with lightning jit, that said the compiler outputs a bytecode
<beach>
Or, I guess, it would be good enough if COMPILE-FILE generates native code.
<jackdaniel>
so clisp won't benefit from "highly optimized gnu toolchain"
<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.
<beach>
mayuresh: Oh, but that's very important.
<jackdaniel>
ecl could partially benefit from it, because it compiles to c, and then the resulting c file is compiled with the c compiler
<mayuresh>
hey, i'm a totally newbie to common lisp, yet i'm understanding most things pretty well.
<mayuresh>
i'm in love with this group. :)
<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.
<mayuresh>
pretty good people, and noble too. :)
<mayuresh>
beach: the interpreter of clisp is statically built, that's what runs the common lisp environment for it.
<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.
<mayuresh>
beach: including the common lisp compiler from within.
<mayuresh>
beach: yes, you are correct.
<mayuresh>
beach: but the clisp team *might* bring in the optimisation techniques from sbcl to clisp
<mayuresh>
beach: for the compiler that is.
<susam>
mayuresh: Curious. What attracted you to Common Lisp? Paul Graham's work and writings?
attila_lendvai has joined #commonlisp
<mayuresh>
susam: i worked with autolisp as an engineering intern at larsen & toubro ltd.
<beach>
mayuresh: I think I now have a much better idea about the foundation of your opinions and convictions.
<mayuresh>
beach: sure, that's great. :)
shka has joined #commonlisp
<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.
<mayuresh>
susam: then i forgot about lisp till i worked for cleartrip, where i initiated the formation of the lisp developer team.
<mayuresh>
susam: then off-late i read the introduction of "on lisp" and i was sold.
<susam>
mayuresh: Are you saying you established a Lisp development team in ClearTrip? Did that work out well for you? Were others skeptical?
<mayuresh>
susam: my first interview got pretty involved because i mentioned lisp.
<contrapunctus>
mayuresh: hello from Delhi :)
<pranavats>
There's also a former ClearTrip employee who started a startup called deftask.
<mayuresh>
susam: cleartrip hired me primarily because i was only person who had even heard about lisp.
<pranavats>
Chaitanya Gupt
<mayuresh>
pranavats: i am the ghengis khan of the technology group at cleartrip.
<mayuresh>
:D
<pranavats>
mayuresh: Haha. Awesome. Why did they drop Common Lisp though? If you can shed light on that.
<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.
<mayuresh>
susam, pranavats: cleartrip's investors forced them to hire a team of java developers from another company that was funded by the investors.
<pranavats>
I see.
<mayuresh>
susam, pranavats: cleartrip's 'cto' sequence was hardcore java oriented.
<mayuresh>
i left out of disgust.
<mayuresh>
and then the whole lisp group just collapsed like a house of cards.
<pranavats>
Sad.
<mayuresh>
there were good guys like "baishampayan ghose", "vihang pande", "abhijit rao", etc.
<mayuresh>
in fact, i was responsible for abhijit rao and prashant acharekar's hiring.
<mayuresh>
and then it was just a long line of developers waiting to join in. :)
<mayuresh>
contrapunctus: hello from mumbai. :)
d4ryus1 is now known as d4ryus
selwyn has joined #commonlisp
<pranavats>
mayuresh: I wonder what percentage of the code base was in CL, too. (susam's question)
<mayuresh>
pranavats: when we started off, 100%, then down to 80% (rest was ruby+python).
<mayuresh>
pranavats: then one fine day, 0% because java happened.
<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.
<mayuresh>
pranavats: thinking back, i should not have left. if you run away, they'll keep chasing you away.
<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.
<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.
<mayuresh>
better to stand your ground and fight back.
<susam>
s/Primiarly/Primarily/
<pranavats>
But they still used GOAL in The Last of Us for scripting. So I guess they haven't given up entirely.
^[ has joined #commonlisp
<pranavats>
mayuresh: I guess. I wonder if there are more closeted Common Lisp devs in Software Industry here (India).
<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.
<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.
<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.
<pranavats>
I'm looking up the names you mentioned.
<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.
<moon-child>
beach: the problem with function calls is not complexity but dynamism
<beach>
moon-child: Fair enough. Thanks.
<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.
selwyn has quit [Read error: Connection reset by peer]
<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.
<moon-child>
well, no, I guess it's both
<mayuresh>
beach: i have been studying 'bdi' based intent oriented compilation approaches, will probably use it for common lisp here on.
<moon-child>
beach: yeah, gc can frequently be faster than naive manual memory management schemes
<beach>
moon-child: Indeed.
pjb has joined #commonlisp
<moon-child>
(and where it's not, you can generally implement the same strategies in a language with automatic memory management at no cost)
<moon-child>
(I mean, where gc is slower than sophisticated manual memory management schemes)
<beach>
Yes, good remark.
<mayuresh>
moon-child: good one.
<mayuresh>
moon-child: can you recommend good books to help me go deeper into those techniques?
<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.
<moon-child>
mayuresh: I don't know of any, sorry. Perhaps other people in the channel do, though?
<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.
<beach>
mayuresh: But that is precisely what the SBCL maintainers are doing.
<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.
<beach>
No?
<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.
<mayuresh>
beach: no, that was not my argument.
<beach>
OK.
<mayuresh>
beach: sorry if i misconveyed my thoughts and position.
<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.
<mayuresh>
beach: i don't think the "clear linux" team would agree to having more than 1 full fledged 'cl' system on their distribution.
<beach>
Ah, more constraints.
<mayuresh>
beach: but i'll try suggesting sbcl to them.
<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.
Krystof has joined #commonlisp
<mayuresh>
nothing risky. everybody is entitled to have their preferences and opinions.
<mayuresh>
the same way that i believe in the "clisp" way more than the way of "sbcl".
<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.
<beach>
But that seems to be the state of the software world, so I am not surprised.
<mayuresh>
no, the "clear linux" team doesn't want unnecessary hand tuning and manual intervention. they want as much automation as possible.
<beach>
How does that prevent "more than 1 full fledged 'cl' system on their distribution"?
<mayuresh>
as i said, i'll definitely ask the "clear linux" team regarding "sbcl".
<mayuresh>
for "sbcl" to be buildable, they'll also need to have "clisp", so they *might* choose to run with "clisp" _only_.
<mayuresh>
that's my point.
<mayuresh>
not theirs.
<beach>
I think I am not expressing myself very well.
<mayuresh>
i might have not understood them fully.
<mayuresh>
beach, are you requesting more than 1 "common lisp" system under clear linux?
<mayuresh>
if yes, as i said, they *might* consider.
<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?
<mayuresh>
just not sure.
<mayuresh>
beach: if sbcl does that, then yes, there would be no issues with the "clear linux" team accepting sbcl.
<mayuresh>
beach: understand that the "clear linux" team wants as much automation as possible. or rather as little manual intervention as possible.
<mayuresh>
beach: bocl would be a good idea once it's done.
<mayuresh>
beach: is bocl using anything from sicl?
<beach>
No.
<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.
<mayuresh>
so bocl is building it's own stuff up from scratch!
<mayuresh>
pjb: can you point out a few which are as automated as clisp?
<pjb>
Well, I've copy-pasted and adapted some code from sicl and probably will some more into my bocl ;-)
<pjb>
mayuresh: clisp, ecl, sbcl, abcl.
<beach>
BOCL is going to be a pure C implementation of a conforming, but perhaps horribly slow, Common Lisp system.
<pjb>
beach: well, "pure C" only for some kernel. A lot will be written in lisp…
<beach>
mayuresh: The idea is that it would not be written for speed, but for simplicity and maintainability.
<mayuresh>
pjb: sbcl requires a lot of manual intervention.
<pjb>
You'd have to be terribly masochistic to write everything in C.
<beach>
pjb: Right, but that's just data input to the rest of the system.
<pjb>
Even the C I have is already partly generated from a lisp script!
<pjb>
Yes.
<beach>
Ouch, that last thing is not a good idea.
<beach>
It means it is not "source code" as the FSF defines it.
<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.
<pjb>
It is also quite possible that this would lead to more efficiency (for lisp processes).
<moon-child>
yeah, it sounds like you're making a self-hosting lisp implementation part of which is compiled to c :)
<shka>
yes, it would also be possible on windows
<shka>
not quite on the OSX
<beach>
pjb: I have an embryonic specification of a POSIX API for Common Lisp.
<pjb>
beach: well, it's generated at "edit-time". The generated C code is commited into the repository.
mayuresh has quit [Quit: Leaving]
<beach>
Not sure I understand that, but I take your word for it.
<shka>
honestly, not being glibc dependent would be benefit in itself
<pjb>
shka: some C programmers also do that, using directly linux syscalls and bypassing the libc.
<moon-child>
there was some work done to make sbcl binaries that were statically linked with musl
<pjb>
shka: we would only need to define the FFI for syscalls.
cjb has quit [Quit: rcirc on GNU Emacs 28.0.50]
<beach>
pjb: Have you seen my suggested POSIX interface?>
<pjb>
beach: indeed. I also started working on something like that even earlier. We talked about that then.
<beach>
I see. Sorry about my bad memory. :(
pve has joined #commonlisp
<pjb>
No problem, it was a long time ago!
<beach>
Whew! :)
<pjb>
I started lisping seriously with CL in 1996, 25 years ago.
<beach>
I guess we started roughly at the same time then. I did Scheme before that.
<pjb>
Yes. But scheme didn't stick, each time I tried, it was a different implementation and even perhaps a different N of rNrs…
<beach>
Yeah, same here. And I found myself implementing (bad) object systems.
<pjb>
Yep.
<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...".
<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.
<beach>
Sure.
rgherdt has joined #commonlisp
<shka>
that was the initial point of the design IIRC
<shka>
so it completes the goal
<pjb>
Definitely. This may change with r7rs/big.
<moon-child>
apparently r7rs large is getting predicate-based dynamic dispatch
hendursa1 has joined #commonlisp
hendursaga has quit [Ping timeout: 244 seconds]
lisp123 has joined #commonlisp
Th30n has joined #commonlisp
lisp123 has quit [Ping timeout: 258 seconds]
<beach>
Good for them.
<shka>
eh, i don't know
<shka>
it may hurt the educational angle scheme had going
<shka>
but i guess you can use the older standard version of scheme for this purpose still
peterhil has joined #commonlisp
<moon-child>
or the 'small' variant, which will (afaik) continue to be maintained
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 272 seconds]
Lord_of_Life_ is now known as Lord_of_Life
heisig has joined #commonlisp
Tomte has joined #commonlisp
IAmRasputin has joined #commonlisp
svillemot has quit [Quit: WeeChat 3.0]
IAmRasputin has quit [Ping timeout: 258 seconds]
waleee has joined #commonlisp
Patternmaster has quit [Remote host closed the connection]
etiago has quit [Ping timeout: 255 seconds]
etiago has joined #commonlisp
Patternmaster has joined #commonlisp
svillemot has joined #commonlisp
manicennui has quit [Quit: Connection closed for inactivity]
selwyn has joined #commonlisp
taiju has quit [Ping timeout: 255 seconds]
<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?
<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?
taiju has joined #commonlisp
<ck_>
are you sure that it is Paredit doing the inserting?
elf_fortrez has joined #commonlisp
<gin>
ck_: Yes, if I disable paredit-mode, this issue no longer occurs
<ck_>
oh, I was checking with the wrong buffer, sorry. I've only ever seen no space between the hash-p and the string
<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"?
Equill has joined #commonlisp
<ck_>
gin: yes, it does. Also between #2A and ((1)) for example.
<ck_>
I wonder if I've simply never noticed
<jdz>
gin: I have some code for this, sec.
<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.
<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
<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.
<clintm>
Hmmm... I'll try that. Thanks, jdz!
<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.
Th30n has quit [Ping timeout: 268 seconds]
lisp123 has joined #commonlisp
Th30n has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 252 seconds]
varjag has joined #commonlisp
tfb has joined #commonlisp
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
elf_fortrez has quit [Ping timeout: 246 seconds]
pillton has quit [Quit: ERC (IRC client for Emacs 27.2)]
<pjb>
gin: #p"foo" doesn't insert a space for me…
<gin>
pjb: Paredit enabled for you?
<pjb>
yes.
<pjb>
#2A() no space either.
<pjb>
#2A are self-insert-command and ( is paredit-open-round and " is paredit-doublequote.
<pjb>
gin: type C-h k ( to see your own binding in the paredit buffer.
lisp123 has joined #commonlisp
<gin>
pjb: ( is to (paredit-open-round &optional N)
<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)
<gin>
pjb: " runs the command paredit-doublequote (found in paredit-mode-map),
<pjb>
But it seems that paredit-space-for-delimiter-predicates indeed is what you want to customize.
kakuhen has quit [Quit: Leaving...]
lisp123 has quit [Ping timeout: 265 seconds]
dsk has quit [Ping timeout: 255 seconds]
random-nick has joined #commonlisp
waleee has quit [Ping timeout: 268 seconds]
tyson2 has joined #commonlisp
taiju has quit [Ping timeout: 246 seconds]
taiju has joined #commonlisp
treflip has quit [Remote host closed the connection]
treflip has joined #commonlisp
karlosz has joined #commonlisp
yitzi has joined #commonlisp
treflip has quit [Ping timeout: 252 seconds]
karlosz has quit [Quit: karlosz]
kciN has joined #commonlisp
<kciN>
Hey, guys! Where can I find core common lisp specification, without the whole standard library bloat?
<pranavats>
kciN: Not sure what you mean. You want just the special forms?
Th30n has quit [Quit: WeeChat 3.2]
Th30n has joined #commonlisp
<jackdaniel>
kciN: the common lisp standard covers all symbols found in the common-lisp package
<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
<jcowan>
beach: Is the idea of BOCL to write all of it in C, with no CL source at all?
treflip has joined #commonlisp
<beach>
jcowan: No, not quite. The idea is to write a Common Lisp implementation so that it can be built with only a C compiler and some minimal build tools available. It can consist of a C "core" and additional Common Lisp code on top.
IPmonger has joined #commonlisp
<jcowan>
So equivalent in that sense (AFAIU) to CLISP and ECL.
IPmonger has quit [Remote host closed the connection]
<jcowan>
but presumably easier to maintain
<beach>
jcowan: If you like. But the point is to have it written for best maintenance and simplicity. Not for speed.
<beach>
Yes.
<jcowan>
So one way to get at least partway to BOCL would be to replace the C in ECL (say) with equivalent but slower/more maintainable code.
<beach>
That sounds plausible. I haven't looked at the code enough to be sure, but it sounds likely. The Common Lisp code in ECL might of course also contain "compromises" in the name of performance.
mayuresh has quit [Ping timeout: 258 seconds]
dsk has joined #commonlisp
<jcowan>
Yes, that's why I say "partway"; once you have the C, you can "deoptimize" the CL parts at leisure.
<jackdaniel>
ignoring the c compiler (using only the bytecodes interpreter), removing threading and the interrupt handling should give a fairly maintainable code
<beach>
Yes, that makes sense.
<jackdaniel>
(of course these things are also maintainable, but would be unnecessary from bocl perspectie)
<beach>
It is an amusing exercise to think through the design decisions this way. One is (or at least I am) usually so focused on performance that it is hard to unthink such thoughts.
<jcowan>
Good to know. Still, the maintainer isn't always the best judge of maintainability. :-)
<jackdaniel>
sure, bystanders always know better
<jackdaniel>
because, you know, their opinion is not clouded by knowing /anything/ about the subject ,)
<beach>
Heh!
lisp123 has joined #commonlisp
<beach>
jackdaniel: I am sure ECL is quite maintainable. But I recommend the mental exercise I mentioned above. At least I am often surprised by the consequences.
<beach>
Like immediate fixnums not being necessary, and getting rid of them greatly simplifies things.
<beach>
Or having bitvectors having Common Lisp pointers as elements.
<jackdaniel>
I think that immediate fixnums do not impose /much/; I've mentioned the c compiler, threading and interrupts because (most notably the latter two) impose greater complexity (imho of course)
<beach>
Sounds plausible.
<beach>
I will still amuse myself by this mental exercise from time to time. I'll leave the programming to pjb who is actively working on it, using the result of his own design decisions of course.
<jcowan>
"Sure it's maintainable. That bug you mention, it's right *here*." Meanwhile I am searching the entire codebase for it...
<jcowan>
$BOSS is chronically annoyed with me because it takes me two weeks to fix something he could fix in two days (and that's his estimate for it). Sure, *he* could fix it in two days.
<jackdaniel>
jcowan: I don't buy into a notion that a maintainable code is the code that is understood by everyone from the start. that's not a possible feat for a reasonably complex abstractions
<jcowan>
Sure. But it needs to be in that case well roadmapped. Which this @#$* tangle of JavaScript is not.
* jackdaniel
doesn't understand the javascript reference; re "good roadmaps" - you may pour any number of hours into documentation and people will still complain. case in point - ecl has in the manual a description of file modules and their content
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
<jackdaniel>
even more, internal structures are briefly documented too
<jackdaniel>
so I guess it is time to write a "documentation roadmap"
<jcowan>
I'm talking about $EMPLOYER's JavaScript
<jackdaniel>
I still don't understand, but be as it may
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #commonlisp
hendursaga has quit [Client Quit]
hendursaga has joined #commonlisp
peterhil has quit [Read error: Connection reset by peer]
peterhil has joined #commonlisp
selwyn has quit [Read error: Connection reset by peer]
<jackdaniel>
beach: shouldn't the new text include "in safe code"?
<beach>
jackdaniel: That's what "should signal..." means.
<_death>
does CL use character designators anywhere besides CHARACTER?
<mfiano>
That link reminds me of a cringy comparison between CL and Scheme I had the misfortune of reading (part of) recently, which I can't find the link to. It described DIGIT-CHAR-P as a coercion from a string to a number.
<beach>
The function character takes a character designator.
<mfiano>
Isn't that what he asked about?
<beach>
Oh, sorry.
<beach>
Misunderstood.
<beach>
That seems to be the only one, yes.
<beach>
But there is a proposal to have some functions take a character designator.
<beach>
Or so I thought. :(
<_death>
functions like STRING< take string designators, but functions like CHAR< do not take designators.. maybe it's an oversight, or a performance thing.. maybe the concept of character designators was not born out of practicality
<beach>
Yeah, good question. Performance sounds plausible.
<beach>
Nah, I take that back.
<beach>
In safe code, the type would need to be checked anyway, and it would almost always be a character, which is typically an immediate object.
<_death>
why? remember that characters are kinda like fixnums
<beach>
_death: Is that what you mean? So we agree?
<_death>
agree on what? I think "performance reasons" is a good guess
<beach>
Ah, OK.
<mfiano>
Why woiuld a character be like a fixnum?
<_death>
but it's just a guess, I don't know that performance was ever considered in that context
<beach>
I think _death means that it is an immediate object.
<mfiano>
Doesn't extended-char not have an upper bound? Come to think of it, I don't even think base-char does
<beach>
But in safe code, it would look like (cond ((characterp object) <do the thing>) ((and (stringp object...))...) (t (error...))) So the test would almost always succeed.
<beach>
And the CHARACTERP test would be a tag-bit test, so very fast.
<beach>
... plus, in safe code it would have to be checked anyway.
<beach>
So it is possible that performance was an argument, but I don't think it is a valid one.
mingus has joined #commonlisp
<mfiano>
It's also possible it was just overlooked, or not finalized due to time or other resources.
<beach>
Indeed.
tfeb has joined #commonlisp
tfb has quit [Ping timeout: 272 seconds]
<_death>
beach: btw note that the symbol X is also a character designators (by way of string designators ;)
<_death>
*designator
lisp123 has joined #commonlisp
<beach>
Good point. Doesn't change the performance issue much though.
<_death>
right.. for performance I initially thought about type derivation.. but it could be that in actual cases it doesn't make the deductions easy
lisp123 has quit [Ping timeout: 246 seconds]
Th30n has quit [Quit: WeeChat 3.2]
Inline has quit [Quit: Leaving]
Inline has joined #commonlisp
<beach>
Though I think having those functions use character designators is outside the scope of WSCL.
derelict has joined #commonlisp
<_death>
I agree, it'd be too controversial
CrashTestDummy3 has joined #commonlisp
lisp123 has joined #commonlisp
CrashTestDummy2 has quit [Ping timeout: 268 seconds]
char has joined #commonlisp
cage has joined #commonlisp
ec has joined #commonlisp
lisp123 has quit [Ping timeout: 258 seconds]
<_death>
what about something like saying (defstruct foo a) (foo-a (make-foo)) => NIL .. I'd also want the &aux story to be the same, but expect disagreement there ;)
<Bike>
that gets kind of weird if the slot has a type specified, but that's sort of already the case with array element types
<_death>
Bike: right, I'm not talking about that case..
<Bike>
what case are you talking about? when there's no :type specified?
<_death>
when there's no :type or even initial value.. (defstruct foo a)
<Bike>
that makes specifying :type t have different behavior from not specifying a type, which is a little weird
<Bike>
but i guess you have to specify an initial value to specify a type anyway... right
<_death>
well, if you specify :type, you have to give an initform
<_death>
another thing is allowing (loop repeat 5 for x = (foo) collect x) ... basically CL conformance pitfalls that implementations (even SBCL :) tend to be lenient about..
jeosol has quit [Quit: Connection closed]
CrashTestDummy2 has joined #commonlisp
<beach>
_death: What is the issue with the loop?
Lycurgus has quit [Quit: Exeunt]
char has quit [Ping timeout: 272 seconds]
<_death>
can't have repeat before for according to loop grammar
<beach>
Right. Heh, I catch that in SICL loop, but I often don't see it.
<beach>
So Xach has been known to load SICL LOOP into SBCL to check systems in Quicklisp.
CrashTestDummy3 has quit [Ping timeout: 272 seconds]
<_death>
when #lisp alerted me to that fact I went through much of my code and changed it.. it's not always a trivial change :/
<beach>
I agree, it complicates the code.
<mfiano>
That's not just repeat though iirc
<_death>
right, variable clauses before main clauses
<mfiano>
(loop for x = 42 then (1+ x) while (< x 48) for y = (+ x (random 10)) collect (list x y))
<mfiano>
or something would be unconforming
<_death>
there are other cases of obvious non-conformance in wild
<mfiano>
And I agree it's not always a trivial change. I remember when I first discovered that, which was several years into Lisp, it took me close to a week to comb through all my code and fix it
<mfiano>
and I probably have to go do that again soon, because most implementations are derived from MIT-LOOP...
<_death>
for example when people define print-object methods that don't return the object (and print-unreadable-object not being helpful there..)
<Bike>
eh? print-unreadable-object doesn't return the object? shit, you're right
<Bike>
well that's just hostile
<_death>
but that kind of proposal (about p-u-o) may be too "innovative"
pranavats has left #commonlisp [Error from remote client]
<_death>
it contradicts the existing standard
ec has quit [Ping timeout: 244 seconds]
pranavats has joined #commonlisp
<beach>
_death: It sounds like you should start another project, similar to WSCL, but with a slightly higher level of ambition.
tyson2 has quit [Ping timeout: 258 seconds]
<_death>
beach: heh.. I accept these things.. CL isn't perfect, but it's good enough that I'd prefer not to change anything like that (WSCL is a good idea)
<_death>
besides, I am not an implementer or a company or language designer.. a mere user :)
ec has joined #commonlisp
<beach>
You are being too modest.
azimut_ has joined #commonlisp
azimut has quit [Ping timeout: 244 seconds]
<pjb>
Damned, I always wrote repeat first…
<_death>
so I think defstruct/loop proposals may belong to wscl's scope, because implementations cannot make different decisions without breaking lots of code already
<beach>
So you mean for instance that an error must be signaled when the loop clauses are in the wrong order?
ec has quit [Remote host closed the connection]
scymtym has joined #commonlisp
ec has joined #commonlisp
<jackdaniel>
I think that he meant it the other way around
<mfiano>
Is it within focus for WSCL to include additional functionality, such as #'mappend, or is it strictly limited to removing un-necessary freedoms and fixing errors?
<jackdaniel>
that is: require the implementation to handle these orders (which are right now incorrect)
<_death>
that could be one proposal (that has cost to users..).. another may be to propose to change the grammar so as to allow it (that may have cost to future implementers)
<beach>
That would be within the scope, but I want to start with practices that are widely agreed upon.
<beach>
Yes, I see.
<pjb>
beach: at least a warning. There's a reason for the order.
<_death>
beach: as far as I can tell, that practice (allowing it) is widely implemented
<beach>
OK. That one won't be as trivial to get consensus about as the others. :)
<beach>
_death: Only because everyone is using MIT LOOP by default.
<jackdaniel>
does ccl loop derive from mit?
<_death>
right.. SICL's clean room loop doesn't, I suppose
<beach>
_death: Correct.
<beach>
jackdaniel: I don't know. I should not have said "everyone".
<mfiano>
It would be nice if WSCL could be an extension like PLN, and pushing :WSCL to *FEATURES* would most definitely signal an error condition.
<mfiano>
For supporting implementations
<_death>
jackdaniel: looks that way
<jackdaniel>
thanks
<mfiano>
The loop order thing has been one thing that really bothered me over the years.
<jackdaniel>
mfiano: calling (push :wscl *features*) would signal a condition? or after pushing wscl invalid order in loop would cause the condition?
<mfiano>
The latter
<mfiano>
It's a strict conformance problem, not undefined behavior, iirc
<jackdaniel>
I think that this would be bad for maintanance - pushing to features changing the implementation behavior
cranium has quit [Quit: Leaving]
<mfiano>
The alternative is users continue to take on that burden.
<beach>
It's an interesting idea though. Worth thinking about.
<_death>
but I'd support proposal ALLOW.. so SICL implementers will have to pay the cost ;)
<jackdaniel>
there are other alternatives. One is to embrace any order, another is to add a build flag to the implementation, or even have a function that changes the loop behavior
<jackdaniel>
but changing a features list by a user affecting the macroexpansion sounds like a terrible kludge
<mfiano>
That's fair.
OlCe has quit [Ping timeout: 252 seconds]
<mfiano>
I do agree we do have to be careful about implementor maintenance cost; the cost could outweigh the benefit, especially in small CL-land...I just wish for something better from a user-standpoint, and not limited to loop order of course
lisp123 has quit [Remote host closed the connection]
shka has quit [Ping timeout: 252 seconds]
lisp123 has joined #commonlisp
lisp123 has quit [Client Quit]
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
manicennui has joined #commonlisp
Oddity has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
karlosz has joined #commonlisp
prxq has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
OlCe has joined #commonlisp
tyson2 has joined #commonlisp
amb007 has quit [Ping timeout: 245 seconds]
tyson2 has quit [Ping timeout: 258 seconds]
OlCe has quit [Ping timeout: 268 seconds]
analognoise has joined #commonlisp
amb007 has joined #commonlisp
mister_m` is now known as mister_mm
tyson2 has joined #commonlisp
attila_lendvai has quit [Ping timeout: 255 seconds]
ec has quit [Quit: ec]
robin has quit [Remote host closed the connection]
robin has joined #commonlisp
selwyn has joined #commonlisp
robin has quit [Read error: Connection reset by peer]
rt has joined #commonlisp
mister_mm is now known as mister_mmm
kakuhen has joined #commonlisp
OlCe has joined #commonlisp
char has joined #commonlisp
pve_ has joined #commonlisp
pve has quit [Ping timeout: 255 seconds]
jeosol has joined #commonlisp
char has quit [Ping timeout: 255 seconds]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
char has joined #commonlisp
svillemot has quit [Quit: WeeChat 3.0]
svillemot has joined #commonlisp
OlCe has quit [Ping timeout: 252 seconds]
pillton has joined #commonlisp
svillemot has quit [Quit: WeeChat 3.0]
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
char has quit [Ping timeout: 255 seconds]
svillemot has joined #commonlisp
ggoes has quit [Quit: WeeChat 2.3]
ggoes has joined #commonlisp
karlosz has quit [Quit: karlosz]
akoana has joined #commonlisp
rgherdt has quit [Ping timeout: 272 seconds]
Inline has quit [Ping timeout: 245 seconds]
varjag has quit [Ping timeout: 272 seconds]
selwyn has quit [Read error: Connection reset by peer]
dsk has quit [Ping timeout: 255 seconds]
<jcowan>
P-U-O is a good example of the perils of overspecification. Because it is required to return NIL. which is semantically useless, you can't implement your own P-U-O to return something you find more useful, such as the object. If the definition had said "the return values are unspecified" instead, it would be possible.
taiju has quit [Ping timeout: 255 seconds]
<edgar-rft>
what is P-U-O ?
taiju has joined #commonlisp
Alfr has quit [Killed (copper.libera.chat (Nickname regained by services))]
Alfr has joined #commonlisp
pegaso has joined #commonlisp
pve_ has quit [Quit: leaving]
paulapatience has joined #commonlisp
paulapatience has quit [Remote host closed the connection]