Lisp General: Linking Where Others Don't Dare

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?

>>27302 I did, p easy But the problem is that I can't just name it "nthcdr" :(

>>27329 Your set-nthcdr seems to do a cdr more than it should, since you do a cdr when n is 0 as well; having (= n 1) as the base case and accounting for 0 in the setf expander (since (nthcdr 0 l) is l) could be a solution I suppose. >But the problem is that I can't just name it "nthcdr" :( Shadow the original symbol and define nthcdr in your own package? Given, it's only the same as far as the print name is concerned, but it might be nicer than coming up with something else or something.

Does Scheme have a future outside of small hobby projects? I feel like the Scheme ecosystem is too fragmented to be meaningful.

>>27439 Guix is only going to keep growing (since it's one of only two decent package managers in existence), so that effectively guarantees Guile will survive for a while longer Scheme is also more useful than CL for embedded, because it's much easier to make a small executable with a Scheme.

>>27441 >Guix is only going to keep growing (since it's one of only two decent package managers in existence), so that effectively guarantees Guile will survive for a while longer Well, I was thinking particularly about Guile - it has little use outside of the Guix ecosystem and there are few libraries, but the way you said it suggests there's even less use for Scheme outside of Guix. There's little development happening in the Guile repository: https://git.savannah.gnu.org/cgit/guile.git I'm not sure whether that's because it is so minimal and there's nothing much to do there or is it because it lacks developers. I just get the feeling that most of guile libraries are maintained only sporadically by people in their free time. Maybe if Scheme was unified, there would be more libraries and the ecosystem would flourish.

>>27327 I'm planning on implementing a new Lisp. The goal will be to create a lisp I can use in user-facing applications (such as an ncurses program) that I write in Rust. What would be some good features to include in this Lisp? So far,I have the following things I would change from emacs-lisp * Add namespaces / package support of some sort (since right now the "namespacing" is manual and kind of a pain) * Implement useful emacs-lisp libraries like the dash library, along with useful data types like hash tables / sets / etc. * Make it easy to integrate into Rust applications

>>27445 No doubt you have considered the possibility of embedding an existing Lisp, rather than writing your own from scratch, and rejected such possibility for a very good reason. Yet I can't help pointing out that, in your case, I'd embed Guile. My reasons are mostly two: one, writing a Lisp interpreter can surely be a lot of fun and relatively quick, but writing one that's actually practical and enjoyable to write software for sounds like it'll take a load of time and effort. And two, libraries: even if I somehow wrote a decent language, it'd still need loads of libraries in order to be useful for anything but whatever toy examples I happen to come up with. In short, if I'm embedding a language into my program because I believe users should be allowed to extend it, then I should give them a language as mature and usable as possible, so that they can use it in ways I didn't anticipate. As for your actual question, as long as I have lexical scoping and tail call optimisation I feel at home - but I guess you're more of a dynamic scoping person? One silly feature I've sometimes thought of is recursive anonymous functions, via some special name like 'self' that is always automatically bound to the current function - I think some languages have that already.

>>27445 I know clojure has something similar with (loop) and (recur) , although the syntax is closer to a let expression.

>>27452 >Guile I tried looking around and there doesn't seem to be an "official" Guile library for Rust. A search brings up this project: https://github.com/shymega/guile-rs But it's currently "on hold". > but writing one that's actually practical and enjoyable to write software for sounds like it'll take a load of time and effort. Yeah. This would be a year-long endeavor, with the result being a lisp I could use and re-use for any applications I write. >it'd still need loads of libraries in order to be useful for anything but whatever toy examples I happen to come up with I agree with you, but I think for the time being, I'll take the policy of "If it's not provided, try creating a Rust function for it, and then bind it to your lisp environment". > I should give them a language as mature and usable as possible, so that they can use it in ways I didn't anticipate. Once again. A good point. I think I'll take a page from the emacs-lisp manual and implement the non-editor functions + macros (and maybe an emacs-minor mode). I think that'll be a good way to show people this is more than a "neat idea". >lexical scoping and tail call optimisation I was thinking about implementing TCO and Lexical scoping, it's much easier to think about (for me, at least). >Recursive anonymous functions I'll think about it; It seems like it wouldn't be _terribly_ difficult to implement, and it may lead to a more robust language design.

>>27454 I see you know what you're getting into and have it all figured out. Godspede. Regarding recursive anonymous functions, I just thought that, rather than a special, reserved name like 'self', which is not a very lispy way to do things, one could have a built-in procedure like 'get-current-procedure', and use it like ((get-current-procedure) arg ...) . Still, I don't think it's a very useful feature to be fair - it'll occasionally spare you from naming a single-use procedure and that's it.

>>27465 Not the implementer lainon. > it'll occasionally spare you from naming a single-use procedure and that's it. I think simply allowing let-binding of functions/procedures would be cleaner and simpler to implement, especially with lexical scope ensuring cleanup.

>>27439 Scheme is an academic language, it's supposed to be fun and easy to learn, not to be used in big projects.

>>27470 That's not exactly true. The base spec perhaps, but implementations generally intend to be used for more than just that. Why in the world would Guile and Racket devs bother to make a performant runtime otherwise?

>>27439 Scheme has the same problem as Pascal. The baseline language is too small for most real world problems. As such, implementations modify it to be more practical. This renders different implementations incompatible, fragmenting the ecosystem.

>>27327 >How do you think Lisp is (one of) the superior programming language(s)? I'm really new to programming and by that I mean serious programming, not just smashing fingers on the keyboard to find a configuration that does a different ``hello world''. That what happened to me while trying languages like Go or Rust. I'm new to Lisp and its mindset, something that I just scratched reading a bit of ``Structure and Interpretation of Computer Programs'' and ``Software Design for Flexibility''. I've seen powerful tools and patterns that I want to apply to my future programs, but I still need to master them. So here come my questions. What are superior languages? What powerful features do superior languages have?

>>27478 >What are superior languages? >What powerful features do superior languages have? It depends who you ask. C people think it's one thing, Haskell people think it's something else, and Python people disagree with both of them. Once you pass the obvious objective soykaf, what makes a good language depends on what you want to achieve with it. Speaking from my Lisp cultist point of view though, a superior language does what you tell it to. It's hard to explain, but Lisp is the only language I can consistently evaluate in my head.

>>27478 >What are superior languages? >What powerful features do superior languages have? SICP actually explores these questions, so let's throw in its answer as a starting point, shall we? The tools that a language gives you to express your problem with are its means of abstraction and its means of combination. The canonical example of poor means of combination is non-recursive data structures, e.g., arrays that can't contain other arrays - if you cannot reproduce your problem's complexity with your language's data structures, you'll have a harder time expressing it. Plenty of languages today give you arbitrarily complex data structures and the ability to define your own types (or the equivalent). As for means of abstraction, common ones include procedures and objects. Features like first-class citizenship and lexical closures help unlock the expressive power of procedures. Objects don't have the same theoretical soundness, but they remain a very expressive and intuitive way to express many problems.

>>27475 I hope r7rs-large will change that but most implementations are likely not going to care about it at all.

I made a parser combinator library because I wanted to see how they work, and none of the other libraries out there had any self confidence (they all were wimpy and said "not for production use" without any reason why)

>>27489 Nice work lainon, this looks pretty good. Do you have a link to the project? I'd love to try it out.

>>27489 >(they all were wimpy and said "not for production use" without any reason why) It's because everybody who makes parser combinator libraries makes them because they want to see how they work and (generally) don't focus on making a nice interface.

What is the easiest way to create a GUI application in CL? All the frameworks that I could find don't seem to work correctly. Also on another note what does this thread think about Clojure as a language?

>>27493 Clojure's kind of an odd bird. It's closer to Lisp than most other languages, but further from Lisp than most other Lisp-likes. The syntax deviates a lot from what's typical of Lisp, and it puts a much greater emphasis on immutability and pure FP. I like it, but it has a very different "flavor" to Common Lisp and Scheme

>>27490 Here you go: https://sr.ht/~shunter/parsnip/

>>27327 In my usual wondering while reading an article from Increment[1], I found the standalone version of ``The Rise of ``Worse is Better''''[2]. From there I found this neat archived version of ``Lisp: Good News, Bad News, How to Win Big''[3]. I'll read it now and I hope someone else will be interested too. [1] https://increment.com/programming-languages/unplain-text-primer-on-non-latin/ [2] https://www.jwz.org/doc/worse-is-better.html [3] https://web.archive.org/web/20000823082801/http://www.ai.mit.edu/docs/articles//good-news/section3.2.html

Is anyone here interested in digital audio? I have been working alone on making some decoders in Common Lisp and I would like to work with someone else for motivation.

Been cobbling together a game up in Common Lisp, it's a multiplayer game kind of like dwarf fortress/rimworld where each player takes the role of one of the last people living in an underground bunker, with a robust medical system and human body simulation (aim at eyes to blind someone, stab to the heart means imminent doom) been thinking of naming the thing MortalityEngine and releasing it under the AGPL though, kind of got bored of hacking at it.

I'm making something that's heavily reliant on (eval) , but I don't want it to have direct acess to important variables. Is there a way to "exclude" bindings from a part of your code?

>>27593 sounds very spaceman

>>27664 We don't talk about spacemen you sow.

>>27643 If they're lexical then you don't need to worry, as EVAL evaluates forms in a null lexical context. For dynamic bindings, I suppose you could shadow the bindings with LET or something; I believe PROGV can make specials locally unbound as well.

>>27643 What are you making, and why do you think it should be heavily reliant on (eval)? (instead of e.g. macros or something more compile-time)

Recently got a bit into Racket and built my first "real world" program in it. I'm coming from classic Schemes like Chez, and I must say: It's really great! I often found myself messing with srfi's in Scheme to get basic functionality like string handling and stuff, but Racket really feels like it has batteries included. That you can compile your programs to a standalone binary is also nice. All in all, it's been a very nice experience! I personally don't really see a reason to use Chez for small programs anymore as Racket is just easier to work with.

>>27137 It's not just Quicklisp. MELPA and personal sites are the same. It's like exposure to Lisp causes some kind of allergy against TLS. Downloading from Github isn't a guarantee either because until recently it was possible to upload over unencrypted connections.

I have an irrational fear that reading about one lisp will negatively impact my performance on the other. I know it should be the opposite. I want to learn about lisp in general, so I learn a little bit from different books which naturally use different dialects. My worry is that learning the "ways" of one dialect will push out of my mind the patterns that I may have absorbed in reading about the other. Does anyone else experience this dumb soykaf? And how to get over it?

>>27777 you're worried that one way of doing things will hedge out the other -- remain open to either way and allow yourself to synthesize what seems best from both

>>27777 I can't speak for Clojure but I go back and forth between CL and Scheme/Racket all the time. They have different stylistic conventions but what you know in one is almost always applicable to the other.

>>27781 Between CL (and which implementation) and Racket, which would you think is more robust for, say, something to communicate with an API?

>>27748 How big are the binaries?

>>27832 Afaik Racket produces executables by bundling its bytecode interpreter, so by small programs that lainon means small programs in terms of code written.

>>27833 I still would want to know the size of the binaries.

>>27299 Ask the SBCL and ECL devs why they made it that way, because it works in Clozure CL. CL-USER> (defparameter *x* '(1 2 3 4 5 6 7)) *X* CL-USER> (setf (nthcdr 3 *x*) '(3 . nil)) (3) CL-USER> *x* (1 2 3 3) The main ECL maintainer (jackdaniel) is fairly easy to approach on #commonlisp on libera chat, if you want to ask him directly.

Is there any reasonably complete graphql server implementations for a lisp? I wanna build a thing in a lisp involving it but cant find anything outside clojure that fits the bill. >>27497 This is neato, also fantastic logo

Hi there, I'm new to Lisp. I'm currently using GNU Guile and I like it. Am I missing something from the other Scheme implementations? Or is this a good implementation to start with?

>>27983 >Or is this a good implementation to start with? Yes. Each implementation offers some unique features. For example, Chibi Scheme and Guile are good for embedding, Kawa run on the JVM, Chicken compiles to C code, etc.) However, Racket has DrRacket IDE which has helpful functions for beginners. If you choose to use Racket, be sure to select R5RS from the languages menu as Racket (language) is a different from Scheme. That being said, in my honest opinion, Gnu Emacs + Geiser (or SLIME/SLY for CL or CIder for Clojure) is the best development environment for lisp. See, https://www.gnu.org/software/guile/manual/html_node/Using-Guile-in-Emacs.html

>>27983 Remember my boy. You don't code in a "scheme" or "lisp." You code in either "Steel Bank" or "Guile", "Racket", or "Clozure" Ok? You got that? It's like how Cniles code in GCC, clang and whatever microsoft uses

>>27986 Please don't go spouting nonsense. The Common Lisp community actually does a pretty good job of ensuring compatibility libraries and mundane libraries work properly on all implementations. Schemers however don't bother nearly as much with interoperability between implementations.

>>27986 This is true of schemes. One programs in guile, mit, whatever. But not of Common Lisp. But that is also a superficial consideration, one programs in lisp. Sometimes you have 2 namespaces, sometimes you have one, you might have continuations or a loop macro, you might have different semantics at different times, but you're programming in lisp.

I'm set to start touching up some of my Lisp programs again, and writing some new libraries, after ignoring them for so long. How is your progress lately? It's nice how the Lisp General is still the overall most active language threads on Lainchan. This cool new artwork of the alien Lisp mascot is just a few days old.

Common Lisp was single voiced as an abomination by old school LISPers.

My first experience was with Racket, which was very difficult for me at the time (I would say more than 7/8 years ago). I thought since it was functional everything would have to be written inside function parameters, haha, I had no idea what I was doing. Contracts, promises, concurrency, all that soykaf haha, no fuarrrking clue. I left it for a while on and off returning to the docs rewriting some stuff others made tutorials on, but started programming PHP WordPress plugins for a living at a company. And up until half a year ago when I made the mistake to program a CRM migration in PHP I knew I had to gtfo of PHP (strange things happen with arrays & builtin functions). Now Im rewriting my scripts to Common Lisp for preparation to write a well planned web service. Even though I love the development environment in Emacs & Sly, I'm still waiting to feel as comfortable as I was with my PHP workflow, although I'm learning faster than I ever did with PHP. I've just used SBCL for now, since I have no idea why I would go somewhere else. This thread had been here for a while, and has helped me see the benefits of the REPL which I very much appreciate. If anyone has some Emacs package recommendations to add to the CL workflow I would very much like to hear it, or maybe soms CL codestyle conventions, or some other esoteric feature I should know. Days go by way too fast with the repl and CL. Besides AVR hardware programming, I do not remember the last time I thought just the programming part was fun, but I do now!

>>27913 Lacinia for Clojure is well documented and stable. We use it quite a bit at my job and it's worked out well for us.

>>28056 I've never heard of a single complaint about CL that doesn't hinge on "there are weirdly named functions!" or "the spec is too big!" 1. is a childish complaint that I only hear from scheme purists. It takes some getting used to but is literally only an aesthetic issue that you get used to and doesn't impact the ergonomics at all. 2. is silly because there are plenty of widely used languages whose specs are far bigger than CL, and if you're looking for a spec with scheme levels of minimalism, well guess what, now you're sacrificing having an adequate core standard for ease of implementation. Having a language with a spec that is easy to implement is meaningless if the core language isn't useful on its own and leads to something like scheme where each implementation needs to have its own extensions to be useful and ends up not being portable across implementations. People have managed to implement CL many times and are continuing to do so with projects like CLASP and SICL, and CL is portable across all of them. Other lisps haven't held up to CL as far as I'm concerned even with these complaints in mind because none of them have matched CL's stability, portability, or its development experience and tooling.

>>28057 Do you use a structural editing mode yet? If not, get paredit or lispy. It's one of the things that make lisp so nice to work with for me.

>>28062 >get paredit or lispy. And/Or rainbow-delimiters

>>28060 The problem with CL's large spec is the redundancy. There's always like four or five subtly different versions of each feature, and you never quite know which one you're "supposed" to use until making the wrong choice breaks your program.

>>28073 Again I'm not gonna deny that there are some weird quirks with the language when you're learning it (why are there like five different ways to express equality?), but it's not a very compelling reason to me to say that we need a new spec that breaks compatibility with literal decades of software. Just look at the mess that Python2 vs Python3 is, and that's a vastly more active ecosystem than CL. There's a tradeoff between ease of learning the language vs long-term health of the CL ecosystem and while the CL spec isn't necessarily perfect, it's also light-years ahead of pretty much any other language in terms of stability and the development experience. Another thing is that CL is the result of decades of real world use and work to standardize all the different lisp implementations from back in the day. You're welcome to try to make a better lisp and probably end up with something like the scheme ecosystem, but come back after 30 years and tell me if all the different incompatible implementations being standardized doesn't result in another ANSI standard with a bunch of quirks and less than ideal design decisions to make all the different implementations work together. That is again just another reality of a language getting a lot of real world use over many years. You could maybe argue that a new CL spec would sacrifice breaking compatibility with decades of software, a lot of which like SLIME and CLIM is still incredibly powerful and better than the alternatives, in order to attract new developers, but Clojure already tried this with middling success and a lot of that was because Clojure is designed to be a hosted language and already had to make compromises with using the JVM and Javascript. And those are both far bigger and uglier languages than CL. Either way it's a gamble and I don't see the current trends in tech producing anything as good as CL again, warts and all, but feel free to try to prove me wrong. The consensus with most of the CL community seems to be that it's far better to remain compliant with the spec than chase after some shiny new spec, and that kinda comes with the territory if you're using a weird old language like CL that isn't trendy anymore. I should also add that one of the reasons why SICL is being made is to address the difficulties of implementing the CL spec by making an ANSI compliant implementation in pure CL that can be reused in other CL implementations. So while yes the quirks of CL might make implementation difficult, SICL will one day make that less of an issue.

>>28074 To add to this: Here's an article from Robert Strandh, one of the main developers behind SICL, on why a new CL spec is a bad idea and why asking for a new CL spec isn't really understanding what problems are trying to be solved in the context of language design: http://metamodular.com/2021-01-25-2.text

I hate Lisp because I hate computers. I don’t like “exploring” and figuring out “clever” solutions. I like when the compiler holds my hand and things just work. Thanks for coming to my TED Talk.

>>28074 I never said there needed to be a new spec. CL suceeeds at what it sets out to do, and that's all that matters at the end of the day. But that doesn't mean I have to love everything about it.

>>27493 I'm a fan of Clojure's immutable and shared (within memory) structures optimized for the invariants of the language. It's a very practical language and goes beyond just being a Lisp on the JVM. As an example, the system of transients, it provides a way of both documenting values that are used in a linear fashion in the language for both the programmer and the computer to understand and utilize.

>>28079 Cool, no one asked. Why the fuarrrk are you even here. >>28082 That's fair, I don't entirely disagree I'm just used to hearing these sorts of criticisms from people asking for a new spec.

What is the best Lisp implementation to use if I want to write (preferably native) Android apps?

>>28107 I'd assume Clojure since it runs on the JVM.

>>28114 ABCL does just as well though. As does Kawa Scheme.

>>28116 ABCL & Kawa will probably work better than Clojure, since they don't insist on immutable structures (which do have a runtime cost) that Android is not optimized to work with. > sage for doublepost

Android has it's own virtual machine (Dalvik/ART) which is rather different from the JVM though. ABCL can't target it (unless this has changed recently), Kawa can, and I am not sure on how the Clojure on Android situation currently is. There's also EQL5-Android, which is native and uses Qt for widgets. Haven't actually tried any of those, though.

>>28129 It seems to be that ABCL depends on parts of the JRE that Android JRE doesn't bother to implement. Because why bother to properly implement it, right Google?

At first the book seemed not as useful for learning Scheme because I already knew the basics and the first chapters were a bit boring. That combined with advanced English scared me away. It took me some time to understand the value of SICP. Maybe that's because I got better at learning and life generally since I first tried it. The book seems to teach you also how to make compilers, emulate hardware and if I'm not mistaken - some basic stuff about operating systems. I'm going to get back to reading it soon!

How is it possible to write something like ferret in Clojure? >Ferret is a free software lisp implementation designed to be used in real time embedded control systems. Ferret lisp compiles down to self contained C++11 I thought that when you develop a language using another that is based on the JVM that the resulting language also has to use the JVM in order to work. How is that possible?

>>28134 Think about it like this: a text file generated by a program running on the JVM is just a text file. It behaves exactly the same as a text file generated by a native language like C++, because at the end of the day a file is a file and how it was created doesn't matter. A compiler is a program that takes, in broad terms, takes one file and spits out another one. The step inbetween file a and b is mostly irrelevant to the end result.

>>28134 >>28138 this And you might want to actually take a look at its docs: https://ferret-lang.org/#sec-2-1

Is it sensible to write a program in Lisp that generates source code in another language? This could probably be useful in situations where you can't choose the language that you want to use. But I'm not sure how much sense something like that really makes.

I've been learning CL because I was tired of Tcl's uplevel/tailcall not being able to replace real macros and the lack of quasi-quoting equivalent. My summary is: beautiful langage, retarded/inadequate/inconsistent standard library. At least, coming from Tcl where the langage is just a little worse but the standard library miles ahead in usefulness, orthogonality and naming. Even POSIX's libc standard is less barren in some places. Something I noticed is that string processing is especially slow since in CL, there is no separate string type, only char vectors which use UTF-32 or something like it instead of proper UTF-8 strings and because the retarded function that is read-line conses each time instead of reusing a buffer like read-sequence. Hash tables are also quite retarded.

>>28167 If you mean making a compiler like Chicken Scheme's or ECL's, then there's no reason that's not a good idea. If you mean to do that because you don't like the language your workplace makes you use, that's a bad reason and it will be both a maintenance and a cooperation nightmare.

>>28107 >>28114 >>28116 >>28120 as far as I know, the thing about languages that are hosted on the JVM like Clojure and ABCL is that while android apps are written in Java, the Android Runtime (ART) is different from the JVM. so whether or not a language is hosted on the JVM isn't even relevant to it. I believe this was done largely because Google didn't want to pay Oracle for licensing fees as much as I vastly prefer CL to Clojure, if you want to do mobile app development, Clojurescript is probably the most sane way to go in general and also is the only lisp I know of that can be used to make mobile apps aside from a few small random projects out there. MOCL for common lisp is an implementation of CL that's meant to be used for mobile apps, but sadly it's proprietary and costs money

>>28176 >char vectors which use UTF-32 or something like it instead of proper UTF-8 strings Implementation dependent, not specified by spec. http://www.lispworks.com/documentation/HyperSpec/Body/13_ai.htm >because the retarded function that is read-line conses each time instead of reusing a buffer like read-sequence. That is also implementation-defined, it isn't mandated to work that way. >Hash tables are also quite retarded. Please expand.

>>28179 >Android Runtime (ART) is different from the JVM. so whether or not a language is hosted on the JVM isn't even relevant to it Yes, I noted that much here >>28130, Kawa Scheme went out of its way to support ART, while ABCL depends on a functional JRE. >Clojurescript is probably the most sane way to go in general and also is the only lisp I know of that can be used to make mobile apps aside from a few small random projects out there. Clasp might also be usable, although it's still pretty young as a project, as one can make pure C++ Android apps.

>>28180 >Implementation dependent, not specified by spec. Wrong, strings ARE char vectors, and as such, they must use a unit that makes sense as char; otherwise, how are you gonna use all the array/sequence functions? Though, SBCL using UTF-32 and ECL using something similar makes me wonder how combining codepoints and other Unicode niggery is handled. >That is also implementation-defined, it isn't mandated to work that way. Well, while the HyperSpec doesn't say that it returns a "fresh string", I don't know if an implementation does a thorough enough code analysis to recognize when the result is discarded before the next call. >Please expand. Feels like using arrays vs dicts in Tcl, not well integrated with the whole (no way to print/read, no builtin literals, no freedom for the test function), no default values or elegant table nesting and the standard doesn't offer a way to do a gethash followed by setf gethash without guaranteeing that the hash won't be computed twice (like Tcl's dict update), which is something that happens very often with incf, for example; some implementations cache the last computed hash, but that's still clunky. I also remember that the standard was obviously made before multicore CPUs arrived, and was never updated in consequence (and SBCL's extension locks the entire hash tables because it uses open hashing, instead of traditional buckets).

>>28182 >they must use a unit that makes sense as char; otherwise, how are you gonna use all the array/sequence functions? Correct. I'm saying that what they deem to make sense is implementation specific. Some might choose an internal UTF-32 representation, but that's up to them. >Well, while the HyperSpec doesn't say that it returns a "fresh string", I don't know if an implementation does a thorough enough code analysis to recognize when the result is discarded before the next call. Good question. You have a point about the clunkyness. Alexandria helps a bit though.

>>28181 Yeah I didn't see the other post until after. Using CLASP for app development would be interesting -- I don't know how ready it is for something like that or how you'd do it, but it does have a 1.0 pre-release so it's getting close to being stable and fully up to spec.

Is there any Lisp implementation that is like a Swiss pocket knife in terms of platforms that it can target? There is stuff like Clojure or ABCL that can target the JVM but can't run native without using stuff like GraalVM and then you have most CL implementations which can run native but can't target the JVM or even the browser. So, is there any Lisp that can run native, in the JVM, in the browser and other platforms? Maybe even a kind of lisp that can interoperate most languages (want to use C libs you can, want to use java libs you can, want to use Fortran libs you can etc.)

>>28191 >Is there any Lisp implementation that is like a Swiss pocket knife in terms of platforms that it can target? Chicken Scheme (compile to C) or Chibi Scheme (embed) or Guile (embed) or Embeddable Common-Lisp (compile to C/C++) OR just use the JVM stuff: Kawa, ABCL, Clojure. >So, is there any Lisp that can run native, in the JVM, in the browser and other platforms? Just write standard Common Lisp and it should work on any of the implementations that implement the common lisp STANDARD. Don't use implementation-specific features and prefer libraries. If you are asking if there is 1 lisp IMPLEMENTATION that can run on any of these platforms, the answer is probably no.

When I'm working on a project I always switch between CL, Racket and Clojure and can't get anything done because of it. How do I finally settle on a single Lisp implementation?

>>28194 >How do I finally settle on a single Lisp language? Try writing a same and non-trivial program in all languages and see which one you like the most. CL, Racket and Clojure are all good and productive languages and they have good docs, too.

>>27439 if the implementers and library writers can actually get behind R7RS-Large with any kind of commitment to portability and consistency. With R6RS in the rear-view mirror, I'm not hopeful, but we'll see. I do want to be wrong about this.

Why don't people use Racket for anything not academic? Is it really only because it's based on scheme?

>>28194 You could make language modules for racket. >>28213 Cant speak for others but its one of my languages of choice for most things and im far away from academic. Yeah its a shame its not used more since it really comes with batteries and awesome systems that make if both easy and flexible to do lots of cool stuff.

>>28191 >>28193 if you want to use multiple lisps (or other languages), you also could use inter-process communication (or FFI)

Lainons that use Clojure: what kind of project/build system do you use? Do you use Leiningen or the "new" build in tools tools.build & deps.edn or something else? I don't know if I should use and trust Leiningen since it's a third party tool.

>>28229 Gradle is best.

I don't know if this belongs in this thread, but is there any X window manager that works like Genera? preferably written in (any) Lisp of course.

>>28303 Emacs' EXWM and StumpWM and Squeak smalltalk are the closest to Genera. >https://github.com/ch11ng/exwm >https://stumpwm.github.io

>>28304 >StumpWM Thanks for the advice StumpWM is really great.

Am I missing something about Clojure? With Common Lisp's FFI I can interact with C, C++, Python, and JavaScript, but I keep seeing how Clojure's so much more practical because of "Java libraries". Maybe it's just because I'm not in banking or whatever, but I can't even remember the last interesting thing I saw written in Java.

>>28311 I'm not aware of any implementation other that Clasp having good interop with C++. What did you do? I should also ask the same for Python and Javascript really. > I keep seeing how Clojure's so much more practical because of "Java libraries" It's bullshit, majority of those libs don't depend on things ABCL hasn't implement support for.

>>28311 Ignore the Clojure $hills. Unless you need to do mobile development or frontend web development with some fancy modern web bullshit like React/Redux (Reagent/Reframe in Clojurescript), the two areas Clojure currently really shines compared to CL, it's just not as good as CL. ABCL already exists and can do the same soykaf that Clojure was initially designed for, it just doesn't get as much attention because CL is a smaller community of people who aren't generally interested in competing in the rat race of modern (cancerous and AIDS) tech trends

>>28316 I'm a bit conflicted on one hand I like CL more than Clojure but on the other I would also like to either get a job where I use Lisp (or sell my own software at some point) but especially with the lisp job point that means that I probably need to use Clojure since Clojure is the only Lisp as far as I know that has a "bigger" job availability.

>>28317 I feel you, I still think Clojure is worth using for certain things like I mentioned before so that would at least be an opportunity for writing code in it to try to get a job. I kind of view the lack of jobs for common lisp as a bug rather than a feature though, because it ensures that the sanctity of the language isn't tainted by it being made into something you might use at a job. work will kill your enjoyment of basically anything.

>>28318 *feature rather than a bug

how long did it take Lisp to "stick" for you? I did SICP a while back and I had good intuitive sense of Scheme after a few days. Now I am visiting CL to achieve programming enlightenment.

>>28316 What does ClojureScript do that ParenScript doesn't? Serious question.

>>28333 It's a bit hard for me to quantify. My experience with Parenscript vs Clojurescript -- which to be fair I haven't done as much with Parenscript yet, though I plan to -- is that because Clojurescript is hosted on the JavaScript VM itself, it feels closer to a lispy web development experience because you're actually interacting live with a running program. Parenscript on the other hand is just a transpiler, and I don't know how well you'd be able to make something like Figwheel/Shadow-CLJS with it (though I'm currently making a modest attempt at something like it for CL). It also interops pretty seamlessly with JS soykaf, so you have Reagent and Reframe. Like I said above you can also make mobile apps using React Native. Code reuse between Clojure and Clojurescript also seems a lot easier than between CL and Parenscript; I know it can be done but I haven't quite figured out how it works yet. I'd love to say to use Parenscript and CL if you want to make a web app or mobile app, but it doesn't feel quite there in comparison, and I say this as someone who vastly prefers CL to Clojure or really any other language. A lot of this is because both platforms are just fuarrrking awful though to be fair and I do think there's an argument to be made for not adopting soykafty web and mobile technologies that are by design extremely difficult to keep up with and have a competitive ecosystem of different languages targeting them. Maybe Parenscript is better than I think though, I know you can do cool soykaf with macros on it for instance. There's also Valtan and JSCL, so people are attempting to make something like Clojurescript for CL.

Is there any good McCLIM based X window manager or DE yet?

>>28339 Unfortunately not that I'm aware of. StumpWM is really good and uses CLX (which is a backend McCIM uses), and there's an experimental McCLIM modeline in the contribs repo that I've been fuarrrking with a bit in the hopes of getting it into a more complete and usable state, but there aren't a whole lot of McCLIM applications (yet) so the idea of a McCLIM DE is pretty hypothetical right now. I've also been fuarrrking around with trying to make McCLIM clients for email and Matrix, so if it's something you're interested in I'd highly recommend getting involved with McCLIM's development or start hacking on it and make some applications you'd want. What would you be hoping to achieve with a McCLIM WM/DE over StumpWM?

>>28326 I've been on this grind for a year and I feel like I'm getting there, slowly. following the roadmap from https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/ Demoralization is real sometimes but I remind myself this is a years-long process.

>>28060 Here's my complaint: Global package namespace. The CL spec currently has no feature to have package-local nicknames (which to be fair, is implemented by enough impl's like SBCL). So, if you want to stay compliant, you either have to import package symbols into your own package (which removes clarity for humans on which symbol belongs to whom, as well as risking breakage when a dependent package update adds a symbol that causes a conflict) -- OR you discipline yourself to no imports at all, making symbols terribly long (#'com.acme.frobnicator:frobnicate) and encourages library maintainers to come up with short names that would create a package conflict. This is currently happening in practice with massung's base64 and cl-base64 in Quicklisp, who both named their package -- go figure -- "base64". If either one used reverse-domain-named packages like blog.codeninja.base64, this wouldn't happen -- but now you'd be working with symbols like 'blog.codeninja.base64:base64-decode. You could go without this mess by either adding package-local nicknames to the spec, or lose the promise of spec-compliance in your code. If I could complain about CL at large, and not just the -- it'll be that ASDF, the de-facto systems facility we have, has nothing I know of for tagging versions as part of system dependencies. I see cl-foo 1.2.4, so I want to depend on >= 1.2.x, < 2. I'm not able to do that (or at least haven't seen it in the wild), so I'm only able to depend on cl-foo -- whatever latest version is available. If that cl-foo releases a backwards-incompatible 2.0.0, my code breaks. This could be worked around by defining a new package for each breaking change (it looks like alexandria does this), but... why? ASDF already enforces "#.#.#"-style versioning (or at least, complains when a system doesn't), but I don't see where exactly that structure is being utilized anywhere.

>>28365 This is a reasonable complaint. It's not just SBCL though; a lot (most?) implementations these days seem to support package local nicknames: https://lispcookbook.github.io/cl-cookbook/packages.html#package-local-nicknames-pln Additionally, in plain common lisp, there's the rename-package function, which you can use to define your own PLNs if you're worried about portability for some more niche implementations: http://www.lispworks.com/documentation/HyperSpec/Body/f_rn_pkg.htm in ASDF, you can use a :version declaration in your dependencies to set that. It's not something I see being done a whole lot, but I think a lot of that is just due to the culture of CL development where everything is so stable that usually pinning a version of a dependency isn't necessary. That's not always the case though with really actively developed systems like McCLIM or CLX where older McCLIM applications tend to not work without a bit of tweaking. There is however a new package manager for lisp called CLPM that aims to correct this problem and give first class support for things like dependency pinning and other modern dev practices: https://www.clpm.dev/. I haven't used it yet but it seems pretty solid.

>>28365 As >>28371 says, ASDF does support dependency pinning. But please, for the love of all that is sane in this miserable world, don't pin dependencies[1]. >>28371 >This is a reasonable complaint. It's not just SBCL though; a lot (most?) implementations these days seem to support package local nicknames: https://lispcookbook.github.io/cl-cookbook/packages.html#package-local-nicknames-pln Is there a library available to paper over this sort of thing? >Additionally, in plain common lisp, there's the rename-package function, which you can use to define your own PLNs if you're worried about portability for some more niche implementations: http://www.lispworks.com/documentation/HyperSpec/Body/f_rn_pkg.htm That can break things though, as is noted here[2]. [1]: https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/ [2]: https://lispcookbook.github.io/cl-cookbook/packages.html#package-local-nicknames-pln

I program in Racket. It's ok. It's the only language I really know and feel confident in.

>>28337 If you can work in React with JavaScript, can't you work in React with ParenScript? I'm not sure what you mean by "interop" (or "code reuse"). >because you're actually interacting live with a running program I haven't tried it, but trident mode for Emacs is supposed to emulate this.

Does anyone know how the LispWorks for Mobile Runtime works? I just don't know how you would program something that takes normal CL code and makes it run on mobile platforms. Too bad that the source code of it isn't available I would love to see how they managed to do it.

>>28373 For PLNs, I think this is what you might be looking for: https://github.com/phoe/trivial-package-local-nicknames. This gist by the developer of the library also gives some more details on it: https://gist.github.com/phoe/2b63f33a2a4727a437403eceb7a6b4a3 As noted in phoe's gist, most implementations support this out of the box, but if portability ever becomes an issue (maybe you're hacking on Mezzano or SICL for instance), that's what you'd probably want. also yes I realized after posting about rename-package that it has issues and can break soykaf >>28376 Well, to elaborate further: Parenscript as I understand it is more of a lispy alternative syntax for javascript that has some of the power of common lisp carried over to it, like macros for instance, but you can't really just take a package in common lisp and use the symbols from it in parenscript code. It can sort of be done, I know you can import common lisp macros into parenscript at least, but compared to clojurescript where mostly everything you can do in clojure can be reused in clojurescript code, it feels a lot more limited. You can use javascript libraries in parenscript, but there are limitations to this because for one thing parenscript is ES5 whereas a lot of javascript targets ES6 these days. another problem I've had with parenscript that is related to it largely being a different syntax for javascript is that a lot of the time it doesn't feel like I can just write code like I normally would in CL. there are a lot of small differences in how things work, whereas with clojure/clojurescript it mostly feels the same whether I'm writing backend or frontend code. There are these parenscript libraries though for React and ES6: https://github.com/BnMcGn/paren6, https://github.com/helmutkian/cl-react, and I'd certainly recommend anyone who is more interested in using CL and improving the CL ecosystem to try using parenscript. my point is just that if you want to build web apps or mobile apps, I'm not sure how realistic CL is just full stop from a practical perspective, let alone taking into account the experience itself not being quite what you'd expect with CL. I'm aware of trident mode, though my impressions of it were that it's kind of a hacky solution for adding a lispy development experience to parenscript. it reminds me of how it feels right now trying to add some lispy development ideas into python (which I'm unfortunately forced to use for work); it can kind of sort of be done, but it's not the Right Way of doing things, and a lot of what I like about common lisp is the fact that it's a complete system designed from the bottom up to support a lispy development experience. but if I find myself making some kind of gay modern web app, I'd probably give it a shot. one other thing I'll add is that there's the 40ants fork of weblocks, which I believe makes extensive use of parenscript. if I were going to try to make a modern web app entirely in common lisp that's the first thing I would try.

>>28386 >For PLNs, I think this is what you might be looking for: https://github.com/phoe/trivial-package-local-nicknames Yup, I found that a little while after and it turned out to be exactly what I was looking for. Yet more good stuff from phoe. Regarding CL on JS, I know that LLVM has a WebAssembly target, so it might be possible to base some interop layer on that using Clasp.

>>28387 using Clasp for webassembly interop could be pretty amazing. it seems like it's also nearing a 1.0 release so it might not be that far off from being possible.

Does anyone know why I can't click certain elements in chromium based browsers (and also stuff like electron applications) when I'm using StumpWM?

I've implemented some cryptographic functions in Common Lisp, and it's really not fun. Trying to guess what will produce the most efficient compiled function is usually ugly and removes the creativity in approach. I have the most fun doing things like implementing data structures and their operations in Lisp, where the outside world is of no concern. I was lately thinking about why I use Lisp more than other languages, and the image-based nature with an inspector and other niceties was the answer. I can do things like assemble a data structure and then explore it in unintended ways, to get information about the particulars. However, I thought about this more carefully and realized that interacting with the computation in low-stress ways, where I can interactively handle errors rather than account for everything beforehand and whatnot, is what I want out of a general computing environment. I'm not infatuated with Lisp so much as Lisp is the only way to get what I consider a basic computing environment, which really shouldn't be dependent on any language. Still, I don't see myself leaving Lisp entirely in the next few years. I'm slowly replacing things, but the whole is large.

>>29043 have you used Smalltalk at all? it's the one other image-based language I can think of where you get a similar level of interactivity and dynamism this does make me wonder though why aside from lisp and Smalltalk, image-based programming never really caught on. I feel like there's probably something about the lineage of C and Unix that just lends itself to a static computing environment, and practically everything today exists to some extent within those lineages.

>>29044 Smalltalk came to mind, yes. I've read some of the writings about it, but never used it. I may use it just to do anything graphical on a computer, for which Common Lisp wants me to pull in libraries. >I feel like there's probably something about the lineage of C and Unix that just lends itself to a static computing environment, and practically everything today exists to some extent within those lineages. UNIX is an image, simply an extraordinarily poor one.

>>29045 I don't have a lot of experience with Smalltalk and I prefer common lisp even though I really like Smalltalk just because CL feels a lot more versatile, but I recommend checking out Pharo or Squeak and playing around with it. It's a fun language. >UNIX is an image, simply an extraordinarily poor one. Greenspun's tenth rule strikes again

>>28304 >Emacs' EXWM and StumpWM There is also this: https://en.wikipedia.org/wiki/Scwm >>29044 >have you used Smalltalk at all? This. Install Pharo.

Are there any thoughts about Common Lisp IRC clients?

>>29278 There isn't one that currently exists but it's something I've wanted to make in mcclim. I'm just a moron and can't figure out how SASL works

>>29279 There is https://github.com/MrNeutron/beirc which uses McClim. I don't if it still works or not.

How does Racket compare to Common Lisp?

>>29280 It's kind of a fuarrrk because mcclim has changed a lot since it was made. It'd be easier IMO to just make a new one since IRC is a really simple protocol anyways than trying to figure out how to fix someone else's undocumented code

>>29288 You could just roll your own. As you said IRC is a very simple protocol, and that way you get it done exactly the way you like it.

>>28373 > As >>28371 says, ASDF does support dependency pinning. But please, for the love of all that is sane in this miserable world, don't pin dependencies[1]. If it's so terrible, is it really a solution? It looks like the only "sane" solution is to follow conventions I see in linux distro package repos -- suffix a system/package name with a major version number, and *promise* to never make any breaking changes within a major version (albeit, you'd also have to define what a breaking change is. Does e.g. adding symbols count as a breaking change?)

What would you use if you had to write a cross platform GUI based application in Common Lisp?

>>29308 it's on my todo list of things I want to make, there's just a lot of different things there and I was hitting roadblocks that made me decide to put that on the backburner for now.

>>29278 >>29280 The Mezzano OS also comes with an IRC client, although of course it's written for that OS's API so it may not be a viable starting point either. https://github.com/froggey/Mezzano/blob/master/applications/irc.lisp

I found https://common-lisp.net/project/cl-irc/ but I don't know enough about Lisp or IRC to judge it's worth. >>29308 I know basically nothing about Lisp and basically nothing about IRC, so I don't think I'm ready for such a fun project. >>29328 Do share how you come about getting to the solution, as well as your missteps. It can be edifying for novices such as myself to witness not only good programming, but mistakes as they're made in nature, so that I may better channel my energies to avoid or use my mistakes for the best try to improve my skills.

>>29327 It's tough. It also depends on your background. What options have you weighed? The general route is qt-bindings.

>>28229 Last I tried to use deps was maybe 6 months ago and it did not seem complete compared to leiningen >>29327 Perhaps I'm to lazy for my own good, but html templates and hutchentoot.

Which one is more powerful (let's you do more things) EXWM or StumpWM and why?

I've read that in Lisp (especially) common lisp you don't really need to use libraries because you can basically write everything yourself faster than you could in most other languages and that's why lisp devs supposedly tend to write stuff on their own instead of importing someone else's code. Is that true?

>>29387 I'm just going to say it but running your whole ass desktop in a single-threaded application like emacs that you should be using for its intended purpose (writing code) first and foremost is just stupid as fuarrrk. But that being said, StumpWM is more powerful because common lisp is meant to be a general purpose language and isn't tied to fuarrrking emacs. You can use it from multiple different CL implementations, you can write pretty much any extensions to StumpWM that you can think of, you can use it in any X11 environment. I like emacs for writing common lisp but StumpWM feels far more versatile. >>29401 It really depends on how good you are. It's true that if you know what you're doing, it's substantially easier in CL than in any other language to implement something yourself from scratch using only the ANSI standard. But you still have to know how to do it, and there are tradeoffs to consider between using other people's libraries vs. implementing it yourself. I think that CL generally exists in a very good middle ground where when you do decide to depend on other libraries, you can get by with usually no more than five, and there are plenty of high-quality libraries you can use for doing most things.

>>29387 I've only ever used StumpWM. It's convenient to be able to evaluate Common Lisp whenever I want, including to modify parts of the manager. It's possible, and not very difficult, to lock it up by mistake, however; I've done so a few times over the years. >>29401 Yes. That's what I do. I only use libraries I've written. This also leads to better software, because I'm not going to do things that require pulling in many dependencies, unless I've already written them. Too little software is concerned with its own complexity. >>29403 >I think that CL generally exists in a very good middle ground where when you do decide to depend on other libraries, you can get by with usually no more than five, and there are plenty of high-quality libraries you can use for doing most things. Unfortunately, I've seen instances where people have nearly one hundred dependencies, and ask whether they were too much or not, to a chorus of fools calling it perfectly reasonable. Plenty of Common Lisp libraries unnecessarily depend on libraries from other languages, as well. Take DRAKMA as an example; as an aside, he uses Github to host this now, and what a shame; even the old link redirects to this now: https://edicl.github.io/drakma/ It has eight or so dependencies, at a glance, and those likely have others. Already, this is too many. One of them is a dependency on a C language library. The proper way to do this would be to write all of it in Common Lisp, but this is understandably so difficult, made purposefully so by the designers of these protocols, that apparently no one has tried for one reason or another. I audited DRAKMA when I used it, but it's a bit of a mess, especially due to the foreign language dependency. The proper way to write an HTTP client, from what I know of the protocol, would be to start with a Telnet client, and work from that. The goal should be to reduce complexity as much as feasible. Most libraries aren't written in this way, but I suppose I shouldn't take such offense, since I was never going to so much as consider using them regardless.

Hello Lisperatis I'm toying with CL and find it beautiful What other things do you have in your toolkit? I see Perl & Prolog. Qt too. This is all approached with the philosophy that the tools don't matter, only the end result. Don't accessorize, just choose and get it done. Even if the tools are initially painful, RTFM (i.e. Emacs) For example, what do you use for dirty quick scripts? Would you consider scripting in lisp* zealous? How about deployment scenarios? What libraries do you use instead of writing it yourself? Trying to tow the line between practical and zealous. I want off this proverbial carousel of dependency hell and obsolescence *https://roswell.github.io/Roswell-as-a-Scripting-Environment.html *http://howardism.org/Technical/Emacs/piper-presentation-transcript.html

Redpill me on using LISP for High Performance Computing not on Lisp Machines.

>>29420 https://pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-code-breadboard/

>>29420 you know what i assumed you meant implementing high performance algormithms, if you meant managing an array of hpc machines for see https://hpc.guix.info/ sage for double bump

>>29420 https://github.com/cosmos72/stmx/tree/master/asm

How easy is it to get a remote job where you program in "any kind of" lisp?

>>29404 >Yes. That's what I do. I only use libraries I've written So, if you needed to use opengl for example you would create bindings yourself instead of using the ones that already exist?

>>29449 Clojure jobs are relatively common -- though a lot of them are in web. CL is rare and the positions I have seen come up usually required other domain knowledge like quantum computing or computer algebra.

I'm using Guix + StumpWM + Emacs + Nyxt. I need more Lisp in my life what else should I use?

>>29473 >Nyxt When I used that, I couldn't figure out how to go to the next search. I assumed it was bad because search is fairly basic and important to browsing. Is it actually usable? The dude on his website said all sorts of weird soykaf about it being an emacs replacement as well. That kind of put me off it.

How can I learn to program something like CLiCC,cl-js and cl-py? Should I read let over lambda since I've heard that you learn to build something similar for forth in that book, any other advice?

>>29490 1. Be good at math 2. Read Robert Harper

I'm new to Lisp, got interested because of SICP and so on. But I can't understand: why would someone choose to use Lisp over another language? Aren't most innovative features of Lisp already integrated in other, more popular languages? I'm thinking of Elixir or Julia for example. It seems like the strengths that still hold up nowadays are: macros and interactivity (REPL, error handling, images, so on). I don't want to cause a flame war or something similar, I'm genuinely curious as I might be missing something.

>>29539 While that is true to an extent, they aren't exactly as good. The dynamism of lisp is something that is difficult to fully replicate in other languages. Even if it were, macros (or the syntax more generally) and the REPL are incredible things that you shouldn't underestimate the usefulness of. Macros effectively put the language user on the same level as the compiler writer when it comes to extending the language. While many languages need regular updates or revisions to fix issues with them, a good lisp will not really need this. Any issue that exists can be solved more easily through a library than a change to the language itself. Take for instance pipelines. In other languages these must be implemented by the designer, or worked around in some stupid way (usually method chaining). In lisp you can define a pipeline macro in a few lines of code. By defining a language in the way, lisp offers stability that other languages can not without compromising on quality. Dynamism and the REPL are also a huge draw. In lisp very few things are limited by their definition, this makes extending lisp programs much easier than other languages. Emacs lives off this principal, but it is useful in other cases as well.

>>29539 Don't know enough Julia/Elixir but here are some CL features I've rarely seen in other PLs: * Powerful and elegant macros (incl. symbol-macros) due to homoiconicity; nothing can touch CL on this point * Reflection over the entire read/compile/load chain (via reader macros, compiler macros and other goodies like eval-when) * restarts * Very sane "numerical tower" concept * destructuring-bind (and very well designed lambda lists, in general) * first-class symbols (Tcl has this too) * Very powerful gray streams * Arguably the most powerful object system there is * All of the above while still being AOT compiled

>>29539 >Aren't most innovative features of Lisp already integrated in other, more popular languages? The whole is greater than the sum of its parts here. Lisp is gestalt. See this post: >>29043 >>29542 >symbol-macros >destructuring-bind The Ada programming language captures at least some of this with its renaming system, which allows using a variable name to, say, indicate an element of an array without any indexing syntax.

Elisp Question: Given a paragraph, is there an elisp function that can return a list of sentences contained in the paragraph?

>>29563 What I eventually want to do is reformat the paragraph such that each sentence is on its own line.

I know that Racket lacks the image based development of something like CL, but couldn't you add that to Racket if you need it or is that impossible?

>>29563 A quick C-h a for sentence revealed naught to me. This could be a keyboard macro, if manually controlling it would be fine, or a simple function, however. Skulk around in Emacs and look into fill-paragraph-function.

There's been some progress decompiling jak (ps2) into the lisp it was made with & rewriting the compiler for that lisp dialect. https://github.com/water111/jak-project https://blog.jakspeedruns.com/opengoal-project-update-september-2020/

Is there something like a bootable Common Lisp repl, which I could use as a base to write my own userland on?

>>29589 You could take https://github.com/froggey/Mezzano and strip off the userland they've written so far, or maybe contribute to it directly since it looks pretty cool.

>>29590 Is there a way to build Mezzano without having to install Virtualbox?

>>29589 Movitz was supposed to be that, but I'm not sure of the state of the project, or how well it works.

I'm using Racket because my soykafey laptop is stuck running Windows until I'm actually fluent in computers enough to wipe it and run some Linux distribution instead.

>>29609 Racket is a fun lisp. I hope you keep using it after you switch to Linux.

>The Laurel Project has released a compiled version of Taylor, a language that can be interpreted by the EVM with operations that can run both on the stack or on memory frames. This allows Taylor to do recursion operations that are not possible now on Solidity or Yul. The performance of the compiled Taylor relative to Yul is a consistent 94% on gas and 89.7% on execution steps with a more important margin on stack usage. There's a contender to Solidity/Yul, apparently in terms of performance, as a language for smart contracts. And it's a Lisp. Might this be an influence of another project using Haskell for smart contracts? Can a more versed lainon give their opinion on it? Is it a meme?

>>29630 For reference: https://laurel.provable.dev/

>>29630 https://archive.ph/wCyLS

I'm surprised ABCL doesn't support creating a new Java class. The ABCL manual lists JAVA:DEFINE-NEW-CLASS and JAVA:JNEW-RUNTIME-CLASS as ways to create a class, but the former is unimplemented and the latter is unsupported and not fully documented. Clojure on the other hand has no less than 5 different ways to create a new class: defrecord, deftype, reify, proxy, and gen-class.

>>29593 qemu? man 1 qemu-img # create "virtual" HDD man 1 qemu # use qemu-system-x86_64 to boot a vm

Is there some way to write a C FFI for Common Lisp using only things defined in the standard so that I don't have to rely on extensions which SBCL for example implements?

>>29765 that's why you would use the CFFI library https://github.com/cffi/cffi. it's meant to abstract the implementation-specific details of C FFI. I don't know this for a fact but my guess is that there isn't a way to do it purely using the standard because it was still written under the assumption that one would be working in either a purely or a primarily lisp-dominated environment (i.e. a lisp machine). keep in mind that there also aren't any pure CL implementations of CL right now except for SICL, which is still under heavy development. I could be wrong about there being a way to do FFI using just the standard but I think if there was there wouldn't be a need for implementations to have their own ways of doing C FFI. fyi this page also tracks the portability of libraries like CFFI https://portability.cl/ and from the looks of it CFFI is one of the best in terms of that. it's unfortunately kind of impossible to do modern CL development without deviating from the standard at least a little bit, since there are things like ASDF that the community has adopted as de facto standards.

Has anybody tried... ... NewLisp? http://www.newlisp.org/ ... Shen? https://www.shenlanguage.org/ ... PicoLisp? https://picolisp.com/wiki/?home

>>29841 My first lisp was newlisp actually, its been so damn long but i recall it being fairly decent with a practical api. Its nothing special really tho. Its less clutter than cl but gives you more to work with than scheme, id say its a good inbetween. Im gonna check it out again just to refresh my memories.

>>29841 I have checked out all three, and even wrote a very simple program in newLISP. PicoLisp is opinionated; it has dynamic scoping and other (nowadays) unorthodox features. Lisp-hungry people should check it out, but I think few will want to use it in practice. Shen I wrote off in my notes as vaporware. Does it have code you can try, now? That'd be great because I remember it boasted a gorgeous featureset. I see your Lisps and I raise you a couple more: TXR https://www.nongnu.org/txr/ A very practical tool. It packs two languages: a general-purpose Lisp, and a pattern-matching language for text. If you can browse through the examples and not come up with a problem TXR would solve better than your usual go-to language, you get your money back. Gerbil https://cons.io/ This is simply a Scheme, but one with a very nice runtime and stdlib. Pattern matching, coroutines, actors, and other things I won't even pretend to understand on an anonymous imageboard.

Did anyone here use movitz before? https://movitz.common-lisp.dev/ How is it and can you run it on bare metal?

>>29908 >Does it have code you can try, now? All I know is that there is a Common Lisp implementation of the language: >https://github.com/Shen-Language/shen-cl/ >https://shenlanguage.org/download.html

>>29921 I haven't used it myself but there's a more recent branch from 2014 with some info on the state of getting it to compile an img SBCL https://github.com/karlosz/movitz There's also a decent amount of documentation for it here: http://trac.common-lisp.net/movitz/wiki It seems like it would be a decent code base to pick back up for developing some kind of CL system for running CL on bare metal. The assembler is only lime 2000 LOC. It seems like the biggest hurdle would be having a complete CL implementation, but thanks to SICL it'll eventually be possible to reuse code from that implementation in others and make the process of implementing CL a lot more doable (CLASP is already using parts of SICL in fact). So that might make picking up movitz development again easier, and you could possibly use the compositor code from Mezzano to get a graphical environment if it were ported to be implementation-agnostic. Disclaimer: I have no idea what I'm talking about and this would probably be significantly harder than I'm imagining

>>29946 * only 2000 LOC jfc

>>29947 Don't know if you've ever coded Assembly, but even trivial programs reaching hundreds of LoC is not even remotely surprising. Look even just what a hello-world looks like on Linux: https://efxa.org/2011/03/02/assembly-gnulinux/ Mind that this hello world is still using features from Linux and would be more complicated (and much longer) if it had to do any actual display itself, as it would if it were running on bare metal.

>>27442 When scheme, racket, and guile combine, and touch parens, they become...cabal, the ultimate lisp!

>>30000 you are wrong, hello world without OS is easier and shorter, because you don't need to worry about C style Linux system calls you use bios interrupts instead, basically the same thing in the end.

>>30114 Right, I neglected the BIOS functions. I meant from scratch, including all drawing on-screen, without using the functions. But even then, other than my example being insufficiently precise, my statement still stands. Perhaps even more so, since the reason it's short is purely because of provided niceties by the platform. Getting anything done on bare-metal that isn't directly supported is long.

Hello, anons. Pic rel is my first Lisp program that is not SICP-related. This is an automata simulator written in scheme R7RS for the chibi-scheme interpreter. It can run deterministic and non-deterministic automata, and can also build a non-deterministic automata from a regular expression. I wrote it in order to practice what I'm learning at college on the Theory of Computation classes. I'm not a lisper, but I thought that Lisp was the best language to implement that. The code is kinda uggly, but works. My first experience with lisp was SICP, tho. It is made of two files: automata.scm: https://ttm.sh/i5X.scm exempla.scm: https://ttm.sh/i5y.scm automata.scm contains the definitions of the procedures; and exempla.scm is an executable script that loads the first file and builds some automata and run them on a set of strings (the alphabet for the strings are just the characters 0 and 1). I'm curious to know what are you doing with Lisp (especially on scheme). Show me your projects!

Is there a Lisp that doesn't have special forms?

>>30141 Yeah, it is easy to see from your style that you have only read SICP. Read the R7RS standard, and you will see a lot of things that you can use (like record types, case, ...). You use a few SRFIs, but I'd say you should either use more or less. The code might be significantly simplified if you replace your custom tagged list with lambdas, ie. star takes a regular expression in lambda form and returns one that repeats the term. Also, aren't you that Unix guy who writes his own stuff? I pity you for that, because if you go on this path, you might end up understanding Emacs and you'll recognize that all your prior work was superfluous, all the minimalism meaningless and all the dogma was a senseless restriction. But hey, on the other hand it is always good to see people grow out of their old selves. >>30167 You can get rid of some special forms that are only implemented as such for performance reasons, but there is a point where you must be able to stop reducing term and have some computing actually go on.

Does anyone know how https://en.wikipedia.org/wiki/Mocl worked?

>>30177 >Yeah, it is easy to see from your style that you have only read SICP. Read the R7RS standard, and you will see a lot of things that you can use (like record types, case, ...). You use a few SRFIs, but I'd say you should either use more or less. The code might be significantly simplified if you replace your custom tagged list with lambdas, ie. star takes a regular expression in lambda form and returns one that repeats the term. I will read the R7RS. It is a short document, but very terse; I like that. It seems that SICP uses a subset of Scheme. I have not finished the book yet; I'm at the beginning of chapter 4. I also thought that the code style used by SICP was the "standard" one. Is there a scheme code style you recommend for me to follow? >Also, aren't you that Unix guy who writes his own stuff? I pity you for that, because if you go on this path, you might end up understanding Emacs and you'll recognize that all your prior work was superfluous, all the minimalism meaningless and all the dogma was a senseless restriction. But hey, on the other hand it is always good to see people grow out of their old selves. I don't know if I am the one you are thinking of. But yeah, I am a UNIX guy who writes my own stuff. I don't quite see what's the problem with writing your own stuff and with minimalism. However, I also had my prejudice about lisp: I always thought that lispers use layers upon layers of abstraction without caring about how the layers below the one they are using are implemented. And that goes against the minimalism I was taught of. On emacs: it's still a beast that I need to understand and tame.

>>30182 >I will read the R7RS. It is a short document, but very terse; I like that. It is honestly a joy to read. >It seems that SICP uses a subset of Scheme. I have not finished the book yet; I'm at the beginning of chapter 4. I also thought that the code style used by SICP was the "standard" one. Not really, SICP uses what was available in the 80s, just because it was written back then. >Is there a scheme code style you recommend for me to follow? AFAIK the style differs from implementation to implementation. Despite being standardized, it is said that Scheme (more to than Lisp) is extremely fragmented. I argue this is precisely due to it's minimalism. The issue is comparable to how various UNIX implementations diverged before POSIX acknowledged the real needs that all the extensions they provided. >However, I also had my prejudice about lisp: I always thought that lispers use layers upon layers of abstraction without caring about how the layers below the one they are using are implemented. And that goes against the minimalism I was taught of. To me this just proves that minimalism is a vapid concept. Anything you feasibly do is building upon layers of layers. Keeping stuff small for their own sake is a non-virtue. Small code-bases are only valuable in so far this serves an aim, such as making hacking easier, thus allowing for software freedom to be more feasible. That does make a difference, because software freedom changes the way you relate to a computer, and isn't a performative placebo. > On emacs: it's still a beast that I need to understand and tame. Indulge in it, it is a liberating experience.

Would it be possible/make sense to do something like Parenscript https://parenscript.common-lisp.dev/ For other languages like C,C#,Java,Kotlin,Python,Forth,Smalltalk and even stuff like Dart? It would mean that I can compile to all of those languages from CL which I would really appreciate.

>>30187 The benefit of paren-script is that you can now run lisp on the web. Transpilation to JS is not really the objective, it just happens that JS is the assembly language of websites. What would be the benefits of transpiling to something like C#? It would run anywhere that CL runs, for all practical purposes it would be the same as it is running from sbcl.

>>30188 >What would be the benefits of transpiling to something like C#? You could run your CL stuff in C# ecosystems and could maybe even have an interop for C# code. You could also use stuff like xamarin, which would make mobile development easier for example.

>>30187 >C ECL compiles down to C if you're interested. >>30189 If the goal is interoperability there are often better ways to achieve it than compiling down to the desired language (say, foreign function interfaces, or implementations on top of common platforms). Like ABCL to Java, a Common Lisp on top of the CLR would give you as much potential to interoperate with C# and other .NET languages as a CL that compiles down to C# would, potentially without many annoyances that would come with the latter approach (like the need for a working C# toolchain), for example.

Beginner programmer here working my way through SICP and trying to do as many exercises as I can. I had a question on one of earlier exercises where it's supposed to take a list of items and return all the numbers in the list that share a specified property of the first number, in this case it's supposed to be parity (evenness and oddness.) The solution I thought up was to copy all the numbers and a checking procedure into a new list, where it would then evaluate and return either the number if the condition is satisfied or () if it is not. My implementation is as follows, but it keeps looping. I think the problem is with the null? check, but I'm too much of an amateur to know how to fix it. (define (same-parity x . y) (let ((parity (remainder x 2)) (match-list (list))) (define (process i) (define (checker a) (if (= parity (remainder a 2)) a ())) (if (null? i) match-list (append (checker (car i)) (process (list (cdr i)))))) (append x (process y))))

>>30211 process uses null? to check its argument for emptiness, but its argument can never be empty because it's not getting any smaller. This is because, on each recursive call to process, you're not passing (cdr i) but (list (cdr i)) - a list with one member (itself a list), always. Additionally, checker returns either an atom or an empty list, yet its caller blindly passes its output to append, which takes a proper list for its first argument. For it to work the way you're doing it, checker shold return (list a) or (). The same error will catch you at the bottom line, where you call append on x instead of (list x). With these three changes, your program works. There is a straightforward way to do this which is more elegant, more readable and more efficient to boot, but don't worry - if SICP will teach you one thing, it's how to recur on lists. You've come up with a way that works, and have simply failed to implement it correctly because lists still confuse you; you're on the right track.

>>30211 On your code: - You seem to be recurring into nowhere. Think of where your i argument to process converges (let's ignore the rest for now): (same-parity 1 1 2 3) -> (process '(1 2 3)) -> (process (list (cdr '(1 2 3)))) = (process '((2 3))) -> (process (list (cdr '((2 3))))) = (process '(())) -> (process (list (cdr '(())))) = (process '(())) [...] You always take the tail of the list, then put it inside a list and recur, which means you'll never have an empty list, but at best a list with an empty list, so null? is never true. But most importantly, it misses the point of what you're trying to do: iterate through elements of a list. Think of the structure of a list: chained conses, with an element on car and the rest on cdr, terminating with the empty list, so, say, '(1 2 3) is the same as '(1 . (2 . (3 . ()))). Now, you want to go through every element of this list and do whatever with each one of them: the car of a cons has an element, and the cdr has the rest of the list (another cons), so: operate on (car '(1 2 3)) = 1, recur on (cdr '(1 2 3)) = '(2 3) operate on (car '(2 3)) = 2, recur on (cdr '(2 3)) = '(3) operate on (car '(3)) = 3, recur on (cdr '(3)) = '() '() is the empty list, you're finished. This is called structural recursion, because it recurs over the structure of your data, uh, structure (which is itself recursive; you may notice a symmetry between recursively consing a list and recursively iterating through it); if this makes no sense to you, it might be worth revisiting the portion where they introduce conses and lists. - append takes lists and returns the concatenation of them, but you're giving it atoms: On the first case (same-parity 1 2 3) evaluates (append 1 (process '(2 3)), that will give you an error when the call gets evaluated. What you want is to cons the atom in front of the list ((cons 1 '(2 3)) = '(1 . (2 3)) = '(1 2 3)). On the second case, you append the return value of checker to the result of processing the rest of the list; checker, however, will return an atom on the true case and a list on the false case (note here, you probably want to quote your empty list, so '() instead of (); "the empty list rather than the result of evaluating the form that is the empty list"). Appending rather than consing here is right, since your approach to filtering is appending none or one value to the recursive answer depending on whether the predicate matches, so you instead just need to ensure checker returns a list regardless (note this is also a valid solution to the first case, but it is less natural), either empty or with the element you want to accumulate. - match-list is always '(), you don't really need it (think about why). On your approach: It works (and there are cases in which it makes more sense than the alternatives, like when you want to go over a list and accumulate a variable number of values on each iteration, for example), but there is a better way of going about filtering in specific, in case you're interested: try thinking of your process function recurring over i while consing the return value in 3 different cases: i is null, (car i) has the right parity, and (car i) has the wrong parity.

>>30212 >This is because, on each recursive call to process, you're not passing (cdr i) but (list (cdr i)) - a list with one member (itself a list), always. You know, I thought this as well, but the interpreter keeps giving me an error that it was the wrong type of data. I don't have much of an understanding of error codes or even computing right now, but I'm going to make a concerted effort to do so. >which takes a proper list for its first argument Oh, now I get it. Jesus. >There is a straightforward way to do this which is more elegant, more readable and more efficient to boot I'm pretty pathetic as a programmer. I usually spend hours if not days on exercises, and even if most of it is rumination I feel like I've jumped in the deep end. I definitely need to work more on algorithm design, so I've started Concrete Mathematics, but I'm also a pretty pathetic student. To be fair to myself, though, Scheme is a syntactically unfriendly language to work in. >>30213 I don't have the time now to read and comprehend your post, but I just wanted to acknowledge it anyways. Thanks.

>>30218 I'm >>30212. I once spent no less than three consecutive days doing nothing but try to implement a simple sorting algorithm (I forget which) in C. I've gotten better, and so will you. Always push yourself, but don't punish yourself for not getting things right. And don't make things unnecessarily hard for yourself: if something's difficult to understand, make a picture of it so you can see it, or make a physical mockup so you can watch it in motion - use the things that your ape brain is actually good at. That's what geniuses do.

>>30141 Super cool work lain. I'm in a Theory of Computation class this semester too

How much overlap is there between Peter Norvig's PAIP and his latest edition of AIMA?

>>30363 AIMA uses python now, but in theory you can do everything in LISP as well. Norvig has even done so on the AIMA github if you want to look at it.

>>30211 map, reduce and filter are your functional friends. Try: (define (same-parity x . y) (let ((lst (cons x y))) (keep-matching-items lst (if (even? x) even? odd?))))

What is the better way to actually earn money with your common lisp knowledge? Found your own startup or try as hard as possible to find a CL based job(there are not many so it seems to be quite impossible but I'm not sure) Did anyone of you lainons or someone you know ever have success with something like that?

>>30395 you simply accept that you will most likely never make any money using common lisp directly unless you can somehow found a startup (in which case you'll only be able to get funding if you're making the kinds of soykafty tech startup products that you probably have no interest in making if you're into something like common lisp) and treat it as an enjoyable creative activity that doesn't belong in the sewer that is the tech industry. almost no one still uses common lisp. but programming knowledge is pretty transferrable across languages, so if you care at all about trying to get a job programming, you'll probably be fine as long as you can demonstrate that you know how to program and at least are familiar with a given language. though if you're into common lisp you probably already know that once you start using it, almost every other language will feel incredibly unproductive, unergonomic, and ugly

Is it true that learning lisp as a first language will spoil my enjoyment of other languages?

>>30463 >Is it true that learning lisp as a first language will spoil my enjoyment of other languages? Learning Lisp at any point can make you wish to have Lisp features in other languages. The first language you learn will affect a lot how you think about programming. Learning Scheme as a first language is a good idea since Scheme is small and simple language, which makes it easier to learn actual programming concepts. Check out Little Schemer and Simply Scheme (https://people.eecs.berkeley.edu/~bh/ss-toc2.html). I recommend you use Guile or Chicken in interpreter mode. Also, Racket has the DrRacket IDE which is great for beginners, you just need to set the language to R5RS.

I've resumed learning Latin, and now I pronounce NIL as kneel, knowing it to be the abbreviation of NIHIL that's NĪL. What of you? >>29765 I recommend finding ways to avoid using a C language library entirely. I've seen someone before who bound to C language functions, equivalent to some which Common Lisp provides, purely due to ignorance. In particular, it was using isatty in preference to INTERACTIVE-STREAM-P. Learn the language well before pulling in garbage. >>30000 >>30127 I program in CHIP-8 machine code with my customized tooling, and I can attest to a simple "Hello World" program being a few dozen instructions at most. >>30141 Many of my projects are only implemented in Common Lisp, not being flavoured by it, but can be found or linked in this thread: >>28919 >>30463 Lisp was my first language, and it didn't ruin for me Ada, APL, or playing with machine code. Common Lisp is a properly-designed language, as are Ada and APL, and so using languages such as these first opens one's eyes to glaring issues with other languages. For example, Common Lisp hash table searches with GETHASH return a second value, in case NIL weren't being held and in case the programmer wishes to distinguish this case; other languages simply ignore cases such as this, and leave no good way to solve it. Isn't that awful?

>>30465 >now I pronounce NIL as kneel Will you start pronouncing null as nūll[us] as well? :) >What of you? I thought that sounded very anachronistic, but that clipping turns out to have been historically attested. https://en.m.wiktionary.org/wiki/nil#Latin I still prefer the English pronunciation of nil.

>>30466 >I thought that sounded very anachronistic, but that clipping turns out to have been historically attested. It should; this is the book from which I'm learning: >>>/lit/5105 >Will you start pronouncing null as nūll[us] as well? :) I'd given it no thought, as I never really use the word, but yes.

>>30465 >other languages simply ignore cases such as this, and leave no good way to solve it. Isn't that awful? Way to prove yourself ignorant. Or were you joking? I know of literally no language that cannot detect if something isn't in a hash table (e.g. C++'s map have at/find methods, Tcl's dict get produces an error, etc...).

>>30471 Don't misunderstand me; I meant cases like that, not necessarily that exact case. Do I need to find an example, or can my word be taken?

Anything on lisp compilation techniques?

>>30476 Do find an example, it can't be uninteresting. I'm actually learning Common Lisp and it can be seriously retarded in some ways. For example, I'm working with images in the form of multidimensional arrays (via opticl), and if I want to do the equivalent of memcpy between two of them and there's NOTHING. So, unless I want to loop to accomplish this (no), I must use displaced vectors to be able to call replace.

>>30488 >Do find an example, it can't be uninteresting. One example is the gets function, which simply can't be used. It turns out providing an easily-used interface requires basic infrastructure. The atoi function can return zero when given "0", or in other cases, and has undefined behaviour in yet other cases. Lastly, the strcpy function has similar failure modes to atoi, in cases a function would really be expected to handle. >I'm actually learning Common Lisp and it can be seriously retarded in some ways. Point out similar such flaws. Common Lisp may be unusual, but I don't recall any blatantly broken interfaces. >For example, I'm working with images in the form of multidimensional arrays (via opticl), and if I want to do the equivalent of memcpy between two of them and there's NOTHING. Common Lisp isn't its libraries. I use none of them, only the standard. Why would such a thing be necessary, anyway? >So, unless I want to loop to accomplish this (no), I must use displaced vectors to be able to call replace. That seems acceptable to me.

>>30504 >Common Lisp isn't its libraries. I specifically mentioned that opticl uses standard multidimensional arrays, which have basically no support from the language, since they're neither lists nor sequences; so no map, no filter, no loop, etc... (which is why array-operations exist). >That seems acceptable to me. (defun image-offset (img x y) (apply #'array-row-major-index img (if (= (array-rank img) 3) `(,x ,y 0) `(,x ,y)))) (defun image-copy-range (src dst length &key (start-src '(0 0)) (start-dst '(0 0))) (flet ((tempseq (img length start) (make-array (* length (image-chan-num img)) :element-type '(unsigned-byte 8) :displaced-to img :displaced-index-offset (apply #'image-offset img start)))) (let ((svec (tempseq src length start-src)) (dvec (tempseq dst length start-dst))) (declare (dynamic-extent svec dvec)) (replace dvec svec)))) vs memcpy( dst->data + dsty * dst->width + dstx, src->data + srcy * src->width + srcx, length * src.bpp ); Disregard the code smell from my newbie CL, it's still quite sad; especially since I chose C to be nice to CL, C++ would have used an operator() method (though neither C nor C++ having real multidimensional dynamic arrays is pathetic in its own right).

>>30506 Forgot to multiply by bpp in the memcpy pointer offsets; well no matter.

Wanna convince me about beauty of Lisp? Write a program that prints out textmode plot of mandelbrot set that does not look like nightmare fueled hallucination of Alonzo Church.

>>30506 >which have basically no support from the language I can agree it's not good, but it's also not broken. Implementing the necessary routines, possibly as a library, is the typical solution.

>>30504 >One example is the gets function, which simply can't be used. It turns out providing an easily-used interface requires basic infrastructure. >The atoi function can return zero when given "0", or in other cases, and has undefined behaviour in yet other cases. >Lastly, the strcpy function has similar failure modes to atoi, in cases a function would really be expected to handle. So you mean the cumcrust filled parts of the language? Ehhh, I'd say PLs that were designed well by experienced programmers with enough retrospective (i.e. no the C++ workgroup) don't have too much of it, but CL does have stuff like proclaim/declaim or plists/alists vs hash tables; though CL's worst crust is in the names, but that's because it's Common Lisp, not it's fault.

>>30534 By proclaim/declaim, I mean proclaim existing. I guess some others would be set/setq still existing or some retarded loop omissions like `across vec` were you cannot adjust the step or bind more than one element (would be nice to do a sliding window), nested looping being awkward or the aforementioned lack of multidimensional array support. named-readtables shows another tragic oversight. There's no getdelim equivalent and extensions like https://franz.com/support/tech_corner/read-line-variants-071406.lhtml are seriously needed for performance I/O. I could continue all day with thousands of paper cuts, because I'm not yet used to them.

>>30534 I wasn't listing cruft, but entirely broken parts of a language. Common Lisp isn't afflicted with simply broken things, as other languages are. Also exempt are Ada, APL, and others.

>>30538 If you ask me, proclaim IS broken, and declaim is to proclaim as fgets is to gets or snprintf is to sprintf. C was indeed standardized too fast but I doubt it'd have been much better in any case (unlike UNIX itself), the retrospective of the general engineering community (not academic, which already had Lisp) was just not long enough; I mean, we got stupid stuff like a maximum symbol limit of 6 (cf 5.2.4.1 Translation Limits) because it was normal during the time of Fortran and PL/1. The same way that C is just too old (though "okay" because it's not trying to be more than what it can, like C++), Common Lisp shows its age through a standard that doesn't (and couldn't) incorporate stuff like threads, atomics or SIMD programming. But in the end, even with all the flaws of "unifying" standards like SuS/POSIX or CL, it's still better than unstandardized garbage of the week with a single "complete" implementation.

CLASP has finally gotten a 1.0 release (new Common Lisp implementation on the LLVM for C++ interop): https://github.com/clasp-developers/clasp/releases/tag/1.0.0

>>30571 Now that's cool.

>>30571 Epic, I have a few ideas of what to do with it (Mostly ARM stuff, and exploring, well, more complex ideas related to compiling with Lisp)

>>30571 I really can't wrap my head around anything influenced by lambda-calculus

>>30583 It's just function application. Start with a function. Put some variables into it (binding). Run the function. Repeat. Functions are also variables so a function can contain a function ad infinitum. What to do with that? Well just run the innermost function and substitute the abstract function for its concrete variable (reduction). Repeat until you have a concrete return value (or not, since you can produce infinite loops and other non terminating values)

>>30583 Lisp dialects are really simple. Everything uses the exact same syntax except the few special forms, like IF The parenthesis become "invisible" once you get used to them (also, the parenthesis make the order things happen 100% clear). >>30611 this.

>>29564 >reformat the paragraph such that each sentence is on its own line Sounds like a job for regexp.

>using C++17 at work (so no concepts) >having to use constexpr to write is_sequence_container or is_iterator that should have been in type_traits already >slowly realising how pathetic C++ is compared to CL; in CL, the whole fuarrrking lang is "constexpr" while you don't even have a constexpr for in sepples (inb4 fold expressions or fuarrrking recursive templates) >have to write my own multidimension array class >read/hear from industry programming gurus (read: not hackers) how "powerful" template meta-programming is and how constexpr is the second coming of Jesus Save me.

>>30691 Oh, and forgot a related dismay: something with such comparatively low funding/manpower as SBCL can inform me when it fails to optimize some code, meanwhile g++/clang++ can't tell me if a constexpr function call was dispatched at build time or not.

>>30691 People bragging about making big things with c++ templates is like bragging about making a raytracer in ms excel, or opening a bottle with your teeth Sure it sort of seems impressive, but it doesn't accomplish anything, and that time would've been far better spent elsewhere

>>27327 question: as someone who's seriously pursuing learning to program since rather recently (after using linux for a long time), is reading SICP and following along with the recorded lectures actually worthwhile or just a larper thing to do? I've heard that learning lisp and understanding it can help make you a better programmer, so it's been my plan to do so in the future. if not SICP, are there any better or more modern books you would recommend?

>>30826 i think its worth giving it a go but if you find it hard there's no problem with coming back to it at a later point. I think there's some really great gems in the lectures and book particularly the metacircular evaluator is a good introduction in how interpreters work, i think its good for compsci in general. but there are easier books for lisp.

I've been struggling with an exercise in SICP for a few days now. Unfortunately, I'm not just a Windows user fuarrrking 8.1, but literally retarded who can't install an interpreter, so I've been hacking my way along using an online interpreter, but this has its limits because even if it was fully functional, I am definitely too retarded to know it. I will be setting up a proper system in a bit, but for now bear with me. I just need to know if I have the right idea about something. Anyways, the exercise I was having trouble with was 2.58b if you could look that up, which is about symbolic differentiation. The specific idea is to have the interpreter be able to process an infix mathematical expression and return its derivative. Certain operations have precedence over others (PEMDAS), so the program needs to be able to calculate the derivatives of products before the derivatives of sums. I look around on a community forum, and the solutions do all this complicated stuff about setting up tables and manipulating the data in such a way that the original program needs no modification, but that is beyond my skill level and I'm convinced, at the risk of sounding like a smartass, beyond the skill level the exercise expects. If you have an expression (a + b * c + d), the derivative procedure would first do the sum of the deriv(a) and deriv(b * c + d). Unchanged, the next calculation would be the sum of deriv(c+d)b and deriv(b)(c+d), which is wrong because * is supposed to take precedence over +. My solution to it was as follows. It is an incomplete version of the procedure, but you can see the full version in the textbook. (define (augend exp) (cddr exp) (define (multiplicand exp) (caddr exp)) (define (deriv exp var) (cond ((product? exp) (let ((a1 (make-sum (make-product (multiplier exp) (deriv (multiplicand exp) var)) (make-product (deriv (multiplier exp) var) (multiplicand exp))))) (deriv (append a1 ((cdddr exp) var))))) My idea was to have the augend be the rest of the expression while the multiplicand would be just be the first part of the rest of the expression. I'd like to know if I'm on the right track because I am too much of an idiot to test this.

>>30840 my advice would be to be more patient. if you can't even install an interpreter, it's not an indication that you're stupid, but rather than you're not taking the time to actually figure it out then troubleshoot any issues you encounter fuarrrk you, flood detection, i don't even type that fast.

>>30841 Once I finish my new computer and install gentoo (soon,) I'll figure that soykaf out, but for now I'll just have to deal with the illiteracy. First thing I'll do is figure out the difference between an interpreter and compiler as well as what exactly an interpreter and a compiler are.

>>30842 an interpreter executes stuff on the fly. it's not directly executed by your cpu, but rather by the software. a compiler creates machine code, which you can then use your cpu to execute.

>>30840 There's a reason you struggled and it's because MIT Scheme (which SICP is based on) is no longer available for windows. You can download racket and then use the sicp packaget to get usable environment (https://pkgs.racket-lang.org/package/sicp).

I'm trying to wrap my head around the CL MOP, but the AMOP seems daunting. I'm trying to find libraries that implement the MOP thats readable for the beginner and so far I've found json-mop and iclander. Can anyone recommend some well documented libraries applying the MOP that I can learn from?

>>30840 >>30842 Use VirtualBox (https://www.virtualbox.org/) to get a GNU/Lunix environment (you could even practice installing Gentoo, unless you have a low-end computer). Or install (dual-boot) a GNU/Linux distro. Also, you might be interested in >>30711 if you want to install Gentoo. >>30844 This also works but GNU/Linux is more comfy (even if you used Racket).

I'm going to write a ranger-style GUI file manager in CL next holidays and I have a few questions: * McCLIM, cl-ffi-gtk or LTk? I want to do something a bit like emacs' client/server model, so can I spawn a new window in a separate thread (not a process) with its own event loop with any of these toolkits? Can any of these do XEmbed? * Where can I find a list of builtin McCLIM gadgets? Because I'll want at least some kind of table widget. * One of ranger's main problems I want to fix is to compute the current entry preview only if X ms have passed since selecting it; do you have any idea how to do such a thing efficiently without a builtin event loop like Tcl's? Other features I miss it'll have: some tag based thing either using a system daemon or simply xattrs, sorting files by some tag, mtime-based preview caching not only for image files and directories, some way (db, hidden file) to specify the sorting type per directory and remember it

>>30847 My parts are coming today, so I will hopefully have it assembled by the weekend.

>>30847 >>30711 One thing to note is that Layman is deprecated. You should use eselect-repository instead. >>30853 A tip for installing Gentoo: either use a phone/another computer to read the handbook, or: create a new temporary user: useradd -m -G users lain (in the LiveUSB environment) and use links to access https://wiki.gentoo.org/wiki/Handbook:AMD64

>>30846 Lain you might find some good examples of using MOP concepts in the scheme world. They are not CL libraries, but they are relatively small and illustrative examples of the fundamental features. >Gauche scheme https://github.com/shirok/Gauche https://practical-scheme.net/gauche/man/gauche-refe-draft/Metaobject-protocol.html#Metaobject-protocol A practical and well documented scheme that is designed and implemented on a MOP. MOP libs to highlight: -threadpools -fsdbm -*new* temporal differentiation pedagogical implementations of a MOP in: >Tiny-CLOS http://community.schemewiki.org/?Tiny-CLOS <800 lines of mostly comments, a pure implementation of a MOP. > Meroonet From the book Lisp in Small Pieces, apparently a great book on implementing a lisp Additional implementations can be found tied to the Stklos and Gerbil runtimes.

>>30847 A simpler and more accessible alternative is Cygwin (https://cygwin.com/) that gives you a Unix-like environment complete with the usual GNU tools. Of course a full GNU/Linux combo distro is better, but it's a lot easier to get started with. No need to fear about making the jump.

>>30506 You don't need any of that (defun image-copy-range (src dst length &key (start-src '(0 0)) (start-dst '(0 0))) (replace dst src :start1 (apply #'image-offset src start-src) :start2 (apply #'image-offset dst start-dst)))

I made a thing , I've been learning scheme for a month or so now. https://gitlab.com/ardente-/lsd It's scheme but stack-based and without macros (i don't know how i'd implement those). Feel free to provide feedback. It's more of a spare time project than anything. >inb4 using λ and soykaf I like it, it's more concise and shorter, gives me less to worry about and my compose key works fine so I figured I'd better use it. I made another thing in scheme that I spent more time on which I'll publish at some point.

>>30930 You don't create the displaced arrays so yours won't accept multidimensional arrays. The only issue with the original was that it returns a dynamic-extent variable. (defun image-copy-range (src dst length &key (start-src '(0 0)) (start-dst '(0 0))) (macrolet ((tempseq (img start) `(make-array (* length (image-chan-num ,img)) :element-type '(unsigned-byte 8) :displaced-to ,img :displaced-index-offset (apply #'image-offset ,img ,start)))) (let ((svec (tempseq src start-src)) (dvec (tempseq dst start-dst))) (declare (dynamic-extent svec dvec)) (replace dvec svec)) ;; Replace here would return dvec, so you need values below. (values))) The dynamic-extent probably doesn't do anything in practice though, so it could be removed along with the 4 lines it takes up.

>>30933 >You don't create the displaced arrays so yours won't accept multidimensional arrays. It does accept multidimensional arrays, image-offset properly passes the multidimensional index to array-row-major-index

>>30935 A multidimensional array is not a sequence and can not be passed to replace. I have run your code and it has given me that error. The only sequences defined by the common lisp standard are vectors (single dimensional arrays) and lists.

>>30935 Way to embarass yourself, anon. Did you not even try to run your code?

>>30925 Thanks a lot for the info!

Discovered that Bordeaux doesn't have rwlocks, damn. Together with CL's default hash table being totally unsuitable for efficient locking (you can only lock the whole table), this means I'll have to write my own using chained hashing with a rwlock (that I'll also have to write using poorly portable atomics) per bucket and maybe an option to use either a list or a vector for the bucket (or something more advanced, like an BST/AVLT). Is there a PL with proper thread support in all of its data structures? Proper meaning optional during object instanciation and with an optimized implementation for each case. Or even ideally, having four variants per container: {1, N} readers × {1, N} writers.

Sup lainions. I've been interested in lisp for a while, but never get a chance to use it on a regular base. It's quite hard to understand lisp as an idea, not a solid realisation. I've used python a lot in my private projects and I was pretty happy with this. And now I see lisp is good too. But can lisp be fast and cool if I'd like to use it in my mini dumb scripts? e g I could very easly code python script what gets, solves captcha and post some dumb soykaf. But will it be just as convenient in lisp?

>>31019 Depends on the lisp chosen. If you go for something like Racket then I would say yes.

>>31019 I'm pretty sure that lisps run faster and are faster to write than Python scripts. >>31021 >Racket this.

>>31022 >>31021 I've heard Racket is bloated and used in scientific projects only. Also that it is slow. Reading this thread I can assume Common Lisp is better choise. But one thing horrified me - is it necessary to learn emacs to code lisp? Seems like it's the only way to do it right

>>31025 >But one thing horrified me - is it necessary to learn emacs to code lisp? No, but you get the best experience with emacs+SLY or emacs+geiser. There are plugins for NeoVim and VSCodium, I believe: https://lispcookbook.github.io/cl-cookbook/editor-support.html Also, you can learn enough Emacs with its build-in tutorial (that takes like 30 minutes to complete). You only need to use M-x list-packages to install SLY & rainbow-delimiters and then you need to add: (add-hook 'prog-mode-hook #'rainbow-delimiters-mode) (setq inferior-lisp-program "/usr/bin/sbcl") to the bottom of your .emacs file. You may wish to change the default theme of emacs: M-x customize-themes There is also a good blog post about Gnu Emacs distributions, like Doom Emacs: https://amodernist.com/texts/ecg.html imo, Doom Emacs is better than the rest of them but using vanilla Gnu Emacs and building your .emacs config file yourself is better. Btw, if you are looking for a place to start learning common lisp, check out https://gigamonkeys.com/book/ or https://www.cs.cmu.edu/~dst/LispBook/

>>31025 Why the fear? At worst it is a great excuse, and it might help you overcome your concern the pseudo-category of bloat.

>>31026 Thanks, anon. I have experience using doom and space emacs, but as I can tell they are kinda slow. (tons of plugins may be the reason) Using vanilla emacs is truly pain, 'case I forced to build my own editor. In other case it is not usable at all. But if you insist, maybe I really shall drown in configuration way deeper (never done it myself tho). >>31027 As I said emacs is not a programm that makes things done. Emacs is a programm to build programms that makes things done. It' a constructor, and you should really know it perfectly to do what you want. That's kinda tricky in case I am not really used to that sort of idea. Also I'm questioning myself if it is worth learning all that (complicated emacs)

>>31026 >SLY & rainbow-delimiters You might want to also install magit and company mode. >>31028 >but as I can tell they are kinda slow. Emacs 28.1 added support for JIT compiled elisp which should improve the performance a lot. >maybe I really shall drown in configuration way deeper (never done it myself tho). If you want vim keybindings, install evil-mode or use Doom Emacs. You should start with from scratch or from a very simple .emacs file, and find & add stuff that you need over time. >Also I'm questioning myself if it is worth learning all that (complicated emacs) You should learn either NeoVim or Emacs, imo. Try the tutorials and see which one you like more. NeoVim and Gnu Emacs aren't that complicated once you learn the basics. Perhaps you want to see what Emacs has to offer: >https://emacsrocks.com (pick the episodes that seem interesting. I really recommend ep. 17 and ep. 16) >https://www.youtube.com/watch?v=MRYzPWnk2mE&list=PLxj9UAX4Em-IiOfvF2Qs742LxEK4owSkr&index=1 (watch this video next) >https://www.youtube.com/watch?v=d6iY_1aMzeg&list=PLX2044Ew-UVVv31a0-Qn3dA6Sd_-NyA1n&index=1 (complete tutorial. also, check out his org-mode tutorial if you are interested) (SLIME)/SLY, Geiser, magit, dired and org-mode are Gnu Emacs "killer apps". I also like the elfeed RSS reader.

>>31030 Thanks a lot <3

>>31025 >Also that it is slow. Racket switched to Chez for its backend a while ago, and it's gotten a lot faster now. https://ecraven.github.io/r7rs-benchmarks/ >is it necessary to learn emacs to code lisp? I use Emacs, but there's some people out there that use Vim with Vlime or Slimv for Common Lisp. https://github.com/vlime/vlime https://github.com/kovisoft/slimv

I've not posted here in a while, so I suppose I'll show this library I've recently written: http://verisimilitudes.net/2022-05-03 It's a trivial trie in Common Lisp, sufficient for my needs. I'll probably add a partial searching function and a SETF expansion later.

If someone can manage to make CL-PPCRE's performance look less ridiculous, please help me: https://github.com/mariomka/regex-benchmark/pull/43

>>31058 Please do your best to try and stay anonymous. If you really have to wage slave, try saying something "Look at this cool blog post I found".

>>31069 That guy is pretty much a mod in lain/λ/ and also the OP in this thread. You can also see his site being posted in OP to find Lisp's book.

>>31072 >he's a mod so what. I only want to see mods identified when they're moderating.

>>31075 Sure. But you can easy recognize his post in any thread, even if he doesn't identify himself or post his website link. You also don't need to complain about someone posting their own website.

>>31075 This place is his own little insider trade, but there is no rule, unspoken or otherwise, enforcing anonymity of it's users. The fact that a site is anonymous in nature, doesn't mean people have to be. Also what's it to you?

>>31069 After so long using anonymous imageboards, I've decided it's unreasonable to share most work without some consistent identity. This format is usually fine for discussions, but larger work is rarely ever mentioned anonymously, and why would it be mentioned without an identity? It's almost entirely unreasonable to collaborate on something large with no identities whatsoever. The closest example of which I can currently think is Bitcoin, which was pseudonymous. I could've posted it here directly, but there's little point. Even then, I started making these threads over eight years ago; I simply don't care anymore. >If you really have to wage slave, try saying something "Look at this cool blog post I found". That would be dishonest, so I don't. >>31072 I don't lord it over anyone, but I'm an administrator and this is my board, yes. >>31080 >But you can easy recognize his post in any thread, even if he doesn't identify himself or post his website link. The stranger my writing style becomes, the more easily I may abandon it to make the posts I don't want others to link to me. >>31081 >This place is his own little insider trade I didn't want that to happen, but can I be blamed for it after so many years when it wasn't? Look at the Ada thread; I'm the only Ada programmer who posts anything there; I'm one of the only Ada programmers on Lainchan, if not alone. The machine code thread is the same way. There are only so many places to be.

My first CL "project": https://git.sr.ht/~q3cpma/cl-rwlock Please roast me in an educative fashion (inb4 no tests, it's WIP).

How does lisp work out for graphics programming? Are there any performance issues and such? I'm learning common lisp, and as far as I know, it has a garbage collector, and I imagine most other dialects have it too, so I'm thinking about how much that could impact performance compared to, say, C++. By graphics programming, I mean things like game (engine) development with opengl, vulkan, etc.

>>31141 I'm pretty sure that GC doesn't matter that much as long as it isn't naive (bad) implementation. Actually, a good GC is better than managing the memory manually by hand (a la C/C++). Using GC is faster for the developer and you never know exactly how long things live in the memory. Also, remember that there are games made in Java and even Python (even though Python is slower than any modern implementation of Scheme or Common Lisp).

>>31143 >Even though Python is slower than any modern implementation of Scheme or Common Lisp). Except for Unicode string processing, at least in CL.

>>31144 >Except for Unicode string processing, at least in CL. I wasn't aware of that. I would be interested in learning more about this. Got any links or anything?

>>31145 My own benchmarks, stuff like https://github.com/mariomka/regex-benchmark/pull/43 and the knowledge that since CL strings are vectors, they can't use variable length encoding like UTF-8 (with a boolean to do runtime dispatch for pure ASCII) which is very fast with today's branch predictors; so UTF-16 or UTF-32, which wastes memory (and memory bandwidth) in most cases.

>>31148 In general, all PLs should default to UTF-8 or similar (MUTF-8) for internal storage and provide another random-access-string type or something together with conversion functions. Even more logical when most of the world decided on UTF-8 with some Latin-1 here and there and retarded legacy crap like KOI-8/(Shift )JIS/Windows-1252, so you can avoid conversion when reading in a lot of cases.

>>31128 I don't see the purpose of this, and it is heavily-dependent on the quirks of single implementations. Shouldn't the underlying parallelism mechanism provide something similar? Tests are unnecessary. >>31149 Unicode is garbage, and it's truly disgusting to see the UTF-8 trash have people suggest that constant-time character access in a string would ever somehow be superfluous. Common Lisp wasn't built for this homogeneous world of garbage in which we now find ourselves, but that's not a mark against Common Lisp.

>>31141 CL is great for graphics programming, as it lends itself very well to interactive development. Baggers has a ton of videos doing graphics dev in Common Lisp on his youtube channel: https://www.youtube.com/user/CBaggers/videos (see the "pushing pixels with lisp" series)

>>31158 >I don't see the purpose of this You don't see the purpose of read-write locks? Are you a retarded? >and it is heavily-dependent on the quirks of single implementations. What are you talking about? It works on all major implementations except CLisp and just needs a workaround for SBCL, which is exactly what #-/#+ is made for. >Shouldn't the underlying parallelism mechanism provide something similar? Blame the CL standard for being too old to know about threads and atomics; and bordeaux-threads still doesn't have them. And no, rwlocks are never raw primitives and are always implemented on top of such primitives (mutex/futex and semaphores), like condition variables. >Tests are unnecessary. Yeah, right. >Unicode is garbage Sure, but screaming at the sun won't make it go away. And except emoji garbage and the codepoint/rune mismatch, what's the actual problem? Variable length encoding? I mean, with CJK stuff, you're going to need at least 4 bytes, which UTF-8 handles quite well. >and it's truly disgusting to see the UTF-8 trash have people suggest that constant-time character access in a string would ever somehow be superfluous. It isn't superfluous, it's just rarely needed (or show a me a task needed it that is widespread in all types of programs). As I said, two types are needed, each according to your needs.

>>31160 >You don't see the purpose of read-write locks? Are you a retarded? I could swear bordeaux-threads provides something similar enough. >What are you talking about? It works on all major implementations except CLisp and just needs a workaround for SBCL, which is exactly what #-/#+ is made for. Alright, that's fair enough. >And no, rwlocks are never raw primitives and are always implemented on top of such primitives (mutex/futex and semaphores), like condition variables. I believe I understand now. In that case, why bother complying with SBCL limitations and using bordeaux-threads? Surely the former could be elided. Is some performance concern the reason? >Sure, but screaming at the sun won't make it go away. Unicode is nowhere near the sun. All of this garbage is made by humans, and it can be discarded. >And except emoji garbage and the codepoint/rune mismatch, what's the actual problem? Already we agree that Unicode isn't like the sun. The sun is simple, and behaves reasonably predictably. Unicode is a fundamentally misguided goal, and it will collapse underneath its weight eventually. >It isn't superfluous, it's just rarely needed (or show a me a task needed it that is widespread in all types of programs). As I said, two types are needed, each according to your needs. Look into how Ada handles this. Rather than have a single character type, it has multiple types. It handles everything, instead of pretending only UTF-8 matters. Taking off the glasses, and seeing Unicode and UTF-8 for what they are, when the environment doesn't bend over backwards to force them on others, shows their grotesque nature. Wouldn't this be better: (defmacro with-read-lock-held (rwlock &body body) `(unwind-protect (progn (acquire-read-lock ,rwlock) (locally ,@body)) (release-read-lock ,rwlock)))

>>31162 >I could swear bordeaux-threads provides something similar enough. https://github.com/sionescu/bordeaux-threads/issues/77 >In that case, why bother complying with SBCL limitations SBCL is the major open source CL implementation, and the one I use. >and using bordeaux-threads? ??? How would I get portable mutex/semaphores without it? >Unicode is nowhere near the sun. All of this garbage is made by humans, and it can be discarded. There is no competing standard unless you're going the "ASCII should be enough" way. Btw, I'm French, so I do need those Latin(1 letters, sometimes. >Unicode is a fundamentally misguided goal Tell me how everybody in the world agreeing to have a symbol <=> codepoint bijection is misguided (inb4 combining codepoints, I know). Should there be a table per alphabet? What about mixing latin and CJK in the same string, for example? >Look into how Ada handles this Typing "Ada unicode string" in Google shows me a soykafshow on the level of C: the standard string type uses Latin-1 and it uses the C brain damage known as wide characters when you want more; https://github.com/Blady-Com/UXStrings is a non standard way of getting UTF-8. Honestly, use a lang with very good Unicode support (e.g. Tcl) to understand how painless it can be when done well. By done well, I mean "hiding the Unicode complexity well" (so, unlike ICU but more like libutf8proc/libgrapheme). What's your alternative, anyway? >Wouldn't this be better: Wouldn't want to do a release if acquire fails.

>>31163 Oh, I understand what these are now. Ada provides such a thing with its protected objects, a type of passive concurrency. >How would I get portable mutex/semaphores without it? I was commenting on having special code for SBCL, while also using a portability library. >There is no competing standard unless you're going the "ASCII should be enough" way. Interacting with Unicode may be forced by other systems, but that still doesn't make it like the sun. When I need it in Common Lisp, I use #+ and #- for the purpose. >Btw, I'm French, so I do need those Latin(1 letters, sometimes. Is French encompassed by Latin-1? I don't know. >Tell me how everybody in the world agreeing to have a symbol <=> codepoint bijection is misguided (inb4 combining codepoints, I know). Should there be a table per alphabet? What about mixing latin and CJK in the same string, for example? I could link to some tirades I've written, if that would be wanted. Issues with Unicode range from homoglyphs, to the emoji garbage, to prioritizing ASCII in UTF-8, to the Eastern character conflating, and yet more. Part of my current work involves something I believe to be fundamentally better than Unicode can be. Ada has types Character, Wide_Character, and Wide_Wide_Character, along with corresponding string types. There are also predefined subprograms for converting between different Unicode encodings. This is ugly and inconvenient, I agree, because Unicode is ugly and inconvenient. >Honestly, use a lang with very good Unicode support (e.g. Tcl) to understand how painless it can be when done well. Tell me what happens when one standard requires UTF-8 and another another encoding? These complications can't be eliminated entirely. >What's your alternative, anyway? It's related to my tirades, so I'll ask for confirmation before linking to them. >Wouldn't want to do a release if acquire fails. What if something fails between the ACQUIRE and UNWIND-PROTECT? Consider adding a boolean variable initially at T and later set to NIL, the return value of the ACQUIRE functions, along with a conditional in the unwinding.

If you were GOD of Common Lisp's standard library, how would you change it? What nits would you pick and how would you fundamentally alter its concepts? Here's a few I've been thinking of: - Replace "p" and "-p" suffixes with "?". We can have symbol chars in symbols, so might as well use them - Change +const+ and *special* var name styles to be only the suffix. I think it looks less awkward when using fully qualified symbol names. - Remove y-or-n-p, yes-or-no-p - Remove non-orthogonal notevery, notany, XXX-if-not since their non-negated counterparts can be composed with #'complement with no performance loss (compile macros can easily detect it) - Completely think over how pathnames should behave - Add networking to the stdlib, but provide a CLOS protocol for libraries to provide their own sockets - File I/O is currently tightly bound to the local filesystem. Allow opening files relative to a directory object, as a GF so that (third-party) sftp, ldap, or 9p session directories can be passed around as first-class citizens.

>>31184 1. Standardize and add atomic/thread/SIMD related stuff. 2. Standardize obvious language fixes like named-readtables, package local nicknames, gray (or simple) streams and some of alexandria. 3. Improve I/O so that something like Franz's simple streams or https://github.com/rpav/fast-io isn't needed. Change read-line into read-until. 4. Improve defclass by adding a mix between initform/initarg to use a form ON the user provided argument. 5. Add a way for the compiler to communicate its type inference info to macros/compiler-macros (I think there's something in CLtL2 for that). 6. Really integrate CLOS with the stdlib and use generics everywhere. Add something like https://github.com/marcoheisig/fast-generic-functions or Haskell's specialize pragma to avoid the cost in hot areas. 7. Use a specific string type instead of char vectors. 8. Related to 7, generalize sequence to anything that can be iterated on. 9. Together with 6, extend the concept of sequence beyond the pitiful builtin one by adding a sequence class and making list/arrays (and not only vectors; treating N dim. arrays as arrays of N-1 dim. arrays) derive from it. Integrate loop better with this concept too; making nested loop handier too? 10. Improve FS related stuff enough so that UIOP/osicate aren't needed. 11. Maybe add type parametrization to CLOS, that would tie in nicely with type specifiers. 12. Add a way to splice lists directly outside of quasiquoting. 13. I'd like the equivalent of Tcl's transchan to streams. More an implementation thing: make defclass not slow, slot type is currently ignored by SBCL. In general I've found writing high performance code tedious when writing CL; some kind of DSL to do so might be cool (in Tcl, one can use critcl to write C directly inside, for example).

>>31164 >It's related to my tirades, so I'll ask for confirmation before linking to them. You've piqued my interest so I would appreciate it. >>31184 >- Completely think over how pathnames should behave How would this change the result? Are you implying that we fundamentally more about filesystems now or just that we don't need to cater for such a wide range anymore? >- File I/O is currently tightly bound to the local filesystem. Allow opening files relative to a directory object, as a GF so that (third-party) sftp, ldap, or 9p session directories can be passed around as first-class citizens. Wasn't this part of the motivation for pathnames in the first place? >- Add networking to the stdlib, but provide a CLOS protocol for libraries to provide their own sockets A terrible idea. >>31191 >1. Standardize and add atomic/thread/SIMD related stuff. I would be hesitant to include atomic/thread related functionality still (unless its very abstract and doesn't promise concurrent execution ever happens). Also including SIMD is a terrible idea. >6. Really integrate CLOS with the stdlib and use generics everywhere. This can very easily become a bootstrapping issue. There's a reason SICL is taking so long. >7. Use a specific string type instead of char vectors. Is this actually required for fast strings? Does the standard say that every character must be the same size on memory? Though perhaps the character type could be fleshed out into constant size vs variable size. >8. Related to 7, generalize sequence to anything that can be iterated on. Like what? The CL committee made a point of not specifying something if the answer didn't always make sense. >treating N dim. arrays as arrays of N-1 dim. arrays I don't understand what you mean here. >10. Improve FS related stuff enough so that UIOP/osicate aren't needed. How much improvement is reasonably possible considering the standard should support at a minimum every obscure OS that is still in use somewhere.

>>31374 >I would be hesitant to include atomic/thread related functionality still (unless its very abstract and doesn't promise concurrent execution ever happens). The alternative of implementation defined stuff needing effort of a library like bordeaux is worse. And honestly, lots of PLs have very opinionated stuff like CSP without problems. But I do agree that for CL, staying close to the OS primitives makes more sense. >Also including SIMD is a terrible idea. Why? Anyway, it's happening: https://github.com/marcoheisig/sb-simd/commit/e7829b3d9fe4ed6feca2869b292ef35bf53a4add >This can very easily become a bootstrapping issue. There's a reason SICL is taking so long. This is true. >Is this actually required for fast strings? Does the standard say that every character must be the same size on memory? Though perhaps the character type could be fleshed out into constant size vs variable size. I wouldn't say "required", but all fast string langs (e.g. Tcl, Perl) use UTF-8 internally, while Python doesn't (it uses 1, 2 or 4 byte per char, according to what's enough for the string). >Like what? The CL committee made a point of not specifying something if the answer didn't always make sense. Like the aforementioned UTF-8 strings that clearly needs a state to be iterated on. In general, something as general as iterators would be nice. If generics were to be used, a next method returning a (values the-actual-value nil-if-this-is-the-end) taking a state argument would be perfect; iterating on hash maps, trees, generators, etc... would work seemlessly. I'd worry about optimization, though. >I don't understand what you mean here. I mean that a matrix can be seen as a an array of vectors, and iterating on each vector should be possible (generalize to any dimension number). >How much improvement is reasonably possible considering the standard should support at a minimum every obscure OS that is still in use somewhere. Few, actually. Most of what PCL's fad then UIOP did was remove some undefined behaviour (https://gigamonkeys.com/book/practical-a-portable-pathname-library.html). The other functions would be stuff reading files and so on. Another though I had: maybe try to bridge the hard divide between classes and types. Basically, generics could work on anything, not just objects; after all, how does + does internally? Something akin to typecase, right? Or standardize better the difference between structs and classes (for example, with-slots works with structs on almost all impls, but isn't standard conformant).

>>31380 >The alternative of implementation defined stuff needing effort of a library like bordeaux is worse. There's nothing stopping an implementation from bundling it like they already do with ASDF and UIOP. >Anyway, it's happening: An extension for SBCL is not the same as including it in a language standard. >use UTF-8 internally What does this mean except their functions understand UTF-8 characteristics like variable length characters? >mean that a matrix can be seen as a an array of vectors Right. >Another though I had: maybe try to bridge the hard divide between classes and types. I've been thinking about a way of implementing a nice clean type system where you can define "implementation" and "point in type tree" differently (whilst not making type checking any slower) so the type system aspects of CLOS would be trivial. >Or standardize better the difference between structs and classes Aren't structs just a leftover from before CLOS was included? There's not really any reason to use them over classes. They may as well be deprecated instead. >I'd worry about optimization, though. Wouldn't be any slower than Pythons version so it would only depend on how fast the standardizing body wanted the base language to be. They wouldn't be hard to implement on an implementation supporting extensible sequence functions and that has the benefit of fast interface/design revisions until its reasonably performant. >Basically, generics could work on anything, not just objects; after all, how does + does internally? Something akin to typecase, right? I'm actually working on a implementing the maths functions at the moment. Part of the problem is that extensible interfaces eat up processor cycles (though strandh has done work making dynamic CL faster, in contrast to almost everyone else that's trying to make static CL faster). Of course I'm implementing it with fast-generic-functions so there is a fully extensible interface. I would also hesitate to include such requirements in a standard though.

>>31374 >You've piqued my interest so I would appreciate it. Here's a rebuttal of some Unicode missionaries: http://verisimilitudes.net/2019-11-22 Here's my design for an alternative text model: http://verisimilitudes.net/2018-06-06 Here's the small amount of work done towards realizing one version of it so far; the first describes it, the second is the first attempt, and the third is the best attempt: http://verisimilitudes.net/2020-06-18 http://verisimilitudes.net/2021-04-24 http://verisimilitudes.net/2021-09-21 >I would be hesitant to include atomic/thread related functionality still (unless its very abstract and doesn't promise concurrent execution ever happens). Ada's a good model for this. >Is this actually required for fast strings? No. >Though perhaps the character type could be fleshed out into constant size vs variable size. There's already a base-char type. >I don't understand what you mean here. He means treating a three-dimensional array as a vector of two-dimensional arrays and a two-dimensional array as a vector of vectors and so on, which would make them more convenient in some situations. >How much improvement is reasonably possible considering the standard should support at a minimum every obscure OS that is still in use somewhere. Usually, such people want Common Lisp to bend over for UNIX, because they consider UNIX to be the standard forevermore. They want it to be more like Python.

>>31382 I've only had a cursory glance at those posts so I can't comment on them yet. >Ada's a good model for this. I guess I'll put Ada on my list of PL to look at >There's already a base-char type. Ah yes. >He means treating a three-dimensional array as a vector of two-dimensional arrays and a two-dimensional array as a vector of vectors and so on, which would make them more convenient in some situations. I wonder if that could be done using some function SUBSTRUCTURE but I can't think of another datatype where this would be useful. Perhaps filtering hash tables? >Usually, such people want Common Lisp to bend over for UNIX, because they consider UNIX to be the standard forevermore. They want it to be more like Python. Even newer C standards don't have much from POSIX. I am increasingly noticing double standards for a CL standard that don't exist elsewhere and nobody cares.

>>31381 >There's nothing stopping an implementation from bundling it like they already do with ASDF and UIOP. That would be the same as having a standard, then. Basically, one implementation and no portability troubles. The problem is that unlike ASDF, threads can't be built on what CL provides. >An extension for SBCL is not the same as including it in a language standard. Of course, CL won't evolve, whatever is said here. But SBCL is the major open source CL implementation. >What does this mean except their functions understand UTF-8 characteristics like variable length characters? It means that the string is stored using UTF-8 and that any function does decode it every time it parses it. >I've been thinking about a way of implementing a nice clean type system where you can define "implementation" and "point in type tree" differently (whilst not making type checking any slower) so the type system aspects of CLOS would be trivial. I'm sorry but I don't understand much here. >Aren't structs just a leftover from before CLOS was included? There's not really any reason to use them over classes. They may as well be deprecated instead. There are many reasons, mainly speed because they can't be redefined at runtime (well, they can, but it's an UB). When I implemented RW locks earlier, my only choice was structs because atomic operations aren't possible on class slots; another reason it should be part of the standard, atomic support is so rotten it makes me weep compared to C++ or even C. >I'm actually working on a implementing the maths functions at the moment. Part of the problem is that extensible interfaces eat up processor cycles (though strandh has done work making dynamic CL faster, in contrast to almost everyone else that's trying to make static CL faster). Of course I'm implementing it with fast-generic-functions so there is a fully extensible interface. >I would also hesitate to include such requirements in a standard though. Yeah, fast-generic-functions (or static-dispatch) is something that would need to be in the standard if CLOS were to be integrated much more closely. But even without it, wouldn't you be able to use compiler-macros/macros and CLtL2 type extensions to dispatch at compile time when the type is specified (using declare, the or coerce, I suppose)? Since you seem to follow SICL more than me, do you have any idea about its advancement? The issue section looks like a ghost town, even if there are commits every day. The idea of a completely portable standard library (with the implementations only providing special operators, I guess?) is an extremely interesting project. In general, stuff like SICL, Clasp, McCLIM and the work of Marco Heisig or the S-expressionists gives me back a little faith in humanity.

>>31385 >The problem is that unlike ASDF, threads can't be built on what CL provides. Neither can ASDF though. It depends on a lot of implementation specific behaviour and the point of UIOP is to smooth over implementation specific details because the standard doesn't specify everything it uses. >But SBCL is the major open source CL implementation. It still may as well be an external library to most users, none of the superfluous SBCL modules are imported by default. >stored using UTF-8 Care to explain what that means aside from "a vector of bytes representing one or more Unicode codepoints" >There are many reasons, mainly speed because they can't be redefined at runtime >only choice was structs because atomic operations aren't possible on class slots Sounds like a job for MOP to me. >atomic support is so rotten it makes me weep compared to C++ or even C. I know SBCL has a couple atomic operations in a contrib module. Does C++ offer atomic operations on (I don't know the C++ jargon here) "non final specializers"? CL doesn't have a notion of " you can no longer extend or change upon this" (outside of f-g-f and similar of course) so in that case wouldn't "atomics" just become an instance lock? >But even without it, wouldn't you be able to use compiler-macros/macros and CLtL2 type extensions to dispatch at compile time when the type is specified (using declare, the or coerce, I suppose)? Yes you could, most implementations have their own system though because the compiler is free to ignore all compiler macros and regular macros would imply different evaluation rules. >Since you seem to follow SICL more than me, do you have any idea about its advancement? Edging closer to a native executable. AFAIU most of the hard work from LIR to executable is done. Though there's still a fair bit of the standard library left. I imagine the pace to pick up when strandh finishes the bootstrapping code. Feel free to join #sicl on libera and see how its going. >The idea of a completely portable standard library Its meant to be a completely portable implementation, take what you want leave what you don't. Even the runtime and GC will be almost entirely (as close as possible) ANSI CL

>>31387 >It still may as well be an external library to most users, none of the superfluous SBCL modules are imported by default. True, but I meant that as the CL standard is frozen in time, SBCL evolving is almost the only possible modern take on "CL evolution"; even if that means fragmentation. >Care to explain what that means aside from "a vector of bytes representing one or more Unicode codepoints" Nothing, except that you can't use CL's sequence functions on it. As I mentioned earlier, modern processors have caches big enough and branch predictors good enough so that the memory bandwidth cost gains of UTF-8 are greater than the decoding costs. >Sounds like a job for MOP to me. Care to elaborate? Don't see how I can do anything to avoid structs, since it's an implementation-defined thing. >Does C++ offer atomic operations on (I don't know the C++ jargon here) "non final specializers"? Sorry, you lost me here; but on most platforms, Atomic<T> is lockfree. >CL doesn't have a notion of " you can no longer extend or change upon this" (outside of f-g-f and similar of course) so in that case wouldn't "atomics" just become an instance lock? It's preferable to make it impossible to use atomics than to tank the program performance by reverting it silently to a lock, though.

>>31388 >Nothing, except that you can't use CL's sequence functions on it. Why not? Because you can't just loop across a stream of UTF-8 codepoints? >Care to elaborate? Don't see how I can do anything to avoid structs, since it's an implementation-defined thing. I meant that something MOP based similar to f-g-f is a better solution to the need-for-speed with structures than having an entirely separate structure type that barely supports half the features. You said a newer standard would do well to clarify the difference and I'm proposing standardizing the MOP to be a better solution. >Sorry, you lost me here; but on most platforms, Atomic<T> is lockfree. >It's preferable to make it impossible to use atomics than to tank the program performance by reverting it silently to a lock, though. Depends what the documentation says. A correct program is better than a fast one. Also I don't know how these are implemented in lisps but it most likely could just be a spinlock which most definitely wouldn't absolutely tank performance.

>>31389 >Why not? Because you can't just loop across a stream of UTF-8 codepoints? Well, you can, but you'll be iterating on the raw bytes, and not the decoded codepoints, which is not what you want to do on strings (usually, you may still want to scan for stuff like ASCII chars, which works transparently with UTF-8). >I meant that something MOP based similar to f-g-f is a better solution to the need-for-speed with structures than having an entirely separate structure type that barely supports half the features. I think I understand, but my CLOS-fu (and thus MOP even more) is quite low. > A correct program is better than a fast one. Yeah, forgot that due to CL's dynamism, "not compiling in this case" isn't a valid solution; a compiler warning like SBCL usually does could be useful here. >Also I don't know how these are implemented in lisps but it most likely could just be a spinlock which most definitely wouldn't absolutely tank performance. Look at Linus' take on spinlocks: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723 tl;dr never use them in userspace

>>31390 >Well, you can, but you'll be iterating on the raw bytes, and not the decoded codepoints, which is not what you want to do on strings (usually, you may still want to scan for stuff like ASCII chars, which works transparently with UTF-8). Who says they can't be decoded. Possibly by subclassing STRING with STRING-BASE and STRING-UNICODE or similar to keep both options available. >tl;dr never use them in userspace What's wrong with >I know this usually takes 8 cycles on this m-arch >spin for 8 cycles >if still locked then call kernel 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. Context switching takes a long time so its best to avoid it if you want performance. This is part if the reason for developing io_uring IIRC.

>>31400 >Who says they can't be decoded. Possibly by subclassing STRING with STRING-BASE and STRING-UNICODE or similar to keep both options available. 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. >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). Another reason to not use spinlocks on Linux is that mutex are already very optimized; spinlocks are almost always a premature optimization thing.

It's foolish to count cycles in Common Lisp programming. >>31384 >I've only had a cursory glance at those posts so I can't comment on them yet. I'm patient. >I guess I'll put Ada on my list of PL to look at It's certainly worth it. >I wonder if that could be done using some function SUBSTRUCTURE but I can't think of another datatype where this would be useful. Sure. There's already ARRAY-ROW-MAJOR-INDEX. >I am increasingly noticing double standards for a CL standard that don't exist elsewhere and nobody cares. Those other languages only have one worthwhile implementation, notice. Fortunately, no one will ever be able to meaningfully change the standard. >>31388 >As I mentioned earlier, modern processors have caches big enough and branch predictors good enough so that the memory bandwidth cost gains of UTF-8 are greater than the decoding costs. This reminds me of someone mentioning that HTTP compression can slow things down on a GBPS connection, so reconsider compression since everyone uses fast connections, right? Common Lisp may as well be timeless, compared to other languages, so such performance benchmarks are beyond irrelevant.