SBCL: New in Version 2.1.0(sbcl.org)
sbcl.org
SBCL: New in Version 2.1.0
http://www.sbcl.org/all-news.html#2.1.0
76 comments
Does common lisp have any great libraries for working with data? I’ve been reading some books over the holiday and I’d like to start getting my hands dirty, but my background is R, and my day to day is statistical analysis and graphics.
Not really. But you might want to check out what Gábor Melis is doing, e.g.
https://github.com/melisgl/mgl
He's won several ML competitions and works at Deep Mind now, so as far as Common Lisp fans with strong street cred in up-to-date machine learning go, he's probably a good starting point.
https://github.com/melisgl/mgl
He's won several ML competitions and works at Deep Mind now, so as far as Common Lisp fans with strong street cred in up-to-date machine learning go, he's probably a good starting point.
We're using cl-containers [1] and cl-graph [2] and to make it very fast lparallel [3] and rtg-math [4] (among many others)
[1] https://github.com/gwkkwg/cl-containers [2] https://github.com/gwkkwg/cl-graph [3] https://lparallel.org/ [4] https://github.com/cbaggers/rtg-math/
[1] https://github.com/gwkkwg/cl-containers [2] https://github.com/gwkkwg/cl-graph [3] https://lparallel.org/ [4] https://github.com/cbaggers/rtg-math/
It's not something I'm familiar with but I saw a similar question [1] on r/lisp a few days ago. u/digikar mentioned the Teddy library [2] which itself refers to numcl [3] in its readme. Both are available on Quicklisp.
[1] https://www.reddit.com/r/lisp/comments/kburda/is_there_a_goo... [2] https://github.com/40ants/teddy [3] https://github.com/numcl/numcl
[1] https://www.reddit.com/r/lisp/comments/kburda/is_there_a_goo... [2] https://github.com/40ants/teddy [3] https://github.com/numcl/numcl
https://github.com/sirherrbatka/vellum is maturing and already usable as a data frame library.
Anyone here use SBCL or Common Lisp? Curious what you guys think of it.
I use Common Lisp for most of my daily programming, and SBCL is a big reason why. Once you get over the initial hassle (getting used to the Emacs+SLIME tool chain and learning to read the compiler diagnostics) it really gives you the productivity of Python with the performance of C++. And a lot of that performance is thanks to the tireless effort of the SBCL developers, who have been churning out a new release every few months for the last decades.
Kudos to all SBCL contributors!
Kudos to all SBCL contributors!
Do you mind sharing in what space you work on? Just curious about where Common Lisp finds professional usage. It's not something you see every day.
Also, do you have any tips on landing a Common Lisp job for someone who's already in the middle of their career (30s, senior dev)?
Also, do you have any tips on landing a Common Lisp job for someone who's already in the middle of their career (30s, senior dev)?
I work in academia. My research is about new concepts for parallel programming, especially via runtime optimization and JIT compilation. It was not hard to convince others to use Common Lisp for this - there aren't many languages that allow for metaprogramming at run time. And of these languages, Common Lisp is the only one with decent performance.
As for landing a job outside of academia - my advice would be to attend some of the regular Lisp meetings (See http://planet.lisp.org/, or https://european-lisp-symposium.org/). There is usually some recruiting going on at these meetings. And even if not, you might meet fellow hackers that know about job opportunities.
As for landing a job outside of academia - my advice would be to attend some of the regular Lisp meetings (See http://planet.lisp.org/, or https://european-lisp-symposium.org/). There is usually some recruiting going on at these meetings. And even if not, you might meet fellow hackers that know about job opportunities.
Not the OP, but if you feel like moving into Lisbon,
https://www.siscog.pt/en/
https://franz.com/success/customer_apps/scheduling/siscog.lh...
https://www.siscog.pt/en/
https://franz.com/success/customer_apps/scheduling/siscog.lh...
This is attractive :) No offer mention Lisp though? found https://www.siscog.pt/en/careers/software-engineer-lisbon-re...
It is been a while, so I don't have any more contacts there, yet one might apply and find out.
Oh hey, that sounds interesting and I already speak the local language :)
I do. I post about it often here, so instead of repeating myself, I will add a few links to my earlier comments and posts here:
* Recommendations on learning Common Lisp: https://news.ycombinator.com/item?id=25442155
* On Lisp communities on Reddit r/lisp and Freenode #lisp: https://news.ycombinator.com/item?id=25543565
* Observations on State of Common Lisp Survey 2020: https://news.ycombinator.com/item?id=25291780
* Lisp in Vim with Slimv/Vlime: https://news.ycombinator.com/item?id=21735148
* Emacs4CL (a tiny quick starter ~/.emacs): https://news.ycombinator.com/item?id=25440690
Like many others commenting here, I too use SBCL because of its good performance. I keep CLISP around mainly for nostalgia's sake. I began learning Common Lisp in Sep 2007 during a long layover at an airport using CLISP 2.41 on Debian 4.0 (Etch). Also, having another implementation helps me to test that my code is portable and does not rely on any SBCL-specific features.
* Recommendations on learning Common Lisp: https://news.ycombinator.com/item?id=25442155
* On Lisp communities on Reddit r/lisp and Freenode #lisp: https://news.ycombinator.com/item?id=25543565
* Observations on State of Common Lisp Survey 2020: https://news.ycombinator.com/item?id=25291780
* Lisp in Vim with Slimv/Vlime: https://news.ycombinator.com/item?id=21735148
* Emacs4CL (a tiny quick starter ~/.emacs): https://news.ycombinator.com/item?id=25440690
Like many others commenting here, I too use SBCL because of its good performance. I keep CLISP around mainly for nostalgia's sake. I began learning Common Lisp in Sep 2007 during a long layover at an airport using CLISP 2.41 on Debian 4.0 (Etch). Also, having another implementation helps me to test that my code is portable and does not rely on any SBCL-specific features.
Is there a story of a Common Lisp workflow on VSC by any chance?
Is that generally preferred to the others?
https://marketplace.visualstudio.com/items?itemName=ailisp.c...
https://marketplace.visualstudio.com/items?itemName=ailisp.c...
Swank/Slynk clients are generally preferable to LSP clients when doing Common Lisp. LSP infrastructure in Lisp (notably, the cl-lsp library) is relatively young and not widely used, whereas Slime/Swank is thoroughly battle-tested because it has been widely used years before LSP has been created.
As a side note, this also means that Lisp programmers have been enjoying the functionality nowadays provided by LSP decades before it started being cool. :D
As a side note, this also means that Lisp programmers have been enjoying the functionality nowadays provided by LSP decades before it started being cool. :D
Smalltalk, Java and .NET users have enjoyed as well. :)
I know about Smalltalk, but I didn't know about Java and .NET! Could you point me to utilities for those languages that allowed for features like autocompletions, introspection, live debugging, recompilation, REPLs - standard stuff in Slime/Swank?
autocompletions have been a feature in IDEs since Visual C++ was introduced, and copied by Java IDEs, and naturally Visual Studio for .NET languages as well.
Introspection, graphical code navigation has been a thing in Apple MPW, Borland C++ for Windows, Visual Age for C++ (latter CSet++), C++ Builder, Eclipse, Visual Cafe, Visual Studio Enterprise.
Live debugging and recompilation, edit-and-continue in Visual Studio, JVM class reload capabilities and JRebel JVM agents.
REPLs, available as standard feature in Java since Java 9, prior to that there were IDE features like Eclipse Scrappages. Visual Basic interactive mode (classical VB), and nowadays F#, C# and VB.NET interactive shells on VS, including send-to-repl capability.
Lucid Energize C++ tooling from 1993 already enjoyed some of these features:
https://www.youtube.com/watch?v=pQQTScuApWk
Introspection, graphical code navigation has been a thing in Apple MPW, Borland C++ for Windows, Visual Age for C++ (latter CSet++), C++ Builder, Eclipse, Visual Cafe, Visual Studio Enterprise.
Live debugging and recompilation, edit-and-continue in Visual Studio, JVM class reload capabilities and JRebel JVM agents.
REPLs, available as standard feature in Java since Java 9, prior to that there were IDE features like Eclipse Scrappages. Visual Basic interactive mode (classical VB), and nowadays F#, C# and VB.NET interactive shells on VS, including send-to-repl capability.
Lucid Energize C++ tooling from 1993 already enjoyed some of these features:
https://www.youtube.com/watch?v=pQQTScuApWk
You made me look how old Visual C++/Visual Studio is.
https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B says: 27 years old. Not too shabby :-)
You should add refactoring capabilities for the C++/C#/Java tools to the list of features, I wonder how the Lisp stuff compares.
https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B says: 27 years old. Not too shabby :-)
You should add refactoring capabilities for the C++/C#/Java tools to the list of features, I wonder how the Lisp stuff compares.
Yeah, due to dynamic types is might do well than C++/C#/Java refactoring tools.
However the first refactoring tools appeared on Smalltalk, which is also a dynamic language, but it doesn't have macros and the image provides metadata that Lisps don't always have available.
However the first refactoring tools appeared on Smalltalk, which is also a dynamic language, but it doesn't have macros and the image provides metadata that Lisps don't always have available.
Yes, I use it professionally, and have for over 30 years, since before it became Common Lisp. It is far and away my favorite programming language (hence my HN handle :-) for two reasons: macros allow me to capture any design pattern and seamlessly add it to the language as a programming construct, and the generic function model of OO built in to CL is vastly more powerful than the C-based single-dispatch object.method() model that is ubiquitous in the rest of the programming language world.
Can you expand on the second point? What can you do with CL OO that is hard in C/C++?
I like the Circle-Ellipse Problem [0] as an example of something CLOS / multimethods are good at that C++ isn't. In general, Expression Problem-like [1, 2] problems are much much nicer to solve in CL.
[0]: https://en.wikipedia.org/wiki/Circle%E2%80%93ellipse_problem [1]: https://en.wikipedia.org/wiki/Expression_problem [2]: https://wiki.c2.com/?ExpressionProblem
[0]: https://en.wikipedia.org/wiki/Circle%E2%80%93ellipse_problem [1]: https://en.wikipedia.org/wiki/Expression_problem [2]: https://wiki.c2.com/?ExpressionProblem
The big win is not so much in the actual underlying power, but rather in the syntactic uniformity. In traditional OO languages there is a semantic difference between f(arg1, arg2) and arg1.f(arg2) and as a programmer I have to remember which one is the right one for any particular operation I want to do. In CL the syntax for a regular function call and a generic function call is exactly the same, so as a programmer I don't have to worry about it. I just write (do-something arg1 arg2) and let the compiler figure it out. It removes a tremendous amount of cognitive burden.
But there are lots of examples where it really makes sense to be able to dispatch on multiple arguments. Arithmetic operations, for example. It's really nice to be able to add, say, arrays using the same syntax as adding numbers, or to be able to do array-array multiplication and array-scalar multiplication using the same syntax as multiplying numbers. Or, if you're doing graphics, to be able to specialize on both the object being drawn and the target to which it is being drawn.
There are loads of other things as well. The meta-object protocol allows you to do all kinds of wizzy things. Using EQL specialization lets you define special-case handling for a privileged object without cluttering up the rest of your code. BEFORE and AFTER methods let you tweak arguments on the way in or results on the way out.
Here's an example from a real-world project I'm working on: it's a 30-year-old legacy system and it's chock-full of hard-coded path names, literally thousands of them. We had to port it to a new environment where those paths don't exist. Normally this would have been a huge project to go through the source code and manually find and change all of the paths. Instead, I was able to define a BEFORE method on the OPEN function [1] which translated the incoming hard-coded path name to the correct value in the new environment. What would normally have been a multi-day headache was instead a five-minute tweak.
[1] Yes, I know OPEN is not actually a generic function, and so this is not actually possible in portable CL. But this was in ACL which provides this feature as an extension. And even in portable CL you can always shadow OPEN and redefine it. This is now getting away from the advantages of the OO system and into other parts of CL, but the bottom line is that many, many things that are a PITA in other languages are easy in CL.
But there are lots of examples where it really makes sense to be able to dispatch on multiple arguments. Arithmetic operations, for example. It's really nice to be able to add, say, arrays using the same syntax as adding numbers, or to be able to do array-array multiplication and array-scalar multiplication using the same syntax as multiplying numbers. Or, if you're doing graphics, to be able to specialize on both the object being drawn and the target to which it is being drawn.
There are loads of other things as well. The meta-object protocol allows you to do all kinds of wizzy things. Using EQL specialization lets you define special-case handling for a privileged object without cluttering up the rest of your code. BEFORE and AFTER methods let you tweak arguments on the way in or results on the way out.
Here's an example from a real-world project I'm working on: it's a 30-year-old legacy system and it's chock-full of hard-coded path names, literally thousands of them. We had to port it to a new environment where those paths don't exist. Normally this would have been a huge project to go through the source code and manually find and change all of the paths. Instead, I was able to define a BEFORE method on the OPEN function [1] which translated the incoming hard-coded path name to the correct value in the new environment. What would normally have been a multi-day headache was instead a five-minute tweak.
[1] Yes, I know OPEN is not actually a generic function, and so this is not actually possible in portable CL. But this was in ACL which provides this feature as an extension. And even in portable CL you can always shadow OPEN and redefine it. This is now getting away from the advantages of the OO system and into other parts of CL, but the bottom line is that many, many things that are a PITA in other languages are easy in CL.
I use it to write the star-mapping software behind https://greaterskies.com many years ago. I did it as a fun project after reading PG's essays, but now it is supporting my family and two employees. In the few occasions I need to touch something or add a new feature I feel like coming back home.
Thank you! Do you have an end-to-end write up for the experience? Tooling, libraries, deployment, etc?
I have never written it down, but it's very simple. I don't use any external libraries. I converted the input databases to lisp and compiled them in, and the output is simple postscript. When I want to deploy I dump a core with the compiled functionality, then run sbcl with that core. At some point I was using hunchentoot[1] to provide an http point of entry (great library, as all the ones written by Edi Weitz) but I am not bothering anymore, as most of the processing time is consumed by ghostscript and convert in the post-processing of the images.
[1] https://edicl.github.io/hunchentoot/
[1] https://edicl.github.io/hunchentoot/
Yes, I use SBCL daily. The fact that SBCL (like most CL implementations) is image-based makes CL the language for interactive and incremental programming and live debugging the program as it runs. (Shameless plug: I wrote a book about the last point and about how CL achieves it. https://www.apress.com/us/book/9781484261330)
Why does the first part of your (first) sentence imply the second part?
The two parts are separated by the word "makes".
In theory, a Common Lisp implementation is not required to be image-based. The standard permits a Common Lisp compiler that can e.g. be a batch file compiler that turns files into binaries, and then those can be executed without lots of live-programming, image-based goodies.
No CL implementation I'm aware of follows this paradigm.
No CL implementation I'm aware of follows this paradigm.
even live programming does not require images.
In most CL systems, image-based technically means it can dump memory to images on disk and start those. More exotic is nowadays, when quitting a Lisp system always writes all the changes to a new image, which then will be started next time.
ECL does not support images, but has live programming,
MOCL does not support images, nor full live programming. There are/were a bunch of CL compilers which work similar. They support then only a subset of CL - a subset without some runtime support for things like EVAL or COMPILE.
Typically non-image based and non-live Lisp compilers were written for the compilation of Lisp to C, with the purpose of generating small static executables, MOCL does that. MOCL is based on the earlier CLICC compiler.
In most CL systems, image-based technically means it can dump memory to images on disk and start those. More exotic is nowadays, when quitting a Lisp system always writes all the changes to a new image, which then will be started next time.
ECL does not support images, but has live programming,
MOCL does not support images, nor full live programming. There are/were a bunch of CL compilers which work similar. They support then only a subset of CL - a subset without some runtime support for things like EVAL or COMPILE.
Typically non-image based and non-live Lisp compilers were written for the compilation of Lisp to C, with the purpose of generating small static executables, MOCL does that. MOCL is based on the earlier CLICC compiler.
Thanks.
I do. Feel free to ask any questions, I will try to answer them if possible.
In summary: I think SBCL is the most sophisticated Lisp compiler around and it is even free :). It is not as polished as some commercial solutions, which also come with IDEs, but in the setup of SBCL+Slime+Emacs, you have a professional Lisp setup which will go a long way. (I have done professional work with this setup).
In summary: I think SBCL is the most sophisticated Lisp compiler around and it is even free :). It is not as polished as some commercial solutions, which also come with IDEs, but in the setup of SBCL+Slime+Emacs, you have a professional Lisp setup which will go a long way. (I have done professional work with this setup).
I do. Currently only in hobby fashion, but I also used it professionally when contracting for a company that was building a computation-intensive web platform on a Common Lisp (SBCL) backend. AMA.
Personally, I really like SBCL, it's my go-to implementation. I originally picked it because of performance considerations (hobby gamedev), as it compiles to native. But over time, I've learned to also appreciate the type inference and overall embracing the use of (optional by standard) type declarations to provide compile-time typechecking (as well as further performance benefits).
Personally, I really like SBCL, it's my go-to implementation. I originally picked it because of performance considerations (hobby gamedev), as it compiles to native. But over time, I've learned to also appreciate the type inference and overall embracing the use of (optional by standard) type declarations to provide compile-time typechecking (as well as further performance benefits).
I use Common Lisp for 'exploratory computing' as they say. It's my go-to language if I want to quickly evaluate an idea. Took me a while to learn, but since acquiring at least modest familiarity, I have less patience with ad-hoc syntax (syntactic sugar) found in in-fix languages and the churn found in many currently popular languages.
SBCL might be the best (in terms of correctness, adherence to the standard, performance of the compiled code, compatibility with existing libraries, tool support) open source compiler for CL. The compiler itself can be compared with commercial offerings (those seem to focus rather on additional libraries and external tools).
On ARM32 however, I do use CCL, as SBCL doesn't support multi-threading on that architecture.
SBCL might be the best (in terms of correctness, adherence to the standard, performance of the compiled code, compatibility with existing libraries, tool support) open source compiler for CL. The compiler itself can be compared with commercial offerings (those seem to focus rather on additional libraries and external tools).
On ARM32 however, I do use CCL, as SBCL doesn't support multi-threading on that architecture.
SBCL is one of those exceptional free software projects IMO. It's compiler which includes type inference and optimizations is world-class among Common Lisp implementations.
SBCL is a "sufficiently smart" compiler, that makes Lisp fast. I've replaced enough software with CL, that now I can't stand to use a computer without it. With CL you can do whatever the fuck you want, all the time. It's glorious. The limitations are your own ability, and having to interface to crappy non-CL software, idiotic non-Lisp protcols, and hardware seemingly designed to be operated by spavined brine shrimp. But also I'm "eccentric" and I like exiling myself to the software wilderness, where you have great freedom, but have to be very self reliant.
I am interested in this idea of "refactoring" software into Lisp. Do you have any resources on this?
I don't write Lisp myself, but I support SBCL-based apps running in production, and it's a very interesting beast. The REPL and the debugger/inspector are amazingly powerful.
I still find Lisp itself very hard to read, though. I understand the whole homoiconicity thing, and how S-expressions are one of the simplest implementations of that, but it's things like "car"/"cdr" instead of some reasonable memorable name (say, "first"/"rest") that kill me. Just don't seem to have the brain space for it.
I still find Lisp itself very hard to read, though. I understand the whole homoiconicity thing, and how S-expressions are one of the simplest implementations of that, but it's things like "car"/"cdr" instead of some reasonable memorable name (say, "first"/"rest") that kill me. Just don't seem to have the brain space for it.
I've done quite a bit of Scheme in the past, but I've been playing with Common Lisp a little recently, and I often find myself thinking things like "how do I convert a string to a list of characters" or "how do I check if this thing is in this list", like simple standard library stuff that I could implement myself but expect to already be there, and then I go look in the Hyperspec, and sometimes it's hard to find thing when you don't have a name to look up.
True, but there is The Common Lisp Cookbook project to help with exactly such: http://cl-cookbook.sourceforge.net/strings.html
Pleeeeeeeeeeeease link to the recent Cookbook :) https://lispcookbook.github.io/cl-cookbook/
That looks great, thanks!
The Sourceforge version is old, please see https://lispcookbook.github.io/cl-cookbook/ !
FWIW, "first" and "rest" are literally aliases for "car" and "cdr" (and there's a bunch more, see [0]), so it may be that the code you're working with isn't following a good style. The general style rule for more modern code is that you use "first"/"rest" if you're dealing with regular lists, and "car"/"cdr" if you're doing something more peculiar with cons cells - though it's not universally followed, and I guess at this point "car"/"cdr" & friends are too established in the history of Lisp.
--
[0] - http://clhs.lisp.se/Body/f_firstc.htm
--
[0] - http://clhs.lisp.se/Body/f_firstc.htm
For me learning Lisp is an essential requirement for becoming a professional programmer, even if you don't use it after that, you will "Lispify" everything you touch. It just changes the way you think.
SBCL is a compiler, it let's you use what was designed as an interpreted language, in an efficient, compiled way.
But this compiler has nothing to do with other compilers you probably know about. Instead of compiling the entire set, you just can compile fragments of code, or not compile them (interpret it for things like flexible self modifying code)if you want with total control.
Very very good for incremental programming, with tools like the REPL and debugging options you have nowhere else.
Having said that, I use my own dialect of Lisp in C, and I use that for writing code in the c world: c, c++, python, webasm, js.
I use SBCL only occasionally now.
SBCL is a compiler, it let's you use what was designed as an interpreted language, in an efficient, compiled way.
But this compiler has nothing to do with other compilers you probably know about. Instead of compiling the entire set, you just can compile fragments of code, or not compile them (interpret it for things like flexible self modifying code)if you want with total control.
Very very good for incremental programming, with tools like the REPL and debugging options you have nowhere else.
Having said that, I use my own dialect of Lisp in C, and I use that for writing code in the c world: c, c++, python, webasm, js.
I use SBCL only occasionally now.
SBCL was for years a compilation only Lisp implementation. A few years ago an interpreter for Lisp was added, but is not used by default.
SBCL has two compilation modes: a) compilation of source code files to machine code files
and b) compilation of Lisp expressions in memory.
a) can be used via the function COMPILE-FILE and b) typically via COMPILE (and thus also via EVAL)
Generally compilation of Lisp is nothing new (the first compiler was written in the early 60s) and the Common Lisp language definition (first in 1984) has many features to support Lisp compilation: compiler interface, code inlining, similar semantics for interpreted and compiled code, type annotations, ...
SBCL has two compilation modes: a) compilation of source code files to machine code files
and b) compilation of Lisp expressions in memory.
a) can be used via the function COMPILE-FILE and b) typically via COMPILE (and thus also via EVAL)
Generally compilation of Lisp is nothing new (the first compiler was written in the early 60s) and the Common Lisp language definition (first in 1984) has many features to support Lisp compilation: compiler interface, code inlining, similar semantics for interpreted and compiled code, type annotations, ...
SBCL is a great production common lisp that we use for our AGI system - incredibly fast and reliable. https://graphmetrix.com/
I do, this year I shipped a web application and paid a few rents with it. It reads an existing DB, fetches data from a SOAP service, sends daily reports to a FTP server and renders some HTML templates. I'm coming from Python and am much happier now. The compile-time checks and the deployment stories are particularly appreciated.
Just started learning Lisp (Emacs Lisp), and I am planning on doing a deep dive in Common Lisp. Using Python and Pandas for my day to day scripting. Common Lisp does not have the ecosystem in terms of packages compared to Python (or JS / NodeJS), but hacking Lisp feels extremely good. I intend to use it for prototyping, for all kinds of hacking that does not involve using available packages.
See this comment for libraries suggestions: https://news.ycombinator.com/item?id=25583855
There are quite a lot of packages for Common Lisp, though the selection certainly is smaller than for Python.
[deleted]
off topic: can anyone recommend good solution for text templating like https://handlebarsjs.com/ with full power of common lisp? i have checked the one's mentioned in cliki https://www.cliki.net/templating%20library .
Just curious. I went and skimmed through the handlebarsjs link. I'm used to cl-who and can not see what the js lib does have that is not possible or harder in cl-who.
Side note: with a small macro you can start defining your own streamlined components and special tags. akin to having your abstractions. Also l'm taking a course in HTML5+CSS and use this additionally to avoid being drawned in the usual characteristic boilerplate text.
I am actually using handlebars along with helpers https://github.com/helpers/handlebars-helpers to automatically generate sql, golang, json and jsx. cl-who is only for markup.
What i found useful in handlebars is ability to define inline function templates and use them in template. I am missing cl macro's which would automate my workflow even more so asking if something like this is available in cl.
Just curious. I went and skimmed through the handlebarsjs link. I'm used to cl-who and can not see what the js lib does have that is not possible or harder in cl-who.
They are very different styles, though. With cl-who you write code that mimics the structure of HTML and that code outputs HTML. With Handlebars etc. you write your HTML in HTML and embed code in it. Some prefer one over the other.
They are very different styles, though. With cl-who you write code that mimics the structure of HTML and that code outputs HTML. With Handlebars etc. you write your HTML in HTML and embed code in it. Some prefer one over the other.
I wrote a templating library that was used for a Slack close we developed a number of years back.
It parses the HTML with embedded code, and generates a Lisp function which is compiled on the fly thanks to Lisp giving runtime access to the compiler. Whenever the source file is changed, the code is regenerated and compiled.
Other languages do the same, but in those cases they have to generate source code and call the compiler as an external program, and then load the generated code into the running program using dynamic linking. The Lisp approach is much more efficient.
Thanks to the quality of SBCL, the templates execute with native performance, which is something very few other solutions do.
The project is unfortunately not documented, but the code is available here: https://github.com/lokedhs/lofn
It parses the HTML with embedded code, and generates a Lisp function which is compiled on the fly thanks to Lisp giving runtime access to the compiler. Whenever the source file is changed, the code is regenerated and compiled.
Other languages do the same, but in those cases they have to generate source code and call the compiler as an external program, and then load the generated code into the running program using dynamic linking. The Lisp approach is much more efficient.
Thanks to the quality of SBCL, the templates execute with native performance, which is something very few other solutions do.
The project is unfortunately not documented, but the code is available here: https://github.com/lokedhs/lofn
Yeah, I'd just be using templating in code using cl-who and whatnot. Text template languages like handlbars and are just not a popular choice in Lisp circles.
(To save others the time googling, "whatnot" is not a Lisp templating library.)
There's a third way, though: text templating libraries that support the full language. Does that exist for Common Lisp?
There's a third way, though: text templating libraries that support the full language. Does that exist for Common Lisp?
There is a cl-mustache library: I end up just using spinneret for html and postmodern’ s-expression syntax for SQL
Have you checked cl-emb?
https://common-lisp.net/project/cl-emb/
https://common-lisp.net/project/cl-emb/
Congrats and big thanks to all contributors!
[deleted]
Is there a macOS version of this ? Not using linux for development, sorry.
Many Mac lispers use CCL as well which has its own editor if you don't feel like using GNU Emacs.
Hemlock is an Emacs, though, so I'm not really sure what it would bring.
Hemlock is an Emacs, though, so I'm not really sure what it would bring.
You can `brew install sbcl`
How different is SBCL from CMU Common Lisp?