At Tue, 23 Jul 2019 12:55:37 -0400, Greg Hendershott wrote:
> Ignoring the implementation difficulty (which I realize is a ridiculous
> thing to ignore, but just for a thought experiment): I've seen some SDK
> or API docs with a "choose your language" UI that changes function
> signatures and code examples.
>
> - Could there be some reasonably good mechanical two-way enforestation /
> deforestation? Maybe I'm misusing those terms. I mean, convert
> documentation between the two syntaxes, on the fly.
>
> - Even better, could this work well enough not just to display usable
> documentation, but to transform actual source code? (I don't know if
> this would need to impose something like the Go printer, to "enforce"
> coding styles, for acceptable round trips. I don't even know if that
> would be unfortunate or fortunate.)
>
> If any of this is feasible, then talking about it now and during the
> long wait, would help send a more positive message:
This looks difficult to me. While choices in syntax can make this
problem easier or harder --- and a lot of existing work on alternative
Lisp syntax focuses on making it easier --- even in the ideal case, it
seems difficult to make switching syntax automatic and pervasive. I
think there would end up being a lot of overhead to maintaining
documentation and tools that can reliably toggle between notations.
There are many points into between completely incompatible and
trivially convertible syntax. If we decide on a syntax change, we will
certainly create transformation tools, and the only question is how
automatic they can be.
> It seems like there are at least two "flavors" or "strengths", of giving
> Racket a non-sexpr syntax someday:
>
> 1. The new syntax will be a choice, fully co-equal with sexprs. Both are
> "first class", "forever". Any great new Racket features work with
> either.
>
> 2. The new syntax will become the preferred syntax, used in
> documentation and advocacy. ("Change the culture" is the phrase I
> thought Matthew used initially -- but I welcome him
> clarifying/correcting/revising.) Sexprs and #lang racket will get a
> status that's not as weak as "deprecated", but not really as strong
> as co-equal with the new syntax.
I can see how option 1 might work without auto-conversion between
syntaxes. We could have different language names, parallel
documentation and tutorials, different entry points on the web, and
separate distributions. Those would share the same core implementation
and package system, so they'd interoperate, and maybe some other
parallel products could have shared sources.
Actively maintaining two complete faces of Racket in that way would
incur a significant cost, both in the short term and long term --- not
the same cost as supporting switchable syntax, but still significant.
Anyway, Option 1 read that does seem within the realm of possibility.
For now, I'm still advocating option 2.
> TL;DR: How would we promote Racket in the meantime??
Racket is a language on the move. :)
> Example worry: Something similar to an "Osborne Effect".
You're concern is valid. I appreciate the idea of looking for technical
solutions, and, obviously, I can't close the technical question;
someone might come up with a great idea. My sense so far, though, is
that the potential technical solutions would be too difficult and/or
expansive.
As others have noted, if we end up changing Racket's syntax, it
wouldn't be the first time that Racket has embarked on a difficult
transition with concern about how that transition appears. I've learned
the importance of starting a discussion within the community earlier
rather than later. I have not drawn the lesson that we need to be
guided (technically or strategically) by outside impressions along
these lines.
--
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/5d38c291.1c69fb81.9f608.bddbSMTPIN_ADDED_MISSING%40gmr-mx.google.com.
