Just for mentioning the original source: It has been made quite clear at
RacketCon and the video recording of it, that #lang racket is here to stay
with its current syntax.
My guess is still, that people are a bit worried about any syntax becoming
second class citizen in Racket.
(btw.: I like the square brackets idea someone threw in at RacketCon (could
not see who in the video) – simply genius :D)
On Tuesday, July 23, 2019 at 11:07:55 PM UTC, Michael Myers wrote:
>
> 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/6630a42e-f758-48e5-828d-8e02183caebe%40googlegroups.com.
