Programming language notation is a barrier to entry

Re:Programming language notation is a barrier to entry by lisper on Thursday October 01, 2020 @04:51PM (#24656027)

A long time ago I settled on FST and RST as the Right Names for the two halves of a cons cell. The argument is:

1. It's vaguely mnemonic of FirST and ReST, but compactified enough that it's still parseable as abstract names with no particular semantics

2. It's composable the same way that CAR and CDR are, e.g. FFRST == CAADR.

Another good pair of names is LHS and RHS for Left Hand Side and Right Hand Side. Same argument applies.

[ Parent | on HN ]

Re:Programming language notation is a barrier to entry by Riverheart on Thursday October 01, 2020 @06:50PM (#24656990)

How do you define these so you can use them like CAADR?

[ Parent | on HN ]

Re:Programming language notation is a barrier to entry by lisper on Thursday October 01, 2020 @07:22PM (#24657231)

(defun ffrst (l) (caadr l))

Lather, rinse, repeat.

For extra credit, write a macro that will save you having to type every possible combination out manually.

[ Parent | on HN ]

Re:Programming language notation is a barrier to entry by emidln on Thursday October 01, 2020 @07:26PM (#24657259)

I did this once for Clojure and named it car-cdr-construction-set! with an argument for how many levels deep to define in the current namespace.

[ Parent | on HN ]

Re:Programming language notation is a barrier to entry by agumonkey on Thursday October 01, 2020 @08:08PM (#24657492)

Some people in university hinted that some lisps had special parsing stages for car/cdr based functionals. They may turn c(.)*r into nested (car (cdr ( ... ) ) ) calls.

[ Parent | on HN ]