Racket2 and syntax
1078 views
Skip to first unread message
Matthew Flatt
Jul 14, 2019, 10:30:04 PM7/14/19
to Racket Users
tl;dr DON'T PANIC
At RacketCon today, after summarizing the state of work on Racket CS, I
recommended that we next explore the possibly of changing to an
infix-oriented syntax in "Racket2".
You can find the recording here:
https://www.youtube.com/watch?v=dnz6y5U0tFs
Start at 32:27 for the part about what Racket2 could be.
I'll produce a text version of the rationale soon. For now, I'd like to
offer a few clarifications:
* There is no specific proposal for a new syntax, yet. Our next step
will be creating a process to explore a possible new syntax.
* The talk does include some initial constraints that might guide the
choice of a syntax. Even that meta level (i.e., the set of
constraints) remains subject to a community process.
* `#lang racket` is not going away and will always have its current
parenthesis-oriented syntax. In the same way that Racket still
supports `#lang scheme` and `#lang mzscheme` and even `(module
<name> mzscheme ....)` and even top-level programs, the Racket
compiler and runtime system will always support `#lang racket`
programs. We believe that Racket's `#lang`-based ecosystem makes it
uniquely positioned for trying new language variants while
preserving and building on our past investments.
* Any new syntax must specifically preserve Racket-style
language-oriented programming, which means everything from defining
simple pattern-based macros to building whole new `#lang`s with a
smooth path in between. Again, our current macro technology must be
an enabler for a new surface syntax, not a casualty.
As I hope comes across in the talk, I like the current Racket syntax
--- and how could I not, after 24 years of helping to define it? ---
and I am aware of many potential technical and social pitfalls that
this kind of shift could create. Still, in addition to keeping the core
Racket implementation running, I feel obliged to recommend changes that
I think would be good for the Racket language and community. We've been
lining up some technical solutions for a while. I don't know where the
community discussion will lead, but I'm pretty sure it's time to start
the conversation.
Whether or not we eventually decide on a different syntax, the design
of Racket2 will require community input and participation. If you want
to know more about how we're thinking about that process, see the
keynote by Aaron Turon:
https://www.youtube.com/watch?v=xSjk2PdQm5k
(We'll have professionally edited videos of all talks available soon.)
Thanks,
Matthew
At RacketCon today, after summarizing the state of work on Racket CS, I
recommended that we next explore the possibly of changing to an
infix-oriented syntax in "Racket2".
You can find the recording here:
https://www.youtube.com/watch?v=dnz6y5U0tFs
Start at 32:27 for the part about what Racket2 could be.
I'll produce a text version of the rationale soon. For now, I'd like to
offer a few clarifications:
* There is no specific proposal for a new syntax, yet. Our next step
will be creating a process to explore a possible new syntax.
* The talk does include some initial constraints that might guide the
choice of a syntax. Even that meta level (i.e., the set of
constraints) remains subject to a community process.
* `#lang racket` is not going away and will always have its current
parenthesis-oriented syntax. In the same way that Racket still
supports `#lang scheme` and `#lang mzscheme` and even `(module
<name> mzscheme ....)` and even top-level programs, the Racket
compiler and runtime system will always support `#lang racket`
programs. We believe that Racket's `#lang`-based ecosystem makes it
uniquely positioned for trying new language variants while
preserving and building on our past investments.
* Any new syntax must specifically preserve Racket-style
language-oriented programming, which means everything from defining
simple pattern-based macros to building whole new `#lang`s with a
smooth path in between. Again, our current macro technology must be
an enabler for a new surface syntax, not a casualty.
As I hope comes across in the talk, I like the current Racket syntax
--- and how could I not, after 24 years of helping to define it? ---
and I am aware of many potential technical and social pitfalls that
this kind of shift could create. Still, in addition to keeping the core
Racket implementation running, I feel obliged to recommend changes that
I think would be good for the Racket language and community. We've been
lining up some technical solutions for a while. I don't know where the
community discussion will lead, but I'm pretty sure it's time to start
the conversation.
Whether or not we eventually decide on a different syntax, the design
of Racket2 will require community input and participation. If you want
to know more about how we're thinking about that process, see the
keynote by Aaron Turon:
https://www.youtube.com/watch?v=xSjk2PdQm5k
(We'll have professionally edited videos of all talks available soon.)
Thanks,
Matthew
Alexis King
Jul 14, 2019, 11:55:09 PM7/14/19
to Matthew Flatt, Racket Users
Well! While I am sure that everyone at RacketCon has already discussed this to death, and I’m sure there has been plenty of support to counterbalance the tomato-throwing, let me be the first to say something positive on the mailing list so the optics from here aren’t so gloomy: I find this idea extremely exciting. :) It’s a surprise, for sure, but I will not be doing any panicking.
I don’t have any significant commentary right now, given how vague and open-ended the direction still is, but I am excited by the idea of continuing the Honu line of research. I, too, don’t mind parentheses, but after straddling the Haskell and Racket communities for a few years, I’ll happily defend the readability advantages of a more irregular syntax. I keep coming back to Racket because nothing lets me extend the language like Racket does, but if I could get that kind of flexibility and robustness without s-expressions? It sounds hard to achieve, but if Racket can pull it off (and I am confident Racket can do it as well as anyone), I doubt I would do much looking back.
If anything, the one thing I’m disappointed about is that I could not be at RacketCon this year, as it seems like it’s been a bad one to miss, but it’s been fun to follow everything as best as I can from the sidelines. Many thanks to everyone who’s had a part in the organizing, speaking, recording, and streaming! I look forward to seeing where this goes.
Alexis
I don’t have any significant commentary right now, given how vague and open-ended the direction still is, but I am excited by the idea of continuing the Honu line of research. I, too, don’t mind parentheses, but after straddling the Haskell and Racket communities for a few years, I’ll happily defend the readability advantages of a more irregular syntax. I keep coming back to Racket because nothing lets me extend the language like Racket does, but if I could get that kind of flexibility and robustness without s-expressions? It sounds hard to achieve, but if Racket can pull it off (and I am confident Racket can do it as well as anyone), I doubt I would do much looking back.
If anything, the one thing I’m disappointed about is that I could not be at RacketCon this year, as it seems like it’s been a bad one to miss, but it’s been fun to follow everything as best as I can from the sidelines. Many thanks to everyone who’s had a part in the organizing, speaking, recording, and streaming! I look forward to seeing where this goes.
Alexis
Maciek Godek
Jul 15, 2019, 7:51:33 AM7/15/19
to Racket Users
I hope you don't mind me adding my two cents to the discussion.
I believe that people who use Lisp tend to see the advantage of its syntax for meta-programming.
As Richard Gabriel and Guy Steele wrote in "The Evolution of Lisp",
Algol-style syntax makes programs look less like the data structures used to represent them. In a culture where the ability to manipulate representations of programs is a central paradigm, a notation that distances the appearance of a program from the appearance of its representation as data is not likely to be warmly received (and this was, and is, one of the principal objections to the inclusion of loop in Common Lisp).
On the other hand, precisely because Lisp makes it easy to play with program representations, it is always easy for the novice to experiment with alternative notations. Therefore we expect future generations of Lisp programmers to continue to reinvent Algol-style syntax for Lisp, over and over and over again, and we are equally confident that they will continue, after an initial period of infatuation, to reject it. (Perhaps this process should be regarded as a rite of passage for Lisp hackers.)
Personally, I had a lot of objections when SRFI-105 and SRFI-110 were ratified. I thought that it's going to be more harmful than helpful, as it would only increase the entropy of the Lisp code base.
I still don't think that syntax is the problem. I think that we should be able to switch between different representations of "the same thing", but if we want this to be possible, we need to surpass the idea of syntax (or the idea that programs need to be text that is parsed).
Maybe the direction similar to where "I think we should be heading" is somewhere between Mathematica notebooks and Smalltalk's object environments.
I wrote a bit more about it here (I intended to present that during Racketfest in March, but unfortunately I ran out of time)
Neil Van Dyke
Jul 15, 2019, 8:07:40 AM7/15/19
to Maciek Godek, Racket Users
I look forward to the syntax discussion, within whatever process is
determined.
(BTW, I've said similar to what Gabriel&Steele do, as recently as last
week [1], but I'm open to rethinking syntax. Especially if it might
mean we can entice Shriram to resume working more directly on Racket. :)
[1] https://news.ycombinator.com/item?id=20376377
determined.
(BTW, I've said similar to what Gabriel&Steele do, as recently as last
week [1], but I'm open to rethinking syntax. Especially if it might
mean we can entice Shriram to resume working more directly on Racket. :)
[1] https://news.ycombinator.com/item?id=20376377
Alan Forrester
Jul 15, 2019, 9:09:45 AM7/15/19
to Racket Users
On Mon, 15 Jul 2019 at 03:30, Matthew Flatt <mfl...@cs.utah.edu> wrote:
>
> tl;dr DON'T PANIC
>
> At RacketCon today, after summarizing the state of work on Racket CS, I
> recommended that we next explore the possibly of changing to an
> infix-oriented syntax in "Racket2".
Infix notation introduces a lot of complexity in writing and reading
>
> tl;dr DON'T PANIC
>
> At RacketCon today, after summarizing the state of work on Racket CS, I
> recommended that we next explore the possibly of changing to an
> infix-oriented syntax in "Racket2".
code. You have try to remember what operators are infix, and all their
precedence rules, or you just wrap lots of expressions in parentheses
to avoid precedence rule problems. If you introduce infix you're not
reducing the number of parentheses, you're just ensuring that people
have to sprinkle parens around more arbitrarily than they do now in
the hope that their program will work as intended.
Alan
Christopher Lemmer Webber
Jul 15, 2019, 9:52:43 AM7/15/19
to Maciek Godek, Racket Users
Maciek Godek writes:
> Maybe the direction similar to where "I think we should be heading" is
> somewhere between Mathematica notebooks and Smalltalk's object environments.
I had similar-ish thoughts while watching the excellent Fructure talk at
> Maybe the direction similar to where "I think we should be heading" is
> somewhere between Mathematica notebooks and Smalltalk's object environments.
this year's RacketCon: maybe intro courses would be more willing to pick
up Racket and not be scared of its syntax if the default educational
language was more like Scratch. One nice thing about Fructure is that
it didn't present any parentheses, but I suspect that the way that it
presented grouping meant that if you eventually switched from that mode
of writing code over to textual parenthetical notification, it would
feel like a fairly natural shift.
Raoul Schorer
Jul 15, 2019, 10:41:53 AM7/15/19
to Racket Users
I'm far out of my depth, but...
Doesn't REBOL syntax fit all criteria given in the RacketCon talk? That's a genuine question. Reading about it, I was under the impression that it was basically lisp with alternate syntax.
gfb
Jul 15, 2019, 10:52:48 AM7/15/19
to Racket Users
I've put a package tightlight on the server that “tightens” the highlighting in DrRacket:
Pointing out that it's essentially Scratch's syntax has been helpful in many discussions,
as has using it with faint blue parentheses reminiscent of the subtle lined paper lines
that many are used to not noticing consciously.
There's a View menu item to turn off the outlines, change whether the outline boxes
are horizontally and/or vertically inset, or revert to standard DrRacket.
The package was a hack for a colleague who was teaching our course for non-majors
in 2012, and we still use it. The implementation is a hack because some method needing
to be overriden was private or final, so every method that used it was copied to intercept
that use. Also, I can't resist exploring coding approaches so all the copied code was
rewritten in various ways.
Thomas Burdick
Jul 16, 2019, 4:29:31 AM7/16/19
to Matthew Flatt, Racket Users
I thought I'd add my two cents here, as someone who's been using a mixed-syntax Lisp[*] daily for 15 years now. I've been working with electrical engineers, who aren't programmers, but obviously have a strong technical background.
Traditional algebraic notation for math (what Matthew noted as <expr> + <expr>) is a huge help. +-*/ and < <= == != >= > are all widely used and appreciated. = to mean set! was a bad idea. Programmers like it, but I've seen endless mistakes where someone meant it as equal.
It's helpful to have the functional version of these operators, too. I've seen people use especially add( expr expr expr ), where the sub-expressions were complex enough that you'd run into confusion about precedence when trying to add them together. add and times for + and * seem to be particularly helpful.
No one ever uses {} instead of begin. table[idx] is popular for numeric indexes (both forms are evaluated). As is table->name for symbolic indexes (only table is evaluated).
We have parentheses for disambiguation (ie, (a+b)*c vs a+(b*c)), but not arbitrary amounts of them. So ((a+b)) is going to complain that some number is not a function. I've almost never seen an over-parenthesized expression, and when I did, the engineer immediately understood what had gone wrong.
There are a few ways functions can be called: fn(arg arg arg), fn(arg,arg,arg), or (fn arg arg arg). People mostly use the first, and never or almost never use the second. The classic Lisp syntax is mostly used for syntax forms, where the puttuing the function name before the paren leads to a pileup of parens. Let is a good example:
(let ((a 1) (b 2))
...)
Noone writes
let((((a 1) (b 2))
...)
Instead you'll see either the Lisp style, or
let( (a b)
a=1
b=2
...)
Another example is foreach, which is like a more limited version of Racket's for:
foreach( elt lst
println(elt)
)
But with multiple lists, people will revert to the Lisp style:
(foreach (a b) lstA lstB
printf("a is %L, b is %L\n" a b)
)
This mixed-mode with some Lisp-style function calls, and some C-style ones works out pretty well. Some of our syntax forms were adapted to work well with C-style, but if you get too many close parens, you'll start to see horrors like this:
) ; let
) ; if
) ; let
) ; define
Paren-matching in the editor doesn't seem to help dissuade them.
Those are the relevant bits of experience that I can think of. At a personal level, you get used to the syntax pretty quickly, and it doesn't make it feel less like a Lisp.
In the meantime, I no longer try to teach engineers classic text-based programming, unless they're independantly motivated. Instead, we built a visual programming system in which people who never would have touched a two-list foreach are happily building very complex programs, and even use the each2 iterator. They happily write individual expressions textually (of the x+sin(y) sort, or string formatting or similar). I don't have the impression that an even better textual syntax would have made things much more accessible for assembling larger programs. But this is only glancingly relevant to Racket.
Cheers,
Thomas
[*] SKILL, which is a proprietary Lisp used in microelectronic CAD in Cadence Design Systems products. It has a weird history, with a Franz Lisp derived dialect, and a Scheme derived dialect. They both coexist in the image, and both use the same reader.
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5d2be52a.1c69fb81.f77b6.e393SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
> For more options, visit https://groups.google.com/d/optout.
Traditional algebraic notation for math (what Matthew noted as <expr> + <expr>) is a huge help. +-*/ and < <= == != >= > are all widely used and appreciated. = to mean set! was a bad idea. Programmers like it, but I've seen endless mistakes where someone meant it as equal.
It's helpful to have the functional version of these operators, too. I've seen people use especially add( expr expr expr ), where the sub-expressions were complex enough that you'd run into confusion about precedence when trying to add them together. add and times for + and * seem to be particularly helpful.
No one ever uses {} instead of begin. table[idx] is popular for numeric indexes (both forms are evaluated). As is table->name for symbolic indexes (only table is evaluated).
We have parentheses for disambiguation (ie, (a+b)*c vs a+(b*c)), but not arbitrary amounts of them. So ((a+b)) is going to complain that some number is not a function. I've almost never seen an over-parenthesized expression, and when I did, the engineer immediately understood what had gone wrong.
There are a few ways functions can be called: fn(arg arg arg), fn(arg,arg,arg), or (fn arg arg arg). People mostly use the first, and never or almost never use the second. The classic Lisp syntax is mostly used for syntax forms, where the puttuing the function name before the paren leads to a pileup of parens. Let is a good example:
(let ((a 1) (b 2))
...)
Noone writes
let((((a 1) (b 2))
...)
Instead you'll see either the Lisp style, or
let( (a b)
a=1
b=2
...)
Another example is foreach, which is like a more limited version of Racket's for:
foreach( elt lst
println(elt)
)
But with multiple lists, people will revert to the Lisp style:
(foreach (a b) lstA lstB
printf("a is %L, b is %L\n" a b)
)
This mixed-mode with some Lisp-style function calls, and some C-style ones works out pretty well. Some of our syntax forms were adapted to work well with C-style, but if you get too many close parens, you'll start to see horrors like this:
) ; let
) ; if
) ; let
) ; define
Paren-matching in the editor doesn't seem to help dissuade them.
Those are the relevant bits of experience that I can think of. At a personal level, you get used to the syntax pretty quickly, and it doesn't make it feel less like a Lisp.
In the meantime, I no longer try to teach engineers classic text-based programming, unless they're independantly motivated. Instead, we built a visual programming system in which people who never would have touched a two-list foreach are happily building very complex programs, and even use the each2 iterator. They happily write individual expressions textually (of the x+sin(y) sort, or string formatting or similar). I don't have the impression that an even better textual syntax would have made things much more accessible for assembling larger programs. But this is only glancingly relevant to Racket.
Cheers,
Thomas
[*] SKILL, which is a proprietary Lisp used in microelectronic CAD in Cadence Design Systems products. It has a weird history, with a Franz Lisp derived dialect, and a Scheme derived dialect. They both coexist in the image, and both use the same reader.
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5d2be52a.1c69fb81.f77b6.e393SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
> For more options, visit https://groups.google.com/d/optout.
John Cowan
Jan 13, 2020, 10:38:56 AM1/13/20
to Racket Users
On Sunday, July 14, 2019 at 10:30:04 PM UTC-4, Matthew Flatt wrote:
At RacketCon today, after summarizing the state of work on Racket CS, I
recommended that we next explore the possibly of changing to an
infix-oriented syntax in "Racket2".
I realize that Racket2 is the name of the project, but I think it's very important that the *language* of the project gets its own unique name. Otherwise outsiders will see it as the successor, the important one, the one they should use by default, because they will think Racket1 (which will quickly become the human-oriented name of the existing language) has become obsolete. Larry Wall just changed the name of Perl 6 to Raku, and this is a Good Thing, because it deflects the "When are you going to replace Perl 5?" question.
John Cowan http://vrici.lojban.org/~cowan co...@ccil.org
I don't know half of you half as well as I should like, and I like less
than half of you half as well as you deserve. --Bilbo
David Storrs
Jan 13, 2020, 10:54:07 AM1/13/20
to John Cowan, Racket Users
On Mon, Jan 13, 2020 at 10:38 AM John Cowan <co...@ccil.org> wrote:
On Sunday, July 14, 2019 at 10:30:04 PM UTC-4, Matthew Flatt wrote:At RacketCon today, after summarizing the state of work on Racket CS, I
recommended that we next explore the possibly of changing to an
infix-oriented syntax in "Racket2".I realize that Racket2 is the name of the project, but I think it's very important that the *language* of the project gets its own unique name. Otherwise outsiders will see it as the successor, the important one, the one they should use by default, because they will think Racket1 (which will quickly become the human-oriented name of the existing language) has become obsolete. Larry Wall just changed the name of Perl 6 to Raku, and this is a Good Thing, because it deflects the "When are you going to replace Perl 5?" question.
+1
John Cowan http://vrici.lojban.org/~cowan co...@ccil.orgI don't know half of you half as well as I should like, and I like lessthan half of you half as well as you deserve. --Bilbo
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/2f002c9e-61f2-4fd4-8014-0cd3d4e61853%40googlegroups.com.
Matthew Flatt
Jan 13, 2020, 10:57:22 AM1/13/20
to John Cowan, Racket Users
The project name is "Rhombus". The language name is TBD.
https://groups.google.com/forum/#!msg/racket-users/-x_M5wIhtWk/V47eL30HCgAJ
https://groups.google.com/forum/#!msg/racket-users/-x_M5wIhtWk/V47eL30HCgAJ
Sage Gerard
Jan 13, 2020, 11:06:30 AM1/13/20
to mfl...@cs.utah.edu, co...@ccil.org, racket...@googlegroups.com
I'd take this thread as evidence that outdated information is easier to discover than Rhombus. How many mentions of "Racket2" currently ranking in search engines have added mentions of Rhombus? Maybe it's not a big problem right now, but could it get harder to manage?
-------- Original Message --------
-------- Original Message --------
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5e1c935f.1c69fb81.9e1f7.8c0bSMTPIN_ADDED_MISSING%40gmr-mx.google.com.
Reply all
Reply to author
Forward
0 new messages