Sure. This is translated straight out of SICP 3.5.1[0]: (define (sum-primes a b) (accumulate + 0 (filter prime? (enumerat

Sure. This is translated straight out of SICP 3.5.1[0]: (define (sum-primes a b) (accumulate + 0 (filter prime? (enumerate-interval a b)))) If you have an S-exp parser built into your optical nerve (to paraphrase L. Torvalds), it will be indeed hard to parse. The translation rules for an S-exp are roughly: 1. switch to square brackets 2. surround all symbols except the first in brackets 3. move the first symbol outside the opening bracket 4. replace dashes in symbols with spaces 5. leading and trailing whitespace doesn't count into a symbol. That's basically it. Besides that indentation and closing brackets are written C-style rather than Lisp-style. Now the real confusion might begin if you have an S-exp with an S-exp as the first element like: ((fnr) 1 2) This would translate to: fnr[][[1][2]] which is... interesting. Anyway, this is just a theoretical example to demonstrate the whitespace-agnosticism. I have not implemented this particular language. But it's one way to arrange these trees into a Lisp-like language, if one was so inclined. The cool thing is the simplicity and identifiers with spaces. Not cool, besides unfamiliarity, is the verbosity compared to regular S-exps (more brackets). [0] https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book-Z-H-24.html#%_sec_3.5.1 https://mitp-content-server.mit.edu/books/content/sectbyfn/b...