On Nov 13, 2007 12:04 PM, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> 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.
Hmm. Possible confusion between ()-as-s-expr versus
f()-as-swt-expr-function-call IMO.
Hehe, maybe something like:
#|Legacy code from days when we were still using s-expr|#
s-expr(
(foo
(bar foo)
(quux
'quuux)))
Of course it does have the problem when a whole set of s-exprs need to
be embedded into a list structure that is represented mostly in
swt-expr. Hmm.
Dunno why I keep giving solutions which are just "tell the reader
explicitly what type of expr I'm thinking of".
>
> 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
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Readable-discuss mailing list
> Readable-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/readable-discuss
>
