Lisp General: Prelude to Solitude

This is the Lisp General, ask any and all Lisp questions here. Below is a link to the general's texts which contain many links to various books, documentation, websites, and other interesting information. >Check the texts first: http://verisimilitudes.net/lisp >To foster discussion: Which dialect do you prefer? Do you use Emacs or a different lisp-based editor? What was your first experience with lisp? What have you made in lisp? What is your favorite Lisp program? What do you like about Lisp? How do you think Lisp is (one of) the superior programming language(s)? How long have you been programming in Lisp? What are your favorite Lisp resources? Please share, preferably links! Is Lisp your main programming language or not? Regardless, what do you primarily use it for? What would you like to see in the Lisp general? What was your favorite aspect of the Lisp machines? Do you think we'll ever get something similar to the LispMs again? What is your preferred method of documenting your code? In the dialects that allow it, do you make many reader macros or not? Do you use more than one dialect? What are they and which do you prefer? What do you consider the criteria for what constitutes a Lisp to be? What is your favorite function in your chosen dialect(s)? How do you feel Lisp is weaker than other languages? What is one aspect of other languages Lisp seems to ignore?

>>31412 >I think we're talking past each other here. I'm saying that CL's sequence (i.e. vector or list) functions can't do the decoding on the fly, so you can't store your string as UTF-8 and use those functions. Yes I think we're going in circles so there's no reason to continue this. >Linux might have some utility to notify the kernel that you want a lock on the next context switch so you can notify, spin, remove notification or notify, spin, block. >That'd be a syscall for every test, negating all the supposed performance gains of a spinlock; and a process can't really affect its scheduling this way, anyway, unless you use a realtime scheduling policy (you don't). My point wasn't clear here I meant leave a notification for the kernel that you want a lock without context switching in case your thread gets swapped out during the few cycles of spinning. This is similar to the io_uring system which allows a process to leave a note for the kernel without context switching that they want some resource (in the future) except it won't be acted on until the next context switch (or until they try and access it). >Another reason to not use spinlocks on Linux is that mutex are already very optimized; spinlocks are almost always a premature optimization thing. The case mutexes don't optimize for is exactly the case I'm suggesting spinlocks for (in fact IIRC a few popular mutex libraries will spin for a few cycles like I'm recommending so in that case you're right and there wouldn't be a difference) and a lot of the same optimizations would apply. >>31414 >There's already ARRAY-ROW-MAJOR-INDEX Of course there's much of the spec I still don't know. It really seems like they thought of everything in the areas it matters. >Those other languages only have one worthwhile implementation, notice. Not necessarily but that is a common occurrence. >Fortunately, no one will ever be able to meaningfully change the standard. In the end a new standard might damage the language just as much as the original ANSI did. I'm starting to believe that ad-hoc standards like Bordeaux-Threads are better than a complete new CL standard. Especially for concepts we don't (yet) fully understand like multiprocessing: just look at all the different incompatible methods are currently in use. >Common Lisp may as well be timeless, compared to other languages, so such performance benchmarks are beyond irrelevant. I think a better metric is whether sufficient performance optimizations are always possible because of an acceptable level of abstractions the language exposes as its core elements. A lot of design for the CL standard was making a language performant given a sufficiently smart compiler. Even now we haven't reached what they envisioned such a compiler could do (probably because most optimization work seems to go into making static SBCL code fast).

Thought a little bit about something I posted earlier: CL already has type parameters (e.g. `(deftype fixnum-car-cons () '(cons fixnum *))`) but no way to parametrize classes. And I really want it because I'm making a hash map using chained hashing, so the bucket type (list, vector or BST) should be customizable by the user for its performance characteristics. Instead, I'll have to use some godless macro abominations and define different classes for hash-map/list, hash-map/vector, etc... >>31416 I'd say we understand each other now. You want spinlocks to avoid the kernel machinery (sleep/wake up, mainly) cost, but with an io_uring like mechanism of shared memory to tell the scheduler to not bother you. Interesting.

>>31418 >You want spinlocks to avoid the kernel machinery (sleep/wake up, mainly) cost, but with an io_uring like mechanism of shared memory to tell the scheduler to not bother you. Interesting. Basically. Keeping the slower kernel machinery out of the way unless its actually needed. There might be something like that just a thought to try and get the best performance reasonably possible.

comp.lang.lisp on Google Groups has an entertaining thread on CLOS's non-default method combinations: https://groups.google.com/g/comp.lang.lisp/c/JaQy8WgeBHo/m/qP3fH2M_AQAJ

I've been thinking about making something like a pdf viewer - essentially zathura, if you've ever used it, because zathura is really annoying about some things. I've looked at some options for pdf rendering, and mupdf looks like the best one, but is it possible to use it with a lisp(I only have experience with common lisp, but I'm fine with trying some other ones)? I don't think there's a binding for it out there, so is it possible with some sort of ffi? Or maybe ecl? I'm not exactly sure how those things work since this is a library with a lot of its own structures and the examples for c interop with those are usually extremely simple standalone functions like multiplying 2 numbers.

>>31467 mupdf have header files, so it's possible to FFI-bind it to Common Lisp. If bindings exist already, I don't see them in Quicklisp. Baggers does an excellent video on bindings to C libraries: https://youtu.be/BL9MiiCcETM I recommend using cl-autowrap, which reads header files to generate the bindings for you. As a precaution, I remember getting this one error when generating the bindings that I needed to use someone's unmerged fork to fix, but once they are generated, anyone else is able to use your library with the quicklisp distibution or master branch. It's been a few months, though, so I don't remember the error or whose pull request it was that fixed it.

>>31571 > SAVE-LISP-AND-DIE That is not what I am looking for. This command saves lisp project as image. Which means it saves hello-world in 20mb file and starts REPL on execution >google search I'm not that stupid, anon >asdf >you don't want to do this with your simple program Well, I was searching for a way to manage lisp projects. I've come to conclusion asdf is kinda cmake from lisps' world. >Quicklisp >Alexandria I meant that there are so much things that bring no sense to use. I know what they used for. I just don't get why it is so complicated What I was talking about that is there is no easy way to start lisp programming. No setup-and-go if you will. You have to do 1. Hard step one 2. Hard step two 3. Hard step three ... and in the end you would come to conclusion you barely understand anything (maybe I stupid tho, but just don't get these things)

>>31574 >Strange. Shceme compiled hello world is 128kb. If I need the whole interpreter to run hello world in CL, that is like kicking dead whales down the beach. Common lisp requires that a full interpreter be available at any point in the program's execution. For the most part this is useful as it means a running program is the exact same as an interpreted one, but if you were to limit the features of CL that you use and try to do some black magic behind the scenes you could probably decrease it. The consensus in the CL community seems to be that 20MB of disk space isn't worth the hassle and it's easier for everything to just work™. I don't know if scheme has the same restrictions, but I would be willing to bet that the 128kB of a scheme executable also includes a full scheme interpreter, and it's only smaller because scheme as a langauge is smaller than CL. >install and configure emacs You can use any text editor for lisp. I used vim for years without issue. If you are desperate for emacs, there are distributions that include all of the lisp stuff and don't require any config. Lispbox includes a configured emacs, quicklisp, and common lisp implementation. >install and configure quicklisp >install and configure asdf These are the same step and involve running two shell commands. One to download quicklisp, and the other to run the installer. You can achieve it in one step if your distribution packages quicklisp. >So much stuff you've got huh? Not enough? Take hello world with whole interpreter implemented. The only reason this would be a problem is if you where compiling you hello world, which is completely pointless since you aren't distributing it to anyone. This exact same criticism applies to literally any other interpreted language, but very few of those even give you the option package the interpreter with the code. You just have to supply both separately.

>>31625 >You have to use the JVM to run code, CL and Scheme give native machine code The JVM compiles bytecode to native code in almost the exact same way a CL implementation would. You can even statically compile it straight to native code if you want to throw away the benefit of the JVM. That the source of overhead comes at startup when class files are loaded and code is being JITed, and at runtime when dynamic type checks and large quantities of garbage collected allocations occur. Here's a benchmark of CL vs Java if you don't believe me: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/lisp.html It's a roughly even split between CL and Java.

>>31635 >>31628 Ok, lainanons. I appreciate your help and support. But maybe lisp is not just for me. Maybe I'm too dumb to use lisps. Maybe I'm too picky and I shall stay at learning mainstream soykaf like python. Python is kinda ok for most of the stuff I regularly do. But it's boring. I just wanted to find my favorite language. I've been looking for something special. And nothing got me like lisp. Nor C-thing, nor haskell, nor java(script). You know lisp is kinda romantic. Lisp hacker sounds cool. And I really appreciate you code lisp despite its unpopularity. But what I like more is that you've found a language you love, in which you really enjoy programming.

>>31655 >"curse of lisp" I've seen this and many other pieces of content which attempt to explain why lisp's power leads to it's downfall. You see the same things about FP and whatever else the speaker is selling. I've come to the conclusion that power isn't very useful for writing programs and isn't as easy to measure as people think. >no docs, no modules, no much of IDE integration I think this isn't as bad as you think. Clojure for one piggybacks off of Java's ecosystem. Lisp docs tend to be alright, if not great. IDE integration is rather good through emacs. It isn't stunning by any means, but I've seen much worse. >Lisp force you to think different Thinking different is a fun exercise, but not super useful for writing code. It is useful for when you don't understand how to program as it forces you to actually think about the capabilities of the machine and how you can utilise them. Once you have learned programming, thinking different isn't really as useful as it could be because you can already do it. Once you know the limits of a system you don't need to explore them anymore.

>>31652 >SBCL is more like a JIT than AOT Not with block compilation.

>>31661 So what does it mean? Lisp is not needed? Lisp shall be good old passed past? You say there is no reason to learn lisp, because "modern" languages already have all the goods lisp provide? Tell me, what is your thoughts about lisp? Why are you here? Do you use it? Do you think lisps would ever be popular again?

Not the same guy but >>31670 >Knowing you don't have to keep up with insane ecosystems like npm or crates has no price. lmao @ the irony. What is quicklisp? So being S T A N D A R D I Z E D is the desired quality here? Then essential qualities such as a package manager, thread support, and network support to name a few being experimental and informally adopted or existing in dozens of unmantained libraries could be a bit of a problem, right? Shall I remind you that Lisp wasn't standardized for several decades? I guess it wasn't at all powerful back then, it only became so by virtue of being frozen by ISO. Come to think of it, I think ISO killed the lisp.

>>31679 >My point is that it is very similar, so there clearly exists a demand for things such as lisp. That similarity is a meme not backed by facts, though. The Lisp family (a concept that didn't exist back in the days where dynamism was its main point) is defined today by using s-exprs (including some syntactic sugar, I guess) to get homoiconicity. >I appreciate the need for a standard, but it isn't the be-all and end-all of a programming language. I know, but it's a step any serious PL (that can be used in software that'll become legacy) should clear at some point; preferably after some quality retrospective. >Lisp didn't solve the dependency hell issue through any feature. It solves it by not being popular enough to have a lot of packages. See >>31676 I agree but the means don't invalidate the end, here. >Runtime compilation is called JIT, and is everywhere nowadays. Yeah, I meant user callable runtime compilation via (compile). >I'll admit lisp's compilation model is one of the few remaining features it has, but this is only present in CL. I'm one of those guys who equate Lisp with CL; it is after all what it was made for, to unify Lisp. I don't think we're that much in disagreement, even if I'm a bit caustic because that's the privilege of imageboards. I just don't think you can say that Lisp is nothing special anymore and that modern unstable monstruosities like Rust are comparable. Even beyond pure tricks and concepts, general quality of design is almost as important and CL is quite good on that front (especially fan of lambda lists, coming from C/C++/Python/Tcl). But to be honest, the most major point for me is that s-exprs look right to me; can't unsee it once it clicks.

>>31680 >monstruosities like Rust I was using Rust as the bad example (as one tends to, god knows I hate Rust). From what I've seen and heard, Wolfram and Julia manage to be much less hellish about their macros than Rust is. >But to be honest, the most major point for me is that s-exprs look right to me; can't unsee it once it clicks This is the big one for me as well. Love dem brackets. I suppose this is half the reason I'm so conflicted about it. Everyone else is chatting up how it's the most powerful programming language, but the main reason I use it is because it looks nice.

>>31684 > but the main reason I use it is because it looks nice. I started to learn python bc the name sounds nice other anon

>>31680 >>31684 To be fair to Rust, it's trying to introduce a lot of high-level abstractions to low-level systems programming. It doesn't quite succeed at either, but the attempt is admirable. On that note, I wonder how feasible it would be to have a Lisp dialect with a Rust-style borrow checker. Being able to take care of memory-management (mostly) statically would be a huge boon to performance.

>>31691 > Being able to take care of memory-management I'm not sure it's quite lisp-style. Lisp is about high-level programming, it's not C. As I can tell lisp was made to prevent any sort of low-level machine deals.

>>31669 >>macros and conditions > Those are the two features that lisp has left, but they aren't even really lisp features. CL is the only widely used lisp that does both. What about debugging, or is that what you also talk about when mentioning conditions? IMO conditions, restarts and just plain old debugging are very different. The first thing that convinced me a year ago to port all my soykaf to CL was the debugging features. Interactive stacktraces, copy-pasting live variables to the REPL & the pause/resume when soykaf hits the fan: recompiling some function after having tested it in the REPL and the program fuarrrking resumes like nothing happened. This is what made me fall in love with this language instantly. I'm still fighting with CLOS MOP, but everything else is fine for me to say the least, and more often than not better than what I experienced (once I wrapped my head around it) considering all the languages I payed my bills with in the past 8 years... but my love is still fresh I guess. I mean if something is a pain in the ass and I don't want to have my mind occupied with that soykaf, CL is flexible enough to create fast solid workarounds, and that's definitely an understatement. Are there other languages that boast this level of interactive programming/flexibility? Because if some lang can beat this (and I'm programming solely in CL, besides the occasional bash script and what not) I'm prepared to love something else. The generics, the scoping, the MOP (even though I am soykaf at MOP, I use & read someone else's library and see what it accomplishes)... I mean the love is real, CL really opened my eyes to how much fun programming can be.

Does it make sense to learn lisp now? What kind of profits can there be? (besides the knowledge of universal zen, I would like to know about the practical application)

>>31728 Lisp's macro system has the practical of keeping the language focused on business logic in a way that functions cannot do. For example, I made a rules engine for a game in Common Lisp and a "defrule" macro, which includes (among other things) a list of parameters and access to a couple control-flow-changing allow/deny operators. Because of the macros, I was able to change the mechanisms of how rules work without altering the rules themselves. SLIME/SLIMV/SLIMA/(whatever SLIME variant your editor has) for Common Lisp enables me to keep a lisp session running so that I can develop code one function at a time and see the effects immediately. This tightens the dev cycle in a way I just can't experience with the languages used in my job -- best that can be offered is Unit Tests. For practical applications, I hear Clojure is a good enough lisp, and gives you access to the full Java ecosystem. Common Lisp in the present is a path less beaten, requiring most folk to work for the functionality other languages have libraries for. It also has a specifically janky relationship with JSON as NIL is both CL's "null" and "false", so each library does something special to compensate for it. It would probably only make "business sense" to use it in completely new fields, so that other languages don't have an ecosystem advantage.

Hello. I am a C programmer and I'm new to lisp. Scheme is the only lisp I know. I first learned lisp with SICP, but I stopped at the end of chapter 3 to read TSPL 3rd edition (it was necessary to read something that teaches Scheme, while SICP uses Scheme, it does not teach Scheme, it only uses Scheme as a tool to teach computer science topics). I am liking the language a lot and I'm using it to design and learn algorithms. I have some stuff I want to discuss: 1. I use vim as editor and chibi as Scheme interpreter. Trying emacs is on my plans, but I may not do it any time soon. I found chibi a bit slow, both for initializing and for finding undefined objects in the environment. Do you recommend another interpreter that is both minimalist and I can hack? I tried to read chibi's C code and I like how it is implemented, and the code is very readable. I want to implement a Scheme interpreter in C later and code minimalism and readability are some stuff I look for in a scheme interpreter. 2. I have noticed that there are (at least) two syntax forms for defining stuff: one for defining regular objects (`define`) and another for transformers (`define-syntax`). It got me thinking: What if transformers/macros were a first-class citizen? What if I could define a macro with the same syntax form I define any other object? What if I could define a transformer and pass it around to procedures (like `(map and ...)`)? Is that possible and feasible; and what would be the consequences of that? I heard about fexprs[1], which was a thing in early lisps; why is that not used in modern lisps? 3. I'm at the 4th chapter of SICP and I have just implemented environments and frames, and the procedures that change/use them (define, set! and var-lookup). One of the exercises asks us to write a counterpart for `define`. It ask us to implement a syntax form to "undefine" a variable from the environment. We can do that by either removing a binding from the first frame where it is found, or we can remove the binding from all frames. It also asks why/how such a "undefine" syntax is necessary or useful, and ask us to justify the choice on the frame to remove it from (first found/all). I implemented the "undefine" syntax on the first frame found (it was easier). But I have no idea on how a counterpart for "define" can be useful nor can I justify the usefulness of the option I chose. So is a "undefine" useful and, if it is, how should it work (by deleting the binding in the first frame or in all frames)? 4. I am soon to end SICP and I want to do it's last exercise (implement Scheme in a language like C). However I want to do more. I want my lisp to have some characteristics Scheme does not have. One of them is function currying. Running ((my-proc a) b) should be the same as running (my-proc a b): if my-proc is a procedure expecting two arguments, running it on a single argument would return a procedure expecting the last one. However, I have no idea how could variadic-length argument list work on that. Is there any lisp with function currying? How do they deal with variadic arguments? [1]: https://en.wikipedia.org/wiki/Fexpr

>>31726 >CL really opened my eyes to how much fun programming can be Understatement, it's a cure for work induced "fun programming" slump.

>>31713 Thanks, looks really useful. Now I just need a way to compose it with interpol.

Guys, I'm not sure Common Lisp is for me: after taking the time to understand some of the intricacies of its model of evaluation, filthy unhygienic macro system, fully object oriented programming environment, and learning the style of incremental, interactive development, I am worried I am going to find every other language to be completely underpowered anemic horse-soykaf. I'm not sure what to do. I guess keep learning Lisp.

>>31753 Welcome to the club

>>31753 Common lisp is the best programming language. But other programming languages are good enough for a specific purpose. Erlang / Clojure are good enough for concurrent stuff. Python / Lua are good enough for scripting. Fortran is good enough for scientific computing

>>31728 Even SLIME isn't very good, so I never really used the advanced debugging features all that much, because I couldn't always get them to work in the environment I had, but even then it's nice to be able to INSPECT a value from the debugger to see what's wrong with my function manipulating it, or to use macros to automate away a lot of work. Other programmers use debuggers just to test that functions work, but I can use the REPL to remember whether something about how my function works, or whether code will work correctly well ahead of time. >>31736 >Unit Tests Right, I'd forgotten those using inferior languages call basic tests possible at an REPL by that name. >For practical applications, I hear Clojure is a good enough lisp, and gives you access to the full Java ecosystem. So does ABCL. Read this: http://www.loper-os.org/?p=42 >Common Lisp in the present is a path less beaten, requiring most folk to work for the functionality other languages have libraries for. I just write every library I use. >It also has a specifically janky relationship with JSON as NIL is both CL's "null" and "false", so each library does something special to compensate for it. I don't see the sense in even mentioning this. JSON is like kicking dead whales down the beach. >It would probably only make "business sense" to use it in completely new fields, so that other languages don't have an ecosystem advantage. I use Common Lisp for some tasks, purely because it's the language I know most well. >>31753 Do what I did and also learn APL and Ada.

>>31774 > I use Common Lisp for some tasks, purely because it's the language I know most well. Are you as old as an dinosaur?

>>31817 Look at this youtube playlist https://www.youtube.com/watch?v=i66wYiG_5bk&list=PL2VAYZE_4wRITJBv6saaKouj4sWSG1FcS&index=75 CEPL always looked really cool to me, but I've never actually used it so I'm not sure how much it supports. Still, it looks really easy to use in those videos.

>>31872 It makes certain things easier, like access to large, complex, and pre-optimized libraries in other languages, almost always C. It's less optimal than having a pre-made lisp system that covers a problem domain, because you need to wrap the program in FFI calls, and take care of converting alien datatypes to lisp datatypes and back. Less work than implementing something from bottom up, not not exactly a free meal like a preexisting system. Typically, IIRC, if a library is C++, you have to write a C wrapper to use with something like CFFI, or just use Clasp, which sits on top of LLVM and interfaces nicely with C++.

>>31973 >tested by people You're thinking about people-tested. Time-tested is just asking if it stuck around. Lisp is more time tested than any language except Fortran because it has been around the longest, even if it hasn't been used by the most people.

I have a question. Is there any AOT-compiled LISP which makes it very transparent how my code is going to compile to machine code? Or a JIT LISP which is specifically focussed on making it easy to determine which machine instructions are produced? I don't really understand the point of this "homiconicity" thing yet; it's more "abstract", or perhaps just "high-level"/Layer"ed than what I usually work with. FWIW, I'm looking for ways to compile my code that are bijective, e.g. bit-for-bit reversible, without needing to include much or any debug symbols. I believe this to be the key to *making it possible in the first place* to produce highly efficient compilers and highly efficient code; transparancy all the way down to the machine code, and the related elimination of "abstractions" (e.g., inadequately-understood-crufy-placeholder-terms).

>>31975 Lisp is kind of an odd bird when it comes to abstraction. Compared to C, it's much higher level, but about as simple from a technical standpoint. It's got a very small set of core features, with the rest of the language built atop them.

>>31978 So perhaps I could start from: https://github.com/jart/sectorlisp ... and layer my "machinecode-centric Lisp" on top of that, and then modify the base as necessary... How quaint! Yes, I tend to forget how close-to-the-metal or at least primitive-as-in-simple Lisps are in actuality, the traditional (((syntax))) of them always throws me off. Thanks for the little push, wouldn't have found this "new" super tiny Lisp otherwise. And btw., do you know of another word for what you call "level of abstraction" there? Perhaps eh... "degree of freedom"? I don't use black box models anymore, and I have "abstraction" stubbed out from my vocabulary; this saves me the headaches of thinking about things which per definition are not real and do not exist.

>>31974 >tested by HDD platters You're thinking about HDD-platter-tested. People-tested is just asking if people remembered it. Lisp is more HDD-platter-tested than any language except Fortran because it has been on HDD-platters the longest, even if that is a really obscure and not that broadly useful way of evaluating a language.

What's the community's take on Racket?

>>32176 >Racket

>>32176 It suffers from the same problem as Scheme macros, but hundredfold. It's a playground for ivory tower academics without any aesthetic sense. But otherwise, with its builtin portable GUI, useful libraries and now that it's based on Chez, it is a good choice.

>>32131 That's super cool, when you get a bit further along you should share it online in a few places, I think it's the sort of thing that would gain traction on more mainstream platforms.

should i try Scheme or Common Lisp if i am a complete layman wanting to learn lisp? are there any concepts which can be easily misunderstood and cause a lot of time barking at the wrong tree? thank you a lot

>>32472 >should i try Scheme or Common Lisp if i am a complete layman wanting to learn lisp? The choice doesn't matter much. With Scheme, you must pick a good implementation like Guile or Chicken. Racket is also a good option (but it's a different dialect of lisp that's based on Scheme but Racket has evolved to a different direction). Scheme implementations often provide features that are specific to 1 implementation (there is more fragmentation in Scheme than in Common Lisp). Also, Scheme is a small language, whereas Common Lisp (and Racket) provide more programming tools/features. I recommend that you start with Little Schemer (it can be worked through using Common Lisp as well) and continue with either Seasoned Schemer or Common Lisp: A Gentle Introduction To Symbolic Computation (or https://gigamonkeys.com/book/). >are there any concepts which can be easily misunderstood and cause a lot of time barking at the wrong tree? I was told to avoid macros, unless you know that you should use them. Also, Common Lisp and Scheme (but perhaps to a lesser degree) are multi-paradigm languages (and they support pretty much any paradigm, not just functional programming). The difference between: EQ, EQL, EQUAL, EQUALP and = is going to cause some confusion at the beginning (Scheme has eqv?, eq?, equal? and = instead). In short, these predicates (tests or questions) test for different kinds of equivalence (the ending "P" in equalp or "?" in equal? mean that they are predicates). The difference between these predicates is easily explained at this page: >https://eli.thegreenplace.net/2004/08/08/equality-in-lisp (see the summary at the bottom). In beginning, you only need to know = (for numbers) and equal (for everything else) or equal? (Scheme). The Little Schemer explains these differences in easy way (it also teaches you to use recursion, if you haven't used it much. Plus it has really helpful "commandments" and "laws" for programming).

I' m new to Common Lisp. I don't get what are property lists (plists) used for? And how are they different from a key-value list?

>>32539 Like alists, they're historical baggage to get around the fact that hash tables are poorly integrated in CL (mainly no literals).

>>32539 The in-practice use case for plists is keyword arguments. Whenever you start writing any form that ends with `:key value :key value` items, you're writing a plist as the tail of that call. DEFCLASS is a good usage example of both plists and alists. Every slot definition is a plist with the name of the slot tacked to the front of it. After slots, you get to write down an alist of options for your class, such as (:documentation "blablabla") and the like. >>32540 Even if hash tables had literals, both plists and alists have practical real-world use: Tiny-scale associations may have a faster time living in lists when the cost of hashing the keys do not outweight the O(1) access benefits. Alists' reader function specifically returns a cons cell of the association, which enables code to keep the association and mutate it should they need to. Hash tables are limited to the pre-baked eq, eql, equal, and equalp equalities. This works well most of the time, but list-dictionary accessors can use custom test functions where hash tables can not. Common Lisp is a multi-paradigm language, so it's no surprised there's many ways to skin the same cat.

>>32575 > though would it be (partly) possible to implement alternative hash tables as a library? We do have #'sxhash, and while it won't be as good as having a sane hash table API from the beginning, it would be likely better than nothing. That's what I plan to do one day. I'll use chained hashing instead of open hashing, so MT access only needs to lock the bucket; and I plan on doing some kind of parametric typing to choose the bucket container (list, adjustable vector, two adjustable vectors with one containing the hash value when you want to store stuff like strings with a heavy comparison function, etc...).

>>32896 I don't use Wayland or care about it very much but it's great to see more work being done on adding backends to McCLIM. I believe there's also an SDL backend in the works, meaning it could soon be portable across OSes

>>31696 >In practice it's got a fair share of issues, but the idea is an interesting one. Reference counting, however static or dynamic cannot replace a garbage collector in all use cases. In fact many reference counted languages will either restrict the creation of circular and similarly complex data structures, also use a GC, or neglect that use case entirely. Also keep in mind that forms lazy collection (such as a GC) can improve throughput.

>>31738 >I heard about fexprs[1], which was a thing in early lisps; why is that not used in modern lisps? Because it makes all forms of static analysis and thus optimization impossible. >So is a "undefine" useful and, if it is, how should it work (by deleting the binding in the first frame or in all frames)? By making it possible to remove mistakes? I haven't read SICP but I assume it allows a programmer too move definitions to a higher frame, access a definition in a higher frame that was previously shadowed and remove an unwanted definition making it an error to use it anywhere anymore. >One of them is function currying. Running ((my-proc a) b) should be the same as running (my-proc a b): if my-proc is a procedure expecting two arguments, running it on a single argument would return a procedure expecting the last one. A minor nitpick but that's called auto-currying. >However, I have no idea how could variadic-length argument list work on that. Is there any lisp with function currying? How do they deal with variadic arguments? Rascal if you stretch the definition of lisp a bit. A lisp with auto-currying doesn't work, you have no way of pragmatically telling if supplying an optional or rest argument will affect the output (and sides effects) in a liner fashion such that it is possible to supply it later. You could probably achieve your goal by creating a lazy lisp: every function call returns a thunk, on which you can either force computation (explicit, i.e. display the result) or create a new thunk by applying it to one or more new arguments. Once computation has been forced, the thunk is replaced with the result and it is an error to apply it to new arguments. Such a lisp may aide your goal of first class macros. Lisp users usually solve the problem by writing a nice macro for manual currying.

>>32981 Are you the guy doing the McCLIM port?

>>31415 Beginner question here. Recently started getting into Emacs. What can elisp (Emacs Lisp) actually be used for? Perl is good for regex and general sysadmin-type things and can be fun to use alongside bash. Python is good for working with machine learning from what I hear. C or Rust as good for low-level applications programming etc. You get the idea. Is elisp purely for customising one's Emacs client? It wouldn't seem much of a compelling motivation to learn it if so. I'm curious about what I can do in elisp; I'd love to hear what sort of programs or scripts other lainons have built, and why they chose to write it in elisp specifically.

>>32982 No, that wasn't me. Someone else beat me to the punch there. I'm building a library to replace libwayland so that it matches better with lisp, while he used bindings to libwayland instead.

>>32986 Sounds really interesting! Please do post a link as soon as you're ready, I'd love to check this out 🙂

>>32985 >Is elisp purely for customising one's Emacs client? No but that is the major reason for learning it. Perhaps a better way of explaining it as a lisp geared towards programming for the Emacs interface. >It wouldn't seem much of a compelling motivation to learn it if so. Its fairly similar to most lisps such as Common Lisp or Scheme if you have any interest in the family. >I'd love to hear what sort of programs or scripts other lainons have built, and why they chose to write it in elisp specifically. I haven't written anything impressive. A few tools I've submitted upstream. However elisp has completely taken over all of my exploratory programming, general purpose scripting, anything that isn't intended for someone else to use. I use elisp so much because its the path of least resistance: Emacs is the ultimate elisp IDE and does a much better job at assisting development in it than most dedicated single-language IDEs. I initially picked Emacs because of its extensibility > it can give any language first class support but now I stay with it because of elisp.

>>32997 Will check that, thanks!

There's this weird thing about me. I'm very much interested in the lisp family of languages, but only as a system which I can study, not really as a tool I can use to write programs. I've never written anything in lisp because there is nothing I would like to write. But I like to learn about how lisp works on the inside, the theory behind it, and so on. Two of my favourite books are Lisp in Small Pieces and Art of the Metaobject Protocol. Of course it feels kinda pointless. I even feel like an intruder of sorts because I'm not going to do anything with that knowledge, nor am I going to benefit from learning this. As a consequence I've just read a few chapters from the aforementioned books because I feel I'm just kidding myself. I've even started reading some lisp source code as of late. But if I open Emacs with the intention of writing some lisp code... there's nothing. Not even if I decide on a cool project. I just don't get any actual interest in doing it. What's wrong with me? And what use could I make of this situation?

>>33077 I don't think there's anything wrong with you per se, it just sounds like you're more interested in pure computer science than applied computer science, like how some people are just into math itself rather than building things in that math. What about lisp tickles you in that right spot? The lambda calculus? Language design?

>>33078 I like to know and understand how a system is put together. I also like learning about the inner workings of the kernel, or details about the tcp/ip stack. It extends to math, which is my main area of interest. Actually I feel a disconnect between math and programming. I like lisp in particular because it feels veey "axiomatic", with a foundation on λ calc. But I can't translate my mathematical knowledge to lisp, much as I'd like to use it to cement my learnings. I've considered implementing something like a proof assistant in scheme. But as always, once I open the editor, my mind goes blank. I don't even have the theory to do that.

>>33079 There's no law saying that you have to program. You like learning about programming-related topics, and it's a source of fun and personal growth for you - you're already winning. You impostor syndrome, on the other hand, is hurting you, so ditch it and revel in the books that you like. >I feel a disconnect between math and programming >I can't translate my mathematical knowledge to lisp If you can see a gap where others can't, and feel frustrated doing something that should be straightforward, either you have brain problems or you have come accross a flaw in the current state of the art that's sitting in everyone else's blindspot. Programming is in its infancy, and yet, already plagued with bad ideas and concessions to mediocrity that have been cimented by habit, so by all means do follow that thread and see where it takes you. >I've considered implementing something like a proof assistant in scheme I figured proof assistants would be your thing. I take it you have played with one or two, and have a good idea how they work (I don't, myself). Digging into the internals of a program you like might motivate you to modify it, which could be a better entry point for you than a blank Emacs buffer. But, again, it's perfectly fine if that doesn't happen, either - you don't have to prove anything to anyone, except for a bunch of theorems maybe. Finally, I concur with the other lain: feel free to pursue the theoretical stuff or whatever happens to interest you. I'll throw some ideas, for whatever inspiration they may give you: - type theory. Have you checked out Haskell/Agda/Idris? You sound like you'd love them. - language design, as already said. Knowledge of Lisp internals prepares you for the more general task of writing interpreters and compilers, and once you know how those work, the sky's the limit. We could use some more imaginative people designing languages! - pointless stuff. Take, for example, this video I ran into randomly: https://www.youtube.com/watch?v=SrKj4hYic5A . In it, an academic type descends upon mortal programmers to give a talk on something that's entirely too hard to follow and either wholly useless or the key to finally getting programming right (recursive interpreters, composed of an infinite hierarchy of nested evaluators). My point is: have fun and scratch your itches!

>>33084 Thank you for the kind response. I will ponder on this.

>>31415 Are there any obscure lisps around? I know about Scheme, Common Lisp, Guile, ELisp, Fennel ... but I'm wondering if there are any super underground Lisp dialects hanging around to try out?

>>33097 InterLisp (https://interlisp.org/), pico lisp and newLisp come to the mind.

Hello guys. What are some must read Lisp books?

>>33215 Here's the abridged road to CL that I've taken: - Paul Graham's Practical CL - Avoid using Emacs/Vim unless you already know them. I got memed into learning Emacs (incl emacs lisp) at the same time as CL, which was hell and caused me to pause learning twice. Learn CL first, and if you think you're into it, then learn the tooling that comes with it. - CLHS. Specifically, the docset that comes with Zeal, an offline doc browser free for Linux. It's incredible how much more enjoyable reading CLHS is when lookups isn't slow and everything's indexed. - The universal third-party libs: ASDF+UIOP, Alexandria. After that, pick a small project in your comfort zone on the pro/g/ramming poster to get you comfortable with CL. After that, you may be interested in going back and forth between theory and practice like any other language.

>>33210 Actually, you know what, you're right. Enjoy continuing to be a weird pedantic autist on lainchan.

>>33219 PCL is from Peter Seibel, not Graham.

>>33224 Right, my mistake, I don't know why I thought Graham made it when I wrote that down

>>33436 The mentioned cookbook is pretty good for that at least. But be sure to start with those old books and read parts of the CLHS not just when you need it. >>33440 >Because how funky EVAL-WHEN is, it's strongly recommended to use something else unless utterly impossible to avoid. It's perfectly understandable, though. And often needed when you do macro (incl. reader macro) stuff. The part I had trouble with is the situations where it's not always needed: toplevel forms (http://www.lispworks.com/documentation/lw61/CLHS/Body/03_bca.htm). Basically, if you don't understand eval-when, you don't understand CL's compilation model and you should RTFCLHS a bit more.

>>33452 >>33455 I just use Emacs' hyperspec-lookup with eww, but I might try that Zeal thing, looks comfy.

>>33459 Oh yeah, and I made my own "cookbook" in org-mode (more exhaustive than the real one, but still not CLHS tier). Very useful.

>>33460 Care to share the org file?

Sorry but I'm really curious, I've seen this thread for some time. I've never seen this language until seeing it on SEL, what's so special about this? can this be useful in some ways? why do you learn lisp? sorry but i feel a bit lost here

Does anyone have a copy of Sketchy Scheme (4.5 ed)?

>>33956 While Smalltalk also has image based development (and even GUI integration with that concept, from what I understand), no other language has something equivalent to CL's transparent homoiconity through lists (thus trees) + unhygienic all-powerful macros + first-class symbol (and symbol interning) support; quasiquoting in the icing on the cake, but I wish it were user-extensible.

>>33959 >quasiquoting in the icing on the cake, but I wish it were user-extensible Surely it is if you redefine the reader macro for it. (let ((qq-old (get-macro-character #\`))) (defun qq-new (stream char) «body that translates to old format»)) (set-macro-character #\` #'qq-new)

>>33972 if you are going to port it, i dare you to use as pure lisp as you can, no FFI's

>>34012 nice name fella mess with the best, die like the rest

Has anyone read Sussman's new book, Software Design for Flexibility? How well does it compare in usefulness to SICP? It's available here for free https://mitpress.ublish.com/ebook/software-design-for-flexibility-preview/12618/C1 but I find this UI very unwieldy, so I'm considering dropping the cash on a physical copy. Is it worth the money? I leafed through it a bit, and honestly it looked over my head. It appeared at first glance a lot more abstract than SICP, which I suppose would be valuable if it turns out to be about something practically powerful instead of just whatever Sussman's new code style is. Otherwise I might have other books to get to first. (Asking here to avoid making a new thread)

i've read a lot of readme's for ffi's, talking about 'making it lispy' what does that mean, to be lispy? its making me wonder if im using lisp to its maximum potential

>>34017 Scheme: SICP is CompSci survey level SDFF is a Master Class of a new software architecture and you need MIT Scheme to follow along. The PCL or K&R of Scheme is: https://scheme.com/tspl4/

How come this thread is buried? Anyway, my question is: what are examples of high-performance Common Lisp programs? It is very often said that it is possible to write lisp code that competes with C++ in performance and optimization, but what are some examples of this?

>>34920 https://github.com/marcoheisig/Petalisp I suppose. But you're looking for benchmarks, from what you said. I started a CL version of Are We Fast Yet some time ago, here are the results: https://github.com/q3cpma/are-we-fast-yet/blob/common-lisp/benchmarks/Common-Lisp/results.tsv As you can see, SBCL trades blows with Luajit and Node in throughput.

>>34926 Kandria? It's a platformer video game, so quite sensible to latency ("soft realtime"). Otherwise, compilers themselves are probably your best bet. Now that I think of it, lisp-stat also qualifies.

>>35002 >Is Lisp community infested by trannies too? should be >Is the Lisp community infested by trannies too? Your inability to use articles narrows down what part of the world you may be from way more than you think it does. It also makes you look like a dumbass. With that said, why do you care what the "Lisp community" does? It's not like you're going to be using it for a job!

Even though I believe myself to have largely moved past the need to use Lisp, I still see the benefits, even with programs I well understand. As an example, I have a program with a very simple design, but in order to do much it will need to be able to load integral state from somewhere, and this requires a format for the state. This format is almost entirely specified, but not quite, and focussing on it too much is placing the cart before the horse. With Lisp, I can ignore the format for now. Still, this isn’t unique to Lisp; it’s mere consequence of an image. I intend to write a little pair of programs soon, one in Lisp and one in Ada, and the Lisp will use the condition system to good effect. My main criticism of the condition system is how the program must be designed to use it ahead of time, for it to work well, and idiomatic Lisp isn’t necessarily written that way. I have a little personal program I use daily that would benefit from more restarts, but I’ve realized it must be entirely rewritten to properly integrate them. Regardless, I can foresee how pleasant one program will be with it; designed from the beginning to leave all possible error handling to the condition system, the main interface for it will be the debugger; this isn’t an acceptable interface for a general program, but will more than suffice for an early version. It will gradually wear down its input in this way until no errors remain and it passes. One part of the language I continue to rarely use is CLOS. The OO ways are different from the Abstract Data Type approach, and I rarely see the point. Some ADTs are so simple that one may as well cobble them out of CONS and a few functions instead.

>>36351 The problem is of eval itself being slow, not the implementation, since the compilation (which will be slow for optimizing compilers, duh) is done at runtime instead of macro-expansion time. Of course, it's different in interpreters (which are quite rare, usually you get bytecode compilers), since everything is slow. >s7 Looks nice. Does it support the current r7rs-large or only small? >>36352 Or add a newline (~%), probably.

Is there a standard way to include documentation strings with variables in scheme? I want to be able to write an equivalent of the following common lisp function: lisp (defun hello (name) "Say hello to `name'." (format t "hello ~a !~&" name)) I'm trying to build a literate programming environment, and it would make it simpler if I could just pull documentation strings out from the functions instead of having to look outside of them. Search engines are useless nowadays, but I tried looking through the SRFI's and didn't see anything like this. I figured this would be a common request, but I suppose not.

>>36389 Just steal what Factor does with its docs if you are serious about literatre programming They store much more than strings https://docs.factorcode.org/content/word-scan-new-word%2Cparser.html All of this is clickable as they are presentations which is what you'd want to go for

http://dpk.io/r7rswtf tl;dr R7RS-large is dead (and Chez is till R6RS, anyway) Come home, white man, away from your fragmented hellhole.

>>36813 >come home white man, into the waiting arms of autistic tranny No. 11782 uhm no thanks

>>36816 If you haven't noticed, that's the state of the entire programming community outside boring industry tech like C++/Java/Ada.

>>36813 Large languages are unnecessary, R7RS-small is all you need. >I wrote in my statement requesting the Steering Committee consider me a candidate for new chair >Daphne Preston-Kendal You can just tell by the name lmao. Either way, I don't really care if R7RS-large is killed/co-opted by trannies. It's been stalled for a decade, if people were actually interested it would've been finished and ratified years ago.

>>36813 How's the latest revision of common lisp doing, out of interest? Is it coming soon? or will the language remain in it's current unenviable state?

>>36819 >You don't need a full numerical tower lol Enjoy making toy programs that do nothing or depend on a single implementation with a bus factor of 1, I guess. >>36820 >unenviable Right. This frozen spec is what allows compiler efforts to be concentrated on the actual compiler, and not catching up with a rolling Katamari like C++20/23. Proper macros allow us to have most of what's missing, anyway. What would be nice would be Julia like JIT specialization that allows it to have throughput and genericity everywhere, but that has its problems too.

>>36827 >>You don't need a full numerical tower lol This is something that most programs genuinely don't need. Pretty much the worst example you could give lol. >This frozen spec is what allows compiler efforts to be concentrated on the actual compiler And what great news that is for Scheme which is about to get all of the brilliant benefits CL does from having no active development on the language. They'll be so much better off once new versions stop coming out. >What would be nice would be Julia like JIT specialization Should be easy, given how focused compiler writers are focusing on improving performance instead of that rolling katamari standard.

>>36827 This, specifically the second part. One of my favorite things about Common Lisp is that I know that properly written code will never break.

>>36836 >And what great news that is for Scheme which is about to get all of the brilliant benefits CL does from having no active development on the language. They'll be so much better off once new versions stop coming out. Unlike R7RS-small, CL contains enough to be usable in its current condition. >Should be easy, given how focused compiler writers are focusing on improving performance instead of that rolling katamari standard. >Just convert an optimizing AOT compiler to JIT, duuude I'm pretty sure the CLOS semantics are too dynamic to allows that in an AOT fashion. And there is actually work done on generic method dispatch: http://metamodular.com/SICL/generic-dispatch.pdf How hard would it be for something like SICL or Clasp to exist with an ever evolving standard? Anyway, you weren't arguing in good faith, I only replied because I'm bored and imageboards are too dead.

>>36844 >How hard would it be for something like SICL or Clasp to exist with an ever evolving standard? Believe it or not, other languages have self-hosted and LLVM compilers. >CL contains enough to be usable in its current condition Most of the Scheme implementations I've seen are quite usable. Mainly because they extend the standard in different ways, something which I can only wish CL implementations bothered to do. There's an argument for portability on CL's side, but that basically goes out the window ones you realise a huge number of important libraries are FFIed. Scheme's SRFIs also allow the language to be extended in semi-portable way, much more than I can say for CL. >Just convert an optimizing AOT compiler to JIT, duuude That isn't exactly an unreasonable request after 30–40 years of focused development. It should already have some kind of JIT capabilities since it accepts and compiles input on the fly. I don't think you have actual evidence that the language standing still improves compilers in any way. >I'm pretty sure the CLOS semantics are too dynamic to allows that in an AOT fashion I can see eql specifiers causing issues there, but other than that not many problems. The bigger issue is common lisp's weak typing when it comes to numbers. Adding two fixnums doesn't always result in a fixnum unless explicitly stated so operations have to box. Given that, I doubt there's any way to optimise CL code without type annotations. There are a huge number of pain points like that, just begging to be fixed in a hypothetical CL2 which is never coming. >Anyway, you weren't arguing in good faith I always find posts like this funny. Accusing the other person of arguing in bad faith might as well be the definition of arguing in bad faith. There is a big difference between a sarcastic argument and a bad faith argument, mine was the former.

>>36850 >That's sane behaviour I don't think it is. Overflow simply isn't an issue, requiring that all integers be boxed to avoid is is an obviously bad trade-off. What's more, solving this problem is a guaranteed win. Let's say you add a new type of fixed size integers. All the existing code with arbitrary ints will work just fine. Then all of that code can be extended to run faster by passing fixed ints. Existing code has to be written to use either a fixed size or an arbitrary size integer, but code in the new system would work generically on both depending on what the user passes. The tedious work of re-writing functions with type annotations is completely automated. >CL2 is indeed never coming This is where you're wrong and it's my principal point of contention. CL has flaws in it, and eventually someone will decided to fix those. CL2 is coming, but it will not be called that. If CL was open to updates, these fix could be added gradually to the base language and in a way that maintains backward compatibility. Instead, by being closed off, CL all but guarantees that whatever replaces it will not be compatible. >Clojure loses much of the magic just to suck funcional purity dick and ride the JVM train Swearing at things you don't like won't make them go away. Being compatible with all Java libraries is a huge boon and many of the functional aspects of Clojure are very good. My experience with Clojure has been much better than with CL. >pretending that CL isn't the least worst we have in the Lisp world is misguided You think CL is the best lisp, but best at what? Most of its benefits seem relatively niche, whereas its flaws smack you in the face as soon as you open a REPL.

>>36902 >What it lacks is parametric structs/classes. This is what I meant and you know it. >Perfectly normal: declarations are like pragma, left to the compiler to do what it wants. In practice, SBCL does. Not what I was talking about. The standard's definition of function types means that they can not be properly checked in a conforming compiler due to the aforementioned incorrect argument variance (function parameters are co-variant in CL but contravarient in correct languages). >What do you even mean by that? forall t . t -> t They are also called quantified types, though I wasn't asking for existential ones so it makes sense to just refer to the generic aspect. >I don't know what you mean. Function arguments are usually contravariant. This means that if you have a variable declared with a function type Dog -> Dog, you could assign it a function Animal -> Golden-Retriever. The result is covariant, you can assign any subtype of Dog to it, and the reverse is true for the parameter – you can assign any type which Dog inherits (eg Animal) thus making it contravariant. In CL, the arguments are both covariant. So you could not assign an Animal -> Golden-Retriever, but you could assign a Golden-Retriever -> Golden-Retriever. >is already better than C/C++ >we beat the crippled old man Not an achievement.

>>36903 >Not what I was talking about. >But I would assume it does correctly type-check programs. Type-checking in CL has no such guarantee Are you seriously implying your edgecase means CL can't type check programs? >This means that if you have a variable declared with a function type Dog -> Dog, you could assign it a function Animal -> Golden-Retriever Doesn't sound particularly useful to me, even if correct. Why not type it as Animal -> Dog in the first place if you want that behaviour? Still, interesting concept, thanks. Anyway, you DID go full ML retard on me with your type fetishism. Yes, ML family PLs have better type systems than CL, nobody ever denied this. But CL's type system and SBCL's static typing facilities still work well in 99% of real world situations, and pretending it's unusable just because it's not called Idris2/Liquid Hasjell is disingenuous. And my criticism of Clojure's core.typed was never about its type system, was it? It was about being basically an ugly testing addon competing with another solution instead of being built into the compiler, where it belongs (for advanced inference and optimisation purposes, to actually replace Java's poor type system).

>>36918 No, this I understood (that the covariance was standard), but your example relies on inference to determine that having ash means the function should only accept integers. And inference isn't specified anywhere. >This is intentionally how the system operates and it is relied upon to work that way. Well, it is retarded then. Fortunately, you can still type your functions correctly, the problem being that you can type too generally. >But really, including production-ready here is ridiculous. It's basically saying: CL is the best lisp if you discount all the more practical lisps that are less theoretically pure and all of the lisps which are better theory but that don't have an ecosystem. Why is it ridiculous? It's pretty normal to want a rock-solid language with multiple implementations. Or at the least, one with a reasonable bus factor. >Clojure We won't agree on the sanity of Clojure's type system which isn't even part of the core languaged (unlike runtime spec) and in a strange state (core.typed vs typedclojure). It's simply not ready to be used stably. >Racket Huh, I should at it more often, I guess; always looked at it as "that Scheme that's not a Scheme anymore for ivory tower academicians". Especially since it switched to the Chez backend and has compatibility/defmacro too. How is its library world compared to Quicklisp? Geiser vs SLIME/Sly? Any good resources to learn about it (in a practical way, I'm not developing a new #lang).

>>36922 >your example relies on inference to determine that having ash means the function should only accept integers. And inference isn't specified anywhere. You don't need to infer the type of the function, you just need to look at the declared type and see that the function is stated to take numbers, therefore it should be valid for any number passed to it. You could do this if the standard defined function types correctly. >It's pretty normal to want a rock-solid language with multiple implementations No it isn't. More popular languages are more likely to have more implementations, but people don't want languages with more implementations. It actually seems like the languages with the most implementations (C, C++, CL) are the least liked, while languages with the fewest (Rust, Clojure, Typescript, Julia) are the most liked. >Why is it ridiculous? Because your core argument is that people should use CL because it's the best lisp we have, even though it isn't the most practical. To then turn around and say "there might might be a bunch of better lisps but they are less practical" is just giving up your original argument.

Why are some people embracing the stability and matured ecosystem of cl ( https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#s3-consequences ) while others think they need a more modern language for the current software landscape. https://github.com/cl21/cl21 https://github.com/coalton-lang/coalton Even when using the same language they don't agree on the future and the next step. What lainons think about this matter ?

>>43707 It takes personal courage and conviction to use a tool that's old, few others are using, and won't help you get a job. You have to really want it. Most people never pick a programming language to learn; they just learn what school or work expects of them. It's also harder to use a language without a ton of batteries included. If you want a library and it doesn't exist, it's on you to write it.

Hello Lisp enjoyers, I'm a Haskell enthusiast and I wanted to read more on it from the point of view of the more old tech loving, Linux-appreciating, etc side of the IT "community" on the Internet (which Lainchan is a part of) but I noticed there's no Haskell thread. Why's this? Is Haskell not practical enough? Not useful enough? Just not popular enough and as such the lack of active Haskell users explains the lack of a thread here? I know this is a pretty banal question(s), so I didn't want to make a thread. Also, if any of you has Haskell resources you'd like to share I'd appreciate them. Sorry for the thread derailment in advance. My fixation for Haskell is driven by my preference for mathematics over programming, not that they're too far away from each other.

>>43898 You talked about Haskell and practicality. If to talk about practicality and FP in general, I'd say: Ocaml > Haskell > F* >= Idris >= ATS >= Clean > LEAN > Agda Ocaml has more libraries, money, documentation, industry interest, support Haskell has libraries but many of them are abandoned, focused on types, poor in practice, now useful, documentation sometimes is very poor, compilation is super slow, it requires 1+ Gb, executables are big Clean is fantastically fast in compilation, it supports affine types, it's simple and now lambda calculi based (but term rewriting based) Idris has small number of libraries. It tries to translate Idris to C, JS, I think Agda is more for play with types, some kind of proving. ATS is just fantastic: it compiles super-fast executables, sometimes faster than C, it supports linear types, dependent types, refined types, theorem proving - and everything in ATS! Currently its author is developing new version which will be "different" (simpler). Also there are different small effects-based languages, SML implementations (CackeML is interesting), Lisp 1/2 family - but Lisp is another universe comparing to the world of ML/SML (Ocaml, Haskell, ATS, etc). F*, LEAN more oriented for proving, but they also can be used in translating mode (to C, for ex). So, I would not say that Haskell is more practical comparing to Ocaml, no, it is not. And definitely not more practical than Lisp family (Clojure is very practical lang, Common Lisp, some Scheme implementations). Haskell sure is in the first 50% of practice, but it is not the first one. It's my 5 cents after ~10 years of usage of Haskell.

>>43923 Idris primarily targets a Chez Scheme backend, but there are C and JS backends too. Idris tends to be my language of choice these days, coming from LISP. >>43898 I think quite a lot of it stems from the fact that Haskell isn't a language you can just "pickup". LISP is much easier to learn and use when coming from other languages, not to mention the "cool factor" LISP holds over other functional languages in general.

https://github.com/a11ce/docker-lisp

Hello Lisp enjoyers. I have a noob question regarding Common Lisp. I am trying to write a function to mirror a nested list as shown on picrel. I wrote a recursive version of reverse as a helper and made sure to include end tests but I cannot get it to recurse over a nested list for fuarrrk's sake (defun mirror (tree) (labels ((reverse-rec (n tree) (cond ((zerop n) (list (first tree))) (t (cons (nth n tree) (reverse-rec (- n 1) tree)))))) (if (atom tree) (reverse-rec 0 (list tree)) (reverse-rec (- (length tree) 1) tree)) ; These final recursive calls should be ; nested inside a cond clause with end ; tests I suppose (cons (mirror (cdr tree)) (mirror (car tree))))) I would be grateful for explanations of car/cdr recursion in general. I have an understanding of recursing over ordinary lists but didn't quite get car/cdr recursion on trees

>>43999 Same Lain here, I have managed to solve the problem and would like to share my little moment of enlightenment. (defun nestedp (x) "Returns T if the input list is enclosed within two or more levels of parentheses." (if (listp (car x)) t)) (defun mirror (tree) (cond ((atom tree) tree) ((null (cdr tree)) tree) ; if input is a 1 item list, leave as is (t (append (if (nestedp (cdr tree)) (list (mirror (car (cdr tree)))) (mirror (cdr tree))) (list (mirror (car tree))))))) CL-USER(224): (mirror '((a b) (c (d e)))) (((E D) C) (B A)) As before, alternative solutions and suggestions on learning materials are very welcome

>>44017 I solved this in Guile like so: scheme (define* (mirror* l #:optional (acc '())) (cond ((null? l) acc) ((list? (car l)) (mirror* (cdr l) (cons (mirror* (car l) '()) acc))) (else (mirror* (cdr l) (append (list (car l)) acc))))) Have you done the 99 lisp problems? I found it useful to go through the exercises to re-enforce what I was learning in other books.

>>43999 >I have an understanding of recursing over ordinary lists but didn't quite get car/cdr recursion on trees The Little Schemer's chapter 5 is about this. The book is somewhat Scheme-specific but it does include notes for CL compatibilities.

>>44057 Thanks for the suggestion. I'll consider doing them once I finish A Gentle Introduction to Symbolic Computation by Touretzky. >>44058 I've heard about this book before. Seems like it's wotrh taking a look at.

I'm writing a lisp somehow I'm over 1500 lines and no working repl yet

>>44094 If you're using C, that's not too surprising unless you're not even close. An LL(1) parser alone would easily be several hundred lines of code.

>>44137 I'm using C and the trouble isn't parsing, recursive descent parsing works fine. My code is bloating bc I've started only implementing SLC (simply typed lambda calculus) and it turns out that if I want to model a C program in my Lisp I need a calculus which takes effects into account. So I'm going through a ton of code churn while I wrap my head around that. Besides, I don't trust "quote". I want to actually understand the logic of it and the way its commonly implemented is too magical for me. So I want to implement whatever logic that can implement quote and not work around that bit.

Is there any Common Lisp implementation suitable for OSdev as of now? SBCL, CLISP, and all the other popular ones all don't cross-compile to bare metal/x86_64 elf and the only ones that do cross-compile to bare metal only do so because they rely on a C/C++ compiler to do all the heavy lifting for them. There is Movitz, but as my understanding of it goes, it's rather a template of an OS than a compiler, but I'm going to have to research it more. Mezzano somehow works the way it does, but it seems like replicating what Mezzano is close to impossible for a single person as they implemented a functional ANSI Common Lisp compiler and there is no way I'm writing a proper compiler any time soon, it just seems like an impossibly complicated process. But on the other hand, it does seem like every 3rd-party tool that you use, will only bite you in the ass later, and all efforts spent on making the code of others work for you, could be as well be invested in writing your own code where you know how it works, but that doesn't seem to apply to software as complex as a CL compiler. I'm aware of LokoScheme and Picolisp, but I don't like them as much as CL, so they are excluded from the get-go.

>>44500 >how can I use an emulator for a lisp machine that runs on a C system to write a system for a C machine? C is a thin layer between you and machine code, modulo register allocation and modern features like SIMD (which are almost invariable modelled on C anyway). lisp's opaque addressing and memory management is completely alien to this machine. your question is a contradiction. could you make a DSL in lisp that is for all intents and purposes equivalent to the machine C? sure you could. if you prefer doing that instead of using literally any C compiler I guess.

>>44501 then again osdev is just a buzzword for people to put on their CVs so go right ahead I suppose.

>>43711 The best thing about the horrendously bad market for young people nowadays is that since you're already so disadvantaged getting employment, you may as well write things in a language you actually like, so why not just use Lisp? Okay, all the jobs might prefer Python, but how likely is it that yet another Python project is really going to leave an impression on anyone? You might as well just embrace weirdness, and better still if it helps you enjoy yourself. At least, so I console myself.

>>31415 I used Clojure for a long time, recently getting into Common Lisp. It feels really good, though getting used to the development workflow using Sly in Emacs, has been interesting. I mostly build web applications. Any tips from seasoned Common Lispites?

>>44635 I don't understand how can it feel good after Clojure. Do you really enjoy all that hilarious soykaf like MAPC, MAPCAR, MAPCAN, MAPL, MAPLIST, MAPCON, instead of proper map, flatmap, filter, flatten, reduce, etc?

>>44500 You're screwed if you're not willing to write a compiler. You will have to either make a compiler or extend one to suit your ends. Most benefits of using a lisp for the OS come from tight integration of the compiler with the OS. Sadly, the boot image needs to be in the PE format. That means you'll need to find an assembler that compiles to that and write the bootloader in that, a CL compiler that can, or an ELF to PE converter. To my (admittedly limited) knowledge on CL, there are no open source CL compilers that can compile to bare metal PE. If you are willing to write one, don't worry about doing it all at once. You don't need to complete the entire CL standard in order to write an OS. Add what you need when you need it. Build a basic core and dog food all the way up to what you want. Don't reject other non-CL bare metal lisps as inspiration if you get stuck. Lisps are pretty similar and the ideas tend to translate well. With minor translations, 90% of something like Loko Scheme or Maru applies to a bare metal CL. Just because they define macros or namespaces different doesn't mean that they don't apply.