This is getting out of hand. There is a lot of misinformation swirling
around, sparking a lot of unnecessary panic and misunderstanding.
Changing surface syntax, even for something as invasive as infix notation,
is not synonymous with abandoning s-expressions.
Let me repeat this, for emphasis: changing the surface syntax, even to
introduce infix notation, does *NOT* require abandoning s-expressions.
Let me assert a stronger point: even if, for the sake of calming people's
nerves, we were to make the following restrictions:
1. Racket2 cannot use any reader other than the standard racket reader.
2. Racket2 is not even allowed to be a #lang, the most it can do is be
an optional (require racket2) after #lang racket/base.
...we could still significantly alter racket's surface syntax, even to
introduce infix expressions.
Now, which of the following are real s-expressions?
x
(+ x y)
(x + y)
x
(+ x y)
(x + y)
'x
('x ,y '(x y z) ('x'y'z)(x,y,z))
(parse-sexpr '(f (x,y) = 2 x ^ 2 + 3 x - 4))
(#%parse f (x,y) = 2 x ^ 2 + 3 x - 4)
The answer, of course, is all of them.
In fact, the last one is a macro I use fairly often, though I tend to give
it the shorter name $.
Consider the following:
https://github.com/mromyers/infix-syntax/blob/master/infix-syntax/test/core/base-test.rkt
Now, consider the following possible programs:
(def (abs x)(if (< x 0) (- x) x))
def abs(x) = if x < 0 then - x else x
def abs(x) = @(if (< x 0) (- x) x)
(def (abs x)($ if x < 0 then - x else x))
def sign(x) =
@(cond [($ x > 0) 'positive]
[($ x = 0) 'zero]
[($ x < 0) 'negative])
If we treat $ as a macro that recursively parses its contents, and @ as a
unary operator that treats the expression to its right as a normal
s-expression, it is possible for all of the above to coexist with the
standard racket reader, with nothing more invasive than a redefined #%app
or #%module-begin.
An 's-expression' does not have an inherent order of evaluation associated
with it. An 's-expression' does not have an inherent evaluation context, or
namespace, or semantics associated with it. What mflatt is proposing isn't
"abandoning s-expressions", it's just introducing some amount of parsing
and interleaving into the process of expansion, in a flexible and
extensible way, which doesn't even require modifying the expander in the
slightest. It doesn't inherently require changing the reader. It doesn't
inherently require changing anything about the syntax of fully-expanded
programs. It's likely that the reader would be tweaked a bit in the
process, but at the end of the day, 'read' will still turn strings into
s-expressions.
If what you're worried about is that you won't be able to write programs
that look the way you want, you have nothing to fear. With this approach,
it is trivial to allow seamlessly switching between standard prefix style
lisp, and infix expressions, even in the exact same program. In Honu, the
equivalent of the @ operator above is a macro called racket_syntax. Now,
granted, it's not 100% automatic that switching and interop between these
will be painless and smooth. So the solution, if you're feeling scared, is
not to panic, but to stick around, and voice your preference for such
interoperability as a priority. Racket is a big tent, and so long as you're
friendly and willing to express your needs and constraints in a civil
manner, there's a lot of room to make something that appeals to many
different sensibilities.
Lastly, if what you're worried about is that this somehow makes racket 'no
longer a true lisp', whatever that means, have no fear. The techniques Honu
uses are a development and refinement of techniques deeply tied to the
history of Lisp, originally implemented as a similar, but less
sophisticated reader macro for Maclisp. By sheer history it's lispier than
lexical binding! If that's not enough, and you have some reservation about
'losing homoiconicity' or somerthing, I'd recommend reading the following:
http://calculist.org/blog/2012/04/17/homoiconicity-isnt-the-point/
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/25b3868f-41e2-43ff-afe8-d7c1c8a8253d%40googlegroups.com.
