[HN Gopher] Common Lisp Quick Reference (2018)
___________________________________________________________________
Common Lisp Quick Reference (2018)
Author : abudabi123
Score : 125 points
Date : 2023-03-25 10:00 UTC (13 hours ago)
(HTM) web link (clqr.boundp.org)
(TXT) w3m dump (clqr.boundp.org)
| TurboHaskal wrote:
| This is so lovely one of my main reasons to main Common Lisp is
| to have an excuse to use it. Not even kidding.
| nanna wrote:
| Is there an Emacs info mode CL manual out there?
| r9550684 wrote:
| there's dpans2texi https://github.com/rebcabin/dpans2texi,
| which lets you convert dpans https://github.com/xach/dpans the
| tex source for the Common Lisp standard to texinfo which you
| can open in emacs
| ofalkaed wrote:
| People who publish programming material online in PDF format
| should really take notice of this and the formatting. The half A4
| version is skinny enough that you can stick it next to your
| editor/IDE window and still see the entire page even on small
| screens.
| djha-skin wrote:
| Of particular interest to me is the loop facility reference. It
| appears to be terse, understandable, and relatively complete. I
| also like the notation. A subscript f to tell me it's not a macro
| is incredibly helpful.
|
| Friendly reminder about printing services like this one[1] that
| will print and ship a PDF to you.
|
| https://www.printme1.com/
| r9550684 wrote:
| hyperspec has a compact take on loop, which is my goto when I
| don't quite remember details of syntax, http://www.lispworks.co
| m/documentation/HyperSpec/Body/m_loop.... it also has a benefit
| of being ascii representable
| User23 wrote:
| Another fun option is to print the folios and bind them
| yourself. A serviceable job can be done in an afternoon with
| little more than a sewing kit. It's easy, using a ruler, an awl
| or something similar, and a stiff piece of cardboard, to make a
| guide template for punching holes in the folios. After that
| it's just a matter of stitching.
| djha-skin wrote:
| I did it myself just now it works great.
| akho wrote:
| The book in the post is a single folio. A whole afternoon is
| an overstatement, I'd say.
| nanna wrote:
| This is a great showcase not only of Common Lisp, but of (La)TeX.
| ergonaught wrote:
| It is amusing that the quick reference is a densely packed "52
| pages".
| inimino wrote:
| It's CL, what are you gonna do...
| 1bent wrote:
| I've always felt that Common Lisp was the Lisp family
| incarnation of PL/I; include everything you think might be
| helpful to offer a warm welcome to folks coming from FORTRAN or
| COBOL.
| dreamcompiler wrote:
| Common Lisp is huge because libraries were not a big thing when
| it was designed, so it included lots of kitchen sinks.
|
| This has some advantages:
|
| 1. The built in functions generally are very efficient and
| don't have many edge-case gotchas.
|
| 2. You don't have to worry about which version of a library
| function to use, i.e. no dependency hell.
|
| 3. The above is true for every CL implementation, from any
| supplier.
|
| It also has some disadvantages: When designing a language you
| can never predict all the functionality people will need.
| Useful things like networking and multithreading and package
| management were not included in the CL standard. Libraries for
| the missing pieces now exist to fix those shortcomings.
| lispm wrote:
| we need to keep in mind that many things were still emerging
| when the core language was designed - 1982 specs appeared
| with the first language book published in 1984. CLOS (the
| Common Lisp Object System) for example was mostly a research
| project, whose first spec was published in 1988, the Meta-
| object Protocol book was published in 1991 - which was
| unusual, since one would standardize on common practice.
| Stuff like networking and multithreading existed in very
| different ways or only very primitive. Networking usually
| meant to interface to the local platform network stacks and
| multithreading was still largely unsolved - parallel Lisp was
| still a research subject, even though
| thread/concurrency/parallelism support existed in very
| different ways - often 'green threads' (cooperatively
| scheduled) or for experimental machines (like the massive
| parallel connection machine). Now even my watch has two cpu
| cores and smartphones have even more cores.
| citizen_friend wrote:
| I also like the simplified Common Lisp reference:
| https://jtra.cz/stuff/lisp/sclr/index.html
| kqr wrote:
| Whenever I see things like this I wish CL was available by
| default in more environments. It would have been the ultimate
| glue language also capable of growing software into medium-to-
| large size projects with some care.
|
| Instead we have Perl. It's not bad and fulfills many of the same
| criteria, but it's also not quite as elegant.
| Kototama wrote:
| Who is still using Perl as a glue language? It's often Python
| to glue things now.
| mark_l_watson wrote:
| SBCL is available to install on MacOS with brew, with apt or
| yum on Linux, etc. You can make small standalone applications
| easily. I have used it for command line utilities (I have some
| simple examples in my CL book that you can read online
| https://leanpub.com/lovinglisp/read)
|
| The linked CL reference looks very nice, BTW.
| Nezteb wrote:
| I also recently updated the Mac install docs for Portacle for
| anyone looking for anyone looking to tinker with CL on newer
| Macs! https://portacle.github.io/
| mpweiher wrote:
| > It would have been the ultimate glue language
|
| Interesting. Why particularly a glue language? Just because
| it's the ultimate language and thus by definition also the
| ultimate glue language or is there something more specific?
| imwithstoopid wrote:
| I would argue perl has a superior practical elegance
|
| so you can write perl in a kinda-sexp style if you really want
| to (no one does, which tells you something)...but you get a
| kinda-sexp built-in syntax for hashes whereas lisps make you
| construct them with bolted on functions
| lenkite wrote:
| Will there ever be a newer edition of the Common Lisp standard to
| reflect the major changes in the computing landscape ?
| lispm wrote:
| Who knows? Currently there is no one working on a new standard.
| Maybe an AI will publish one in 2094, hundred years after the
| first standard.
|
| For now with CL we can program in the past and reuse some code
| from 30 years ago. Changes will need to reflected in
| implementations, libraries and community standards. Some stuff
| would need changing the existing, others not so much. Example:
| Due to meta-programmability something like the Common Lisp
| Object System was implemented 95% in the language itself - the
| remaining 5% largely needed to be implementation specific
| things like changing the type system. Other stuff like
| 'threading' or 'foreign function interface' would need more
| work - but they exist already in implementations and libraries.
| imwithstoopid wrote:
| I would suggest that this is what Racket is
|
| they don't call it Lisp because it came from Scheme but they
| wisely realized the first step to making changes is to stop
| calling it Scheme otherwise purists will just rain fire on it
| and insist on living in the past
|
| from a practical perspective it seems perfectly safe and
| reasonable to say Racket is Lisp2023
|
| otherwise maybe elisp? it is by far the most important thing
| with "lisp" in its name in 2023
| Nezteb wrote:
| I'd agree about Racket; the community and resources available
| for it are fantastic.
|
| Also worth noting is Hy, a sort of alternate Lisp syntax for
| Python. http://hylang.org/
| gibsonf1 wrote:
| This is fantastic. The way this is organized I have already found
| some functions I didn't realize were available. Many thanks to
| the author!
___________________________________________________________________
(page generated 2023-03-25 23:00 UTC)