Sweet-expressions "version 0.1" has been out for a while, so now's a good time
to take "lessons learned" and see how it can be improved.
Alan Manuel Gloria's comments have made me reconsider the role of (...) in
"sweet-expressions". Current sweet-expressions use (...) much like other
non-s-expr languages, but as a result they introduce quiet incompatibilities
when reading s-expressions (if it looks like infix it's "read wrong").
Instead, using [] and {} have their advantages.
I've looked around, and noticed that [...] is widely used (Python, Haskell,
math, etc.) to mean a "raw list". In contrast, {...} is used many languages
(including C/C++/Java/C#) to mean a "new block", which CAN have infix
expressions.
New idea: Perhaps unprefixed {...} should disable indenting (but retain infix
processing), [....] disables infix immediately inside it as well. This means
that (...) can mean "process everything EXACTLY as an s-expression"... meaning
that a sweet-expression reader can replace the "traditional" reader, and the
(...) can "escape" down to the "old" reader. Way better compatibility with old
readers this way. Prefixed () would continue to mean function call, with infix
(potentially) inside.
When using it, most of the time you'd use prefixed function(...) to call
functions, {...} for infix processing, and [...] to give a "straight list" when
you want to make SURE it's not interpreted as infix. One nifty result: When
you print out something as an s-expression, it's EASILY distinguished from a
sweet-expression.
With that in mind, here are some examples:
define factorial(n)
if {n <= 1}
1
n * factorial(n - 1)
substring("Hello" {1 + 1} string-length("Hello"))
define move-n-turn(angle)
tortoise-move(100)
tortoise-turn(angle)
if {0 <= 5 <= 10}
display("True\n")
display("Uh oh\n")
define int-products(x y)
if {x = y}
x
x * int-products({x + 1} y)
int-products(3 5)
3 + 4
{2 + 3 + {4 * 5} + 7.1}
*(2 3 4 5)
Obviously, there are pros and cons here. Love to hear people's thoughts about
it.
--- David A. Wheeler
