HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
rongarret
ergolib
Common Lisp2015–2023
rongarret / ergolib

ergolib

A library designed to make programming in Common Lisp easier

Languages & CompilersLibraries & SDKs
Explore on GitHubRead Hacker News discussions
2Distinct people
22Mentions
0Explicit recommenders
150GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A library designed to make programming in Common Lisp easier

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year22 dated mentions

Observed mentions: 2015-02-19 22:12:21 UTC to 2023-08-06 17:28:39 UTC.

0123452015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC505
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC404
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC505
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC202
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202

What Hacker News says

22 sources
lisper·Aug 6, 2023
I have a macro in my personal library called BINDING-BLOCK that eliminates many (though not all) of the parens in common code idioms: https://github.com/rongarret/ergolib/blob/master/core/bindin... It's also helpful in preventing code from crawling off the right side of the screen. However, like many of the sibling comments point out, if you think getting rid of the parens entirely is desirable then you have missed the point, which is that Lisp code is not text, it's a data structure, a linked list, and the textual representation of the code is just a serialization of that data structure. And the most straightforward way to serialize a linked list is with delimiters at the start and end, like so: (1 2 3)
In Lisp in Space
eliben·Jan 28, 2023
I believe the OP's ergolib provides an example. From https://github.com/rongarret/ergolib/blob/master/core/bindin..., the examples show code like: ;;; (bb ;;; x 1 ;;; :db (y z) (foo) ;;; :mv (a b c) (bar) ;;; (do-something) ;;; :with open-file f "foo" ;;; (do-something-else)) And the code this replaces. This seems to me hard to understand without first digging into ergolib and grokking what bb means. It's just one simple example. I forget now where it was, but there's a famous Lisp quote which goes something like (paraphrased from poor memory): in Lisp you don't just solve problem X, you first grow a new programming language designed for solving X-like problems and then simply solve X with that. This has its charms, for sure. But it makes the code harder to understand for folks not familiar with your "language
Read the rest
designed for solving X-like problems"
In Lisping at JPL Revisited
lisper·Oct 12, 2022
> I don't see how it's just a "slight improvement" I'd probably have to write a whole blog post to explain why I think iterate is only a slight improvement. But the TL;DR is that IMHO if you are writing code that uses a lot of the features of iterate or loop that is an indication that you are doing something wrong. To cite but one example: both loop and iterate include constructs for collecting values. But collecting values has nothing to do with iterating or looping. It should be a separate construct. The right way to collect values is something like: (with-collector collect ... (collect value) ...) Now you can collect values whether or not you are looping, and regardless of what iteration construct you decide to use. You don't need special constructs for conditional behavior. So, for example, you could do this: (wit
Read the rest
h-collector collect (dotimes (i 100) (if (primep i) (collect i))) to get a list of primes under 100. See https://github.com/rongarret/ergolib for an implementation of WITH-COLLECTOR and lots of other constructs that are IMHO the Right Way to write code.
In Eliminating FORMAT from Lisp (2003)
lisper·Apr 21, 2019
DEFINE-CLASS and DEFINE-METHOD are very thin wrappers over DEFCLASS and DEFMETHOD. Rewriting the code using standard CL would not make it substantially longer. All those macros really do is rearrange the parens (because I can never remember where the parens go in the standard versions). DM is called DM rather than DUMP-MEMORY because it was used for debugging and typing DM over and over was a lot less annoying than typing DUMP-MEMORY. As for the use of MACROLET, there is nothing non-standard or unconventional about it. The definitions of DEFINE-CLASS and DEFINE-MACRO, along with documentation (and a whole bunch of other stuff) can be found here: https://github.com/rongarret/ergolib Specifically: https://github.com/rongarret/ergolib/blob/master/core/ergocl...
In A Cosmac1802 Emulator in 300 Lines of Common Lisp
lisper·Jul 9, 2018
> You haven't yet answered any of my questions. That's because you're asking the wrong questions. "Is there anything I mentioned that's not a realistic assessment? Is it me that's negative, or is it the actual situation?" Those are the wrong questions. The answers to those questions don't get you any closer to a solution to the problem. They only get you to the conclusion that the situation is hopeless and that you should give up. OK, you want an answer? It is both you and the situation that is negative. But the reason that the situation is negative is because of people like you who have decided that the situation is negative and that the only reasonable thing to do is to give up. And you know what? You're right. That is the only reasonable thing to do. Which means that the only way to solve the problem is to be a little unreasona
Read the rest
ble and carry on despite the fact that it makes no sense. That's why I'm doing things like this: https://github.com/rongarret/ergolib
In Why not program right?
lisper·May 2, 2017
> 1 - All those parenthesis. (Still a top objection) If you actually count parens fairly you will find that Lisp has no more than any other language, it's just that other languages use a mix of parens, square brackets and curly braces whereas Lisp only uses parens. Also, if you really don't like parens, you can get rid of a lot of them using macros. See e.g.: https://github.com/rongarret/ergolib and in particular the binding-block (BB) construct. > 2 - Lisp doesn't look like or work like what I'm used to. Neither does anything else until you get used to it. > 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. That used to be one of my objections, but it's simply not true any more. And with Quicklisp accessing the (very large) collection of available libraries is incredibly convenient. (Thanks
Read the rest
Zach!) > 4 - There aren't nearly as many Lisp programmers, so it'll be hard to find more to join your project/company if you use Lisp. That becomes a self-fulfilling prophecy. But it's no harder to create new Lisp programmers than it is to create new X programmers for any other value of X. > 5 - There aren't nearly as many Lisp jobs, so why bother learning Lisp if you're going to have a hard time finding work using it? Because knowing Lisp is a huge lever for learning other languages. Once you know Lisp everything else becomes a lot easier to learn (but a lot more frustrating too because now you will be aware of the shortcomings of other languages). > 6 - Lisp is ancient, and anything that old is useless and primitive compared to new and shiny languages. Chasing the shiny new thing is usually a mistake. Most old things suck simply because most things suck in general. But the things that don't suck continue to not suck even after they become old. In fact, standing the test of time is one of the defining characteristics of non-sucky things.
In Not Lisp again (2009)
lisper·Feb 12, 2017
Author here. I'm on the road today so latency will be high but I'm happy to answer any questions people have. Also, a shameless plug: I'm still coding in and writing about Lisp. Some currently active projects: https://github.com/rongarret/ergolib https://github.com/rongarret/BWFP https://github.com/rongarret/tweetnacl/blob/master/tweetnacl... And I just finished (but have not yet published) a Lisp implementation of the Signal double-ratchet. If anyone is interested let me know and I'll publish that too.
In Lisping at JPL (2002)
lisper·Dec 16, 2016
That's why I'm using a library (https://github.com/rongarret/ergolib) to smooth over some of Common Lisp's rough edges. The goal of the book, what I hope will make it unique, is to teach all of the basics without having to get too hung up on the details of CL. The reason chapter 3 is taking so long is that I can't figure out a good way to get around one of those details. I want chapter 3 to be about parsing i.e. I want the reader to build READ before they build EVAL. So I want to introduce READ-FROM-STRING, and one of the things I want to be able to read from strings is characters. Unfortunately, CL uses the same character (backslash) as the reader dispatch macro character for characters (e.g. #\x) as it does for the escape character in strings. So if you type #\x you get the character x, but if you type "#\x" you get a reader error
Read the rest
because the backslash is consumed as an escape character inside the string. I have yet to find a satisfactory solution.
In The Idea of Lisp
lisper·Oct 26, 2016
> future Lisps are expected and encouraged That's right. There are two reasons that Common Lisp never got revised: 1. AI winter hit and the money dried up 2. Common Lisp as it stood when it was first released turned to be a very (very!) good design, in particular because it's almost infinitely flexible. You can implement almost anything within CL because you have control over every part of the code-processing process. You can modify the lexer by making new readtables, and you can change the way the AST is processed by writing macros. There is almost nothing you can't do in CL. (There are a very few things you really can't do without changing the standard, but even those are generally possible using vendor-specific extensions, or by making small tweaks to an implementation.) FWIW, here's my take on bringing CL into the 21st century:
Read the rest
https://github.com/rongarret/ergolib and the beginning of an associated book: https://github.com/rongarret/BWFP > is there something inherent in Lisp that favors fewer namespaces Not really. It's pretty easy to make a Lisp2 act like a Lisp1 when you want it to (https://news.ycombinator.com/item?id=12801372). Much harder to go the other way.
In Technical Issues of Separation in Lisp Function Cells and Value Cells (1988)

Showing the 15 most recent of 22 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.