Once you write enough lisp, eliminating parens becomes more trouble than
it's worth.
Also the guy who did this has the same name as my dad? I'm ashamed.
On Monday, 25 March 2013 06:52:23 UTC-4, poetix wrote:
I really like the look of this:
http://readable.sourceforge.net/
which defines a
I don't like the idea of infix math as a reader macro. Yeah prefix is weird
to read for complex expressions, but in such rare cases there are ordinary
macros that let you do infix math. Use them.
An interesting thought I had the other day regarding infix math:
It would be possible for Clojure
Right now, Clojure is fighting its way to get to Java-like performance
for numerics, and that involves emitting primitive numbers and
operations whenever possible. I'm afraid that would be utterly
incompatible with turning numbers into functions - that would be at
least two levels of indirection
I really like the look of this:
http://readable.sourceforge.net/
which defines a completely reversible transformation between e.g.
define fibfast(n)
if {n 2}
n
fibup(n 2 1 0)
and
(define (fibfast n)
(if ( n 2)
n
(fibup n 2 1 0)))
and wonder how difficult it would be to
Oh, it's this thread again. Please read
https://groups.google.com/d/topic/clojure/TB4i3ATmrEE/discussion before
discussing further.
TLDR: If you want to demonstrate the merits of significant white space for
clojure, please implement a reader with the alternative rules you envision.
Right now, the
One difficulty in that transformation for clojure might be that {
already has significance to the clojure reader, denoting the beginning
of a map literal.
If { in that notation is exclusively used for infix binary operations,
you could get around it, because in that context the {...} expression
As stated in the web site, there are sometimes different needs while
creating/editing, and while reading.
I see no need to create a second edition syntax.
It may be interesting (and potentially way easier to prototype / play
with the idea) to only provide alternative views of clojure code.
My
Some idea for alternative clojure syntax:
(first | first coll) ; (first (first coll))
(count | first | second coll) ; (count (first (second coll)))
(nth % 2 | first coll) ; (nth (first coll) 2)
(+ 1)# ; (partial + 1)
(+ 1 (* 2))## ; (fn [nb] (+ 1 (* 2 %))
(count | first | second)## ; (fn [coll]
(first | first coll) ; (first (first coll))
(count | first | second coll) ; (count (first (second coll)))
(nth % 2 | first coll) ; (nth (first coll) 2)
How is this better than the threading macro?
(- coll first first)
(- coll second first count)
(- coll first (nth 2))
Timothy Baldridge
On
As an interesting point of trivia, the idea of abandoning S-expressions for
some other notation actually pre-dates the first implementation of Lisp.
S-expressions were originally intended as a temporary measure, before a
more familiar representation - deemed M-expressions - could be formalized.
N
Jason Lewis
Email jasonlewi...@gmail.com
Twitter@canweriotnow http://twitter.com/canweriotnow
Blog http://decomplecting.org
About http://about.me/jason.lewis
On Mon, Mar 25, 2013 at 6:44 PM, Kris Jenkins krisajenk...@gmail.comwrote:
I never have understood the obsession with moving the parens in Lisp to the
same place they are in C-like languages. I'm not typing any less, and it
certainly undermines the code = data (i.e. lisp lists / function calls)
homoiconic representation. Is it clearer? Maybe to someone unaccustomed to
12 matches
Mail list logo
