[HN Gopher] LispE: Lisp Interpreter with Pattern Programming and...
       ___________________________________________________________________
        
       LispE: Lisp Interpreter with Pattern Programming and Lazy
       Evaluation
        
       Author : PaulHoule
       Score  : 115 points
       Date   : 2026-02-04 18:34 UTC (5 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | shakna wrote:
       | > LispE provides an alternative to parentheses with the
       | composition operator: "."
       | 
       | That is a... Choice.
       | 
       | Breaking the pair operator in favour of something new.
        
         | sph wrote:
         | Yeah, that's pretty unclean on two aspects: breaks pairs, and
         | breaks the orthogonality of s-expressions
         | 
         | A simple macro would've sufficed, say:                 (compose
         | sum         (numbers 1 2 3))
        
           | shiandow wrote:
           | I don't think it's too bad orthogonality wise, though it is a
           | bit weird to introduce infix notation. It would almost make
           | more sense to write
           | 
           | ((. sum numbers) (1 2 3))
        
             | sph wrote:
             | Your approach is better on a mathematical sense, yes.
             | That's how Haskell does it.
        
             | jnpnj wrote:
             | schemers used a good old `compose` instead of a dedicated
             | syntax
        
             | tkrn wrote:
             | I'm not too fond of adding extra syntax or infix operators
             | to Lisps but I have been thinking lately if maybe some
             | limited form of infix macros could be useful, mainly in
             | binding forms and such. E.g anaphoric ifs were a thing in
             | the past for binding conditional expression's value;
             | currently the preferred method seems to be if-let, or when-
             | let and maybe unless-let too, and of course also the let*
             | variants. And for completeness one might also need cond-let
             | with its own different semantics. Oh, and maybe letrec and
             | a few others too. But at that point it might make sense to
             | come up with some kind of define-let-form macro facility to
             | deal with the general pattern.
             | 
             | But all that gives me a nagging feeling that maybe
             | traditional Lisp macros don't really compose that well? So
             | as a band-aid I had the idea to introduce special infix
             | macros so one could for example do "(if (expr as: var)
             | (something-something var))", or maybe "(something-something
             | var where: var expr)" and so on. I'm not sure what the
             | exact semantics should be though, especially with the as:
             | form. It's probably just a result of doing too much
             | Smalltalk lately, but out of all the "let's fix lisp's
             | syntax" ideas I don't think I have seen exactly this one
             | before, so that's something I guess. (As an alternative we
             | could also of course just replace the lambda form with
             | something less verbose so one could "(if expr [var |
             | something-something var])" and then make the conditionals
             | regular functions, or even generic ones specialized on
             | booleans. Or maybe I'll just get back to hacking my init.el
             | for now and try to cleanse my mind of these impure
             | thoughts.)
        
               | shakna wrote:
               | SRFI-105 is an infix syntax that composes well, and is
               | supported by most Schemes.
               | 
               | Its enabled by default with Guile, for example.
               | (+ 1 2 {10 * 2} 6)
               | 
               | https://srfi.schemers.org/srfi-105/
        
           | jnpnj wrote:
           | and beside multiple-args, there's the usual threading macros
           | (-> [1 2 3] f g)
        
         | mchaver wrote:
         | It's not too bad. I like it! Haskell uses "$" to do the same
         | thing.
        
           | shakna wrote:
           | Well, you could use $ in Lisp, too. Thats a standard valid
           | symbol, that doesn't have a builtin meaning.
        
           | shiandow wrote:
           | Technically $ means something slightly different, it is more
           | somilar to putting parentheses around the right half of the
           | expression. For function composition it uses the same '.' .
        
         | arethuza wrote:
         | After programming in Common Lisp for a few years (a long time
         | ago) and then later on having a brief period where I was fond
         | of Python, I did also become fascinated with the concept of
         | lisps where indentation replaces parenthesis such as Wisp:
         | 
         | https://www.draketo.de/software/wisp
         | 
         | Mind you - I usually end up concluding that Lisp syntax is
         | actually pretty good as it is...
        
           | shakna wrote:
           | I've always been tempted with wisp. Ever since I saw
           | SRFI-110. Love the concept.
           | 
           | I just never quite manage to grasp the new syntax.
        
           | vindarel wrote:
           | There's a new one, pretty good, resembling Python/Julia
           | syntax, check it out! https://moonli-lang.github.io/
           | defun multiply-thrice(x):           print(x * x * x)
           | end              multiply-thrice(23)
        
           | petre wrote:
           | It all ends up like YAML. Thanx but I'd rather take the
           | parens any day.
        
         | mghackerlady wrote:
         | I honestly would've prefered someone try and turn xml into a
         | lisp, at least that has a cool hack value
        
         | bunderbunder wrote:
         | They've got a page on that. They did away with linked lists and
         | chose to represent them as vectors. With some of the usual
         | stuff you see going on under the hood in this style of list on
         | imperative languages, like pre-allocating a little room for
         | growth.
         | 
         | I can't opine on whether that's a good choice. But I will
         | observe two things: first, singly linked lists aren't as great
         | on modern computing architectures as they were 50 years ago.
         | Locality of reference matters a lot more now. And second, both
         | Hy and Clojure abandoned the traditional focus on dotted pairs,
         | and in both cases I found it was fine. (Disclaimer, I didn't
         | spend a whole lot of time with Hy.)
        
           | shakna wrote:
           | Uh... Most Schemes don't use linked lists under the hood.
           | That doesn't impact the syntax, just the implementation.
           | 
           | Guile uses vectors, for example. [0]
           | 
           | Chicken... Is Cheney, so your list disappears entirely, half
           | the time.
           | 
           | Gambit uses vectors. [1]
           | 
           | [0] https://www.gnu.org/software/guile/manual/html_node/Cheap
           | er-...
           | 
           | [1] https://github.com/gambit/gambit/blob/master/gsc/_back.c#
           | L11...
        
         | tkrn wrote:
         | I agree that there is maybe too much potential for confusion
         | with that, but is the dot operator (or read syntax?) actually
         | used that much these days?
         | 
         | Personally I have mostly sometimes used it with Emacs Lisp, but
         | in general relying too much on plain cons cells and cadring
         | down the cars of their cddars feels like a code smell to me and
         | if I need a pair I can always just use cons? As the (only, I
         | think?) infix operator in traditional lisps it has always felt
         | extra-ordinarily useless to me (outside of Schemes use of it
         | lambda lists), but maybe I'm just missing something.
        
           | shakna wrote:
           | Pairs are used by about 3-quarters of the standard library of
           | Scheme, so I really would not consider its use to be a code
           | smell.
           | 
           | You should be using the pairs when using make-hash, for
           | example.
           | 
           | Cons also doesn't always return a pair. Its main purpose is
           | for prepending to a list. Only when "the second argument is
           | not empty and not itself produced by cons" does it produce a
           | pair.
           | 
           | Which means '(a . b) is clearer code in intent, than (cons a
           | b).
        
           | wiml wrote:
           | I think you need something like it in order to have a print
           | representation of a cons cell whose cdr is not a cons-or-nil.
           | And it's nice if your print representations are readable.
        
       | ilikestarcraft wrote:
       | Whoa I never expected to see a lisp repository from Naver
        
         | mchaver wrote:
         | I knew a company, StorySense, and their main product
         | WhatsTheNumber used Lisp (maybe Scheme?) for the main logic in
         | the back end. One of the founders previously worked at MIT
         | Media Lab. Interestingly enough their competitor, Whoscall, was
         | acquired by Naver. I wonder if they also used Lisp and if LispE
         | is related to that product at all.
         | 
         | https://www.cw.com.tw/article/5067306
         | 
         | (Article in Chinese)
        
       ___________________________________________________________________
       (page generated 2026-02-09 23:01 UTC)