This feels a bit dismissive of people's concerns. Yes, the toy examples
you give are non-controversial in their changes. That's not the case once
you start scaling up to even slightly more realistic code. For example:
(and a (or b c d) e (if x g f))
a and b or c or d and e and if x g f
Those two statements might be equivalent, not equivalent, or the second one
might be a syntax error. It all depends on the associativity and
precedence of the various operators. With the Lispy version I know exactly
what I'm going to get; I don't have to remember precedence or
associativity. With the Pythonic version...??? (Also, the Pythonic
version is much more verbose and a pain in the butt to read.)
Regardless: If there is a program that is permanently guaranteed to be
able to losslessly convert between the two formats, I don't think anyone
will give a darn what changes the core devs make to the syntax. Some teams
(where a 'team' may be a single developer) will standardize on one syntax,
others will standardize on the other. If you're trying to work on some
code that's written in the other syntax then you'll translate it to your
preferred version, do your job, translate back, commit and push. Basically
everyone will be free to use "The One True Syntax" (whichever that might
be) and treat the other one as object code that they don't have to deal
with.
If, on the other hand, the dev team is going to specify that TOTS will be
the Pythonic version and the Lispy version will be relegated to historical
status, with no promise that there won't be breaking changes in the
future...well, then I think Greg is right in his other-thread email that a
lot of people will bail and go seek other versions of Lisp that are going
to remain more stable.
On Tue, Jul 23, 2019 at 7:07 PM Michael Myers <
mrmyers.random.suf...@gmail.com> 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/25b3868f-41e2-43ff-afe8-d7c1c8a8253d%40googlegroups.com
> <https://groups.google.com/d/msgid/racket-users/25b3868f-41e2-43ff-afe8-d7c1c8a8253d%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAE8gKoenAjBRpJ8TqVV6wYoQCUMgPH%2BERKXsxPZwtm_L6UGR4Q%40mail.gmail.com.
