infix.el

Infix operators for Emacs Lisp

Developer Tools Languages & Compilers

Explore on GitHub Read Hacker News discussions

2Distinct people

3Mentions

0Explicit recommenders

30GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Infix operators for Emacs Lisp

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 year3 dated mentions

Observed mentions: 2019-01-08 22:19:59 UTC to 2026-10-09 18:40:51 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

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.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	0	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	0	0	0
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	1	1	0
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	0	0	0
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	0	0	0
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	1	0	1

What Hacker News says

3 sources

rspeele·Oct 9, 2026

I'd love to take a principled stance on this because I do consider code an art or at least a craft and I appreciate a program written in a unique and clever way. In retrospect, SO MANY of my personal projects[0][1][2][3] over the years were DSLs that affected how you write something and how pretty or type-safe the code ends up being. They are libraries that can only be appreciated by another programmer, they mean nothing to an end user. It appears that whole genre of library will mean nothing to anybody in a few years. Shoulder of Orion, Tannhauser Gate, etc. etc. [0] https://github.com/rspeele/infix.el [1] https://github.com/rspeele/LicenseToCIL [2] https://github.com/fsprojects/Rezoom.SQL [3] https://rspeele.github.io/FParsec-Pipes/Intro.html Yet, it's utterly hopeless to try to take the same stance visual artists are nobly holding. Of

Read the rest

the programs I use daily, how many have I ever even glanced at the source code? I could count them on my fingers. And I'm in the target audience: a programmer, enthusiastic about the trade, one who has contributed to open source... Conclusion: within a rounding error of NOBODY cares about the code. Of the weavers who were displaced by the automated looms, or the furniture-makers displaced by mass produced pressboard, some of the most skilled could still ply their trade for the rich who wanted to flex their bespoke handmade goods. Programmers writing code by hand will not even have that luxury market. It makes me depressed but I don't see any way around it. My hope is that I can use my knowledge, willingness to spend long hours fighting with a computer, and industry experience to at least make better software with agents than the average vibecoder. I sadly don't think I'll get anywhere trying to play John Henry vs. the Steam Drill, trying to beat it with my hand-typed code. Maybe somebody who's 10x the dev I am can do that, and Godspeed to them, but I thought I was pretty decent and I don't have a chance. Hell, it's not even possible to prove any code was written by hand, other than by having uploaded it pre-2024ish. For this reason I really feel bad for those coming up right now, who have the same enthusiasm and fascination for Real Programming that I did, but no way to prove themselves and no motivation to in a world that values that skill less all the time.

In Programming Isn't Special

Paul-Craft·Jun 5, 2023Submission

Infix.el: Infix Operators for Emacs Lisp

2 points · Open discussion

rspeele·Jan 8, 2019

That's just fine for things that are function calls in any language. I have no preference between log(x, 10) or (log x 10). But I do want to read some functions like conjunctions, and in Lisp, I am forced to call `and`, `or`, `<`, `/`, and pals the same way as log, print, etc. I just don't think I'll ever find: (and (not (is-blocked door)) (< (height player) (height door)) (or (is-unlocked door) (has-key player door))) as readable as: not is_blocked(door) and height(player) < height(door) and (is_unlocked(door) or has_key(player, door)) Edit: to expand, I don't think it's a fundamental flaw of Lisp. There could easily be some syntax sugar that lets you specify precedence rules for functions and write them infix, just like Haskell lets you write either `(+) 1 2` or `1 + 2`. It would de-sugar

Read the rest

to the same sexpr. I know this can be done as a macro, in fact I did it for elisp several years ago ( https://github.com/rspeele/infix.el ) but it is really just a toy for personal use. If an infix operator system came out of the box and its use was encouraged for certain common operators, I think that would be a net positive, but most Lispers disagree with me there (if I had to guess).

In Blub Paradox (2014)