On 22/07/2019 22:42, Breck Yunits wrote:
> Aloha folks,
>
> I had to miss RacketCon this year as we have a new 6 month old at home
> and couldn't make the trek out.
>
> But I would love to lend my efforts to support the initiative to
> explore a Racket universe without parens. If folks out there are
> working on this, shoot me an email ([email protected] or
> [email protected]) and let me know how I can best help.
>
> I've been working on such a research effort since 2012. I call the
> notation Tree Notation http://treenotation.org/. Basically what I
> propose is splitting things up into 2 concepts: the base Tree Notation
> (which is 80% similar to I-Expressions), and then languages on top of
> that (which is where the #lang could come in).
>
> This syntax is less fragile
> (https://twitter.com/breckyunits/status/1153016840769007616) and makes
> 3 things much easier: program synthesis, data science, and visual
> programming.
>
> I think dropping parens would make a big difference and would be a
> great move for "Racket2"!
>
Thanks for the reference to your tree notation work.
Discussion is proceeding at a breath-taking pace. You might want to
enable notifications ('Watch') for
https://github.com/racket/racket2-rfcs, or you might not depending if
you want your like consumed by the #racket2 hash tag. ;)
> -Breck
>
>
>
> On Saturday, July 20, 2019 at 8:49:13 AM UTC-10, Matthew Flatt wrote:
>
> This message is intended as a prose form of what I said at RacketCon,
> but it includes some extra explanation triggered by the discussion so
> far. Where that happens, I apologize that it isn't in the form of a
> more direct response in the original thread.
>
> The Racket2 Idea
> ----------------
>
> Racket's design and implementation is on solid ground, and from this
> point, it can continue to evolve and improve in many ways. No matter
> how Racket evolves, the community is committed to preserving what we
> have achieved: today's `#lang racket` programs will run in the
> future,
> and today's `#lang racket` modules can be used in future Racket
> programs. At the same time, the current language design may be
> close to
> a local maximum, and it's not in the nature of the Racket
> community to
> be satisfied with a local maximum.
>
> By starting all programs with `#lang`, we have created a path to leap
> from one peak of design to a different, higher peak without
> sacrificing
> the old one and while staying Rackety. Roughly, that's what we
> mean by
> "Racket2". The name "Racket2" stands for some language that builds on
> the current Racket technology and implementation, but that may not
> directly accommodate the same bindings and expression forms that
> appear
> in the body of a `#lang racket` module.
>
> Although we could literally write `#lang racket2` for modules in the
> new language, "Racket2" is normally understood as a placeholder for a
> more distinct name. As a matter of branding, perhaps the language
> would
> be called "Racket X" for some good X --- shortened to "X" in some
> contexts --- and Racket X program would be written with `#lang X`
> line
> at the top. Maybe the name depends on how different Racket2 turns out
> to be from Racket, so it makes sense to pick a name later.
>
> Venturing out from Racket's current peak opens a large space of
> possibilities, so the first step is to agree on a set of goals to be
> met by the next peak. The goals can serve as a starting point for
> developing roadmap for deciding on technical details in a follow-up
> process.
>
> Possible Language Changes
> -------------------------
>
> The Racket community has long discussed possibilities for Racket2.
> Here
> are a few potential changes from the wish list:
>
> * Rename functions to make the conventions more uniform, and make
> better use of keyword arguments to reduce names and increase
> consistency.
>
> * Change structures types to have more or fewer features.
>
> * Use generic datatypes (such as streams) pervasively, instead of
> writing code that expects a particular concrete representation
> (such
> as lists).
>
> * Make strings immutable by default (e.g., result of `format` or
> `string-append`).
>
> * Adjust the semantics of common syntax forms, such as raising an
> error
> on fall-through for `cond` or `match`, and change the meaning of
> some
> primitives, such as making `integer?` mean "exact integer".
>
> * Make pattern matching more pervasive and available by default.
>
> * Change module, evaluation, and loading callbacks (e.g., protocol
> for
> `current-module-name-resolver`) to improve errors and
> extensibility.
>
> More changes have been suggested, and no doubt many other changes
> would
> make sense. As a first cut, to synthesize some principles from these
> ideas --- as a way of selecting which wishes should be tackled and
> how
> --- the current wish list might be organized and summarized by two
> overall goals:
>
> * Make the language more consistent
>
> Consistency means making terminology and binding names more
> consistent, and it means unifying related syntactic constructs. For
> example, the `define` and `define-syntax` forms should perhaps be
> less syntactically distinct. Similarly, pattern matching and syntax
> matching seem closely related and could benefit from using the same
> pattern language. Also, pattern matching should be pervasively
> available among binding forms. Etc.
>
> * Make the language constructs more generic
>
> In many ways, the current Racket language and libraries encourage
> the use of concrete data structures instead of abstract datatypes.
> The `map` function works on lists, for example, not arbitrary
> streams, and even `for` demands concrete declarations like
> `in-list`
> to provide the best performance. Refining the capabilities of
> structures and providing a smoother path among dictionaries,
> structures, and objects may also fit into this category.
>
> There seems to be a widespread agreement/assumption among the
> community
> that we could one day switch all the general documentation, such
> as the
> Racket Guide, to use `#lang X`. That would preserve the ability to
> run
> `#lang racket` modules and import them into `#lang X` modules, but it
> would effectively relegate `#lang racket` to a kind of compatibility
> mode. The Racket community has already done this a couple of times,
> moving from `(module m mzscheme ...)` to `#lang scheme` to `#lang
> racket`, and some of the Racket distribution is still implemented in
> `#lang scheme`. After another switch, the constructs for `racket`
> would
> remain documented and maintained, in the same way as the
> constructs for
> `mzscheme` and `scheme` remain documented and maintained, but
> `racket`
> and its documentation would fade to the background.
>
> Based on the wish list, the scale of changes would likely be much
> larger than in previous transitions. There will many more changes to
> names and changes to the meaning of identifiers that are spell the
> same way. The scale of those changes doesn't seem to worry the Racket
> community.
>
> Surface Syntax
> --------------
>
> You won't find a wish for significant changes the Racket surface
> syntax anywhere on the Racket2 wish list. Nevertheless, I've
> suggested
> tacking it on.
>
> Why now?
>
> If we decide that a change to the surface syntax is a good move, it
> would make sense to try that at the same time as overhauling names
> and
> syntactic forms. Pattern matching, for example, seems like a place
> where syntactic flexibility can help. Besides letting different kinds
> of changes reinforce each other, we'd revise all of the documentation
> just once instead of twice.
>
> There are downsides to tackling both semantic and syntactic
> changes at
> once. If a change to surface syntax is on the table, though, then we
> should at least consider bundling the efforts.
>
> Why at all?
>
> Partly, I believe that a syntax with infix operators, fewer
> parentheses, etc., would be better. That's a matter of opinion,
> but at
> least it's an opinion backed by enough experience with parentheses
> that it can't be written off as uninformed. More significantly,
> parentheses are certainly an obstacle for some potential users of
> Racket. Given the fact of that obstacle, it's my opinion that we
> should try to remove or reduce the obstacle.
>
> Syntax is not just an obstacle for potential users of Racket as a
> programming language, but also for potential users of Racket as a
> programming-language programming language. The idea of
> language-oriented programming (LOP) doesn't apply only to languages
> with parentheses, and we need to demonstrate that. Although we
> already
> have tools for parsing non-parenthesis syntax into parentheses and
> letting macros take over from there, that's not the kind of smooth
> path from simple extension to full language building that we have in
> the S-expression world. While these research problems may not be
> forefront on the minds of all Racket users, keep in mind that Racket
> exists because of research and remains supported almost entirely by
> research.
>
> Adjusting the syntax of Racket to accommodate more users could be
> characterized as an effort to make Racket more popular. I don't think
> it's helpful to characterize the idea that way. Granted, any
> effort to
> reduce barriers is effectively an effort to make Racket more popular.
> In that sense, our efforts on Racket's documentation were an attempt
> to make Racket more popular. The work we put into building the Racket
> distribution and making it easy to install is an attempt to make
> Racket more popular. Creating the package system was an attempt to
> make Racket more popular. All strictly true, I suppose, but the
> characterization feels wrong. There's a difference between reducing
> technical barriers for users of various stripes versus marketing to
> make a product more popular. When I point out that parentheses can be
> a deal-breaker to people outside the Racket community, I do not have
> in mind that we just need a better marketing message; I have in mind
> that the obstacle is real, it affects many people, and we should
> address it.
>
> Who?
>
> From a community perspective, the rub is that the "many people" for
> Racket syntax is a barrier are mostly people outside the community.
> It's fair to ask who would benefit. It's difficult to ask a community
> to tackle a problem whose solution targets a different community.
>
> There's also a question of who really needs to participate in the
> development of a new surface syntax. That part of the project could
> take place in its own `#lang` and stay out of the way of `#lang
> racket` users for years. As a practical matter, that will certainly
> happen, even if we think that that new syntax will eventually take
> over. We've already done some side experiments in separate `#lang`s,
> though, and now is a time to check whether there is community buy-in
> and participation for a more ambitious effort.
>
> How?
>
> Parentheses are definitely useful for Racket-style language-oriented
> programming, and parentheses certainly helped Racket's macro system
> get to where it is now. There would be no point to a change in syntax
> if it meant interfering with Racket's main capability. Although a
> macro system without parentheses is a difficult problem, I think we
> know how to solve it.
>
> I have in mind "Honu: Syntactic Extension for Algebraic Notation
> through Enforestation", GPCE 2012. It shows how we can bridge the
> relatively linear structure of non-() programs to the tree structure
> of S-expressions. Specifically, the bridge is called "enforestation".
> It sits roughly between the reader and the expander, but
> enforestation
> needs to be interleaved with expansion to get the level of
> expressiveness that Racketeers would expect.
>
> You may worry that I'm putting a lot of faith in one expriment and
> paper --- and a paper written by a PhD student and me, at that. You
> may be right. I have only my intuition that enforestation is the key
> to the problem of non-() syntax and extensibility. The details in the
> paper don't seem to me exactly right for Racket2, but it's a big
> first
> step toward addressing the problem, and it already seems sufficient.
> Others may have figured out even more. I wouldn't blame anyone for
> concluding that the difficulty of the task is too large for the size
> of the obstacle that it removes, but that's not how I size things up.
>
> The gap between 2012 and now reflects that Racket had more problems
> (in my view) than just syntax, and for various reasons, those other
> problems took precedence for my own work. This also explains my
> answer
> to the "why now" question. The other problems seem to be resolved or
> well on the way, and so syntax seems like the next thing to tackle.
>
> How to Proceed
> --------------
>
> Ideally, we would first decide on whether we want to try changing
> surface syntax ever. Then, only if we have enough consensus that it's
> worth a try, we could move on to setting overall goals and picking a
> roadmap. Finally, if the planing of the roadmap succeeds, we could
> follow it while getting into the details.
>
> Unfortunately, it doesn't work like that. We need concrete
> examples to
> discuss the possibility of changing syntax, potential roadmaps to see
> whether there's anywhere we want to go, and so on. Some of the
> discussion will necessarily put a cart before a horse. Delving into
> some details may incorrectly give the impression that prerequisites
> are a foregone conclusion. We've seen all of that already, starting
> with my attempt to open up the discussion in the middle of RacketCon
> and probably continuing with this message. Perhaps we can just accept
> that this is all okay in the spirit of working together.
>
> I originally thought that we should have a more specific process in
> place for discussion at this point, but I think I've been proved
> wrong. Let's just discuss, for now. I'll be posting more myself.
>
> --
> 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 [email protected]
> <mailto:[email protected]>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/e6e1a457-c033-4408-a940-33203a48fcc6%40googlegroups.com
> <https://groups.google.com/d/msgid/racket-users/e6e1a457-c033-4408-a940-33203a48fcc6%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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/bf83337a-8a12-fec9-f81c-3a53321fc362%40linki.tools.
