Kartik Agaram:
> > Here's my solution so SICP 1.19 (computing fibonacci numbers with a
> > doubling transform)
...
> > define fib2(n)
> > fib-iter(1 0 0 1 n)
> >
> > define fib-iter(a b p q n)
> > cond
> > { n = 0 } b
> > even?(n) fib-iter(a
> > b
> > {square(p) + square(q)}
> > {{ 2 * p * q } + square(q)}
> > { n / 2 })
> > else fib-iter({{ b * q } + {a * q } + {a * p }}
> > {{ b * p } + {a * q }}
> > p
> > q
> > { n - 1 })
> >
> > I wasn't too happy with how it turned out. For comparison, here's
> > fib-iter in wart:
> >
> > def fib-iter(a b p q n)
> > (if
> > (iso n 0)
> > b
> > even?.n
> > (fib-iter a
> > b
> > (+ square.p square.q)
> > (+ square.q (* 2 p q))
> > (/ n 2))
> > :else
> > (fib-iter (+ (* b q) (* a q) (* a p))
> > (+ (* b p) (* a q))
> > p
> > q
> > (- n 1)))
> >
> > To me this seems more readable.
Well, you never *have* to use curly-infix. If you want to use prefix for some
expression, you can always do so.
> > The benefits of curly infix seem
> > entirely offset by requiring spaces around the operators. I wish it
> > was closer to C, like:
> >
> > {b*q + a*q + a*p}
As AmkG noted, there are too many symbols with characters like "-" and "+" in
them.
> > Can y'all think of a nicer way to lay out fib-iter?
A fair challenge. AmkG's approach:
> ;view in a fixed-width font
> define fib-iter(a b p q n) $ cond
> { n = 0 } $ b
> even?(n) $ fib-iter a
> b
> {square(p) + square(q)}
> {{ 2 * p * q } + square(q)}
> { n / 2 }
> else $ fib-iter {{ b * q } + {a * q } + {a * p }}
> {{ b * p } + {a * q }}
> p
> q
> { n - 1 }
My approach would be as follows (I tend to use mostly strict 2-space indents,
and cuddle the {...}):
define fib-iter(a b p q n) $ cond
! {n = 0} b
! even?(n)
! fib-iter a
! b
! {square(p) + square(q)}
! {{2 * p * q} + square(q)}
! {n / 2}
! else
! fib-iter {{b * q} + {a * q} + {a * p}}
! {{b * p} + {a * q}}
! p
! q
! {n - 1}
I actually think this looks fairly reasonable. Lots of people using other
languages would separate the infix operators with whitespace, too, and it's
really clear what's going on.
Really the bigger issue is that because we have *no* precedence, you have to
surround even + vs. *, which is one of the few areas where EVERYONE agrees on
the precedence (even if + and * aren't addition and multiplication). We
*could* add limited precedence, so that:
{{b * q} + {a * q} + {a * p}}
could become (notice that extra whitespace around +):
{b * q + a * q + a * p}
I hate to go down that path; it's hard to know where to stop.
--- David A. Wheeler
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
