The case, and a proposal, for elegant syntax in #lang racket2

4016 views
Skip to first unread message

Christopher Lemmer Webber

unread,
Jul 14, 2019, 1:44:30 PM7/14/19
to Racket Users, Arne Babenhauserheide
The context of this email is the proposal by Matthew Flatt that we move
to an easier-to-accept surface syntax for #lang racket2.

Matthew Flatt has heard more than enough from me of concern about this
proposal. But I should indicate that I'm highly sympathetic to the
goal. I would like to lay out the following observations:

- The challenge with s-expressions is largely in anxiety with something
that looks extremely alien. I suspect there's more fear from
instructors than students in encountering a lisp syntax; my
experience is that introducing someone who doesn't know differently
to a parenthetical syntax isn't scary for them, and they tend to like
it. But people who have *started out* with experience in a non-lispy
language tend to find it scary.

- Nonetheless, assumptions that various math operators should be infix
is understandable because that's what people see today.

- I am indeed very for growth in the community, though my main interest
in growth is in seeing a wider diversity of participants than just
raw numbers. Obviously other peoples' mileage may vary.

- We are at serious risk in this pivot of losing some key things:

- Many communities I have been in that have undertaken such a large
pivot to increase popularity expend enormous energy in the move to
the new thing, and in that process, the project actually collapses.
What I'm trying to say is that a pivot is a gamble; we should
calculate our odds carefully. (Indeed, the first thing I thought
when I heard that this might happen was, did I make a mistake in
shifting my work to Racket? It is unlikely I would have come to
Racket if there wasn't an equivalent amount of elegance.)

- I'm not sure if I could have understood Racket Week with a syntax
that didn't have the elegance of s-expressions. This is not to say
that *no* syntax can have that level of elegance where things can
be so clear, however.

IIRC Matthew's proposal for "#lang racket2" was something like the
following:

a) function(args ...) should work.
b) infix is necessary for math, such as 3 + 4
c) parentheses should be possible for grouping

The weird thing about the last one being that this is already kind of
true in s-expressions, but by ~default this also results in application.

Let me add one more suggested design goal:

- the new syntax should must not be significantly less elegant than
s-expressions.

Is there a way to achieve this? I actually think the best path forward
is to have a surface syntax that actually maps completely to
s-expressions, which is in fact universal that it can work with *any*
s-expression syntax.

I would suggest starting with Wisp as the basis for examining this:

https://dustycloud.org/blog/wisp-lisp-alternative/
https://srfi.schemers.org/srfi-119/srfi-119.html

Sweet-expressions may also be an alternative to explore. However, I
think Wisp is a more elegant base; it can transform *any* wisp code into
s-exp code. Not discussed in my blogpost about Wisp is that it also
supports infix via {3 + 4}. So ok, now we have that. And we can still
group:

{3 + {8 + 4}}

So that's points b) and c), but we don't have a) yet. Could we add it?

I think we can extend wisp with one thing and get everything we want: if
you have func(arg1 arg2 arg3) where the parenthesis comes *immediately*
after the symbol, that is rewritten to (func arg1 arg2 arg3). I will
call this version ~Wisp.

With all this, observe the following code rewritten from Scheme to ~Wisp:

(define (rgb-maker mk)
(lambda (sz)
(vc-append (colorize (mk sz) "red")
(colorize (mk sz) "green")
(colorize (mk sz) "blue"))))

define rgb-maker(mk)
lambda(sz)
vc-append(colorize(mk(sz) "red")
colorize(mk(sz) "green")
colorize(mk(sz) "blue"))

Here is another chunk of code, taken from HTdP2:

(and (or (= (string-length "hello world")
(string->number "11"))
(string=? "hello world" "good morning"))
(>= (+ (string-length "hello world") 60) 80))

To:

and(or({string-length("hello world") = string->number("11")}
string=?("hello world" "good morning"))
{{(string-length "hello world") + 60} >= 80})

And in fact the latter can transform itself *directly* into the former.
And the former technically is also still valid Wisp: you can embed
s-expressions into it and they still work.

I think this satisfies the requirements that Matthew laid out.

There's another major advantage of this. We can now write languages
that work either like:

#lang s-exp "mylang.rkt"

or:

#lang wisp "mylang.rkt"

The main thing that Wisp is missing right now is editor tooling so that
doing indentation is convenient. But that's more than feasible to add,
imo.

I think this is the best way to move forward without creating
significant divisions, throwing out valuable things we have, or making
future Racket Week courses all that much harder. What do people think?

- Chris

Christopher Lemmer Webber

unread,
Jul 14, 2019, 1:53:06 PM7/14/19
to Racket Users, Arne Babenhauserheide
I sent this about 5 minutes before Jay announced
https://github.com/racket/racket2-rfcs :)

Matthew Flatt

unread,
Jul 14, 2019, 4:45:07 PM7/14/19
to Christopher Lemmer Webber, Racket Users, Arne Babenhauserheide
At Sun, 14 Jul 2019 13:44:27 -0400, Christopher Lemmer Webber wrote:
> The context of this email is the proposal by Matthew Flatt that we move
> to an easier-to-accept surface syntax for #lang racket2.

I appreciate your enthusiasm to get started! And I normally appreciate
concrete proposals to solve problems. But I think the
design-and-exploration task that we have ahead is too big for this mode
of operation. Specifically, I don't think we should use the mailing
list to broadcast and discuss concrete solutions just now.

It's presumably on me to propose the next step, so stay tuned. I won't
offer a proposal for a solution or even a proposal for a set of
constraints on a solution. Instead, I intend a proposal (informed by
Aaron's talk) for the social structure that we use to study the
possibilities for Racket2, including but not limited to the question of
reader syntax.

In other words, while it's tempting to jump into technical discussions,
I think we'll need to take this more slowly and formally, making sure
that we agree on a set of goals/constraints for a potential new syntax.
Just as an example, I would advocate the constraint that

function(arg, ...)

needs to be the function-call syntax --- with commas --- not just

function(arg ...)

as you wrote it. My point is not to debate the comma detail here or
establish it a priori as a requirement, but only to illustrate the
layers of discussion that we'll need to work through.

Travis Hinkelman

unread,
Jul 14, 2019, 5:12:22 PM7/14/19
to Racket Users
(Indeed, the first thing I thought 
     when I heard that this might happen was, did I make a mistake in 
     shifting my work to Racket?  It is unlikely I would have come to 
     Racket if there wasn't an equivalent amount of elegance.) 

I want to briefly echo this sentiment. I've been casually learning Racket for several months (and greatly enjoying it), which was preceded by several months of reading and thinking about which programming language to learn next (my background is as a biologist that uses R and NetLogo). When I was listening to the livestream this morning, I had a moment of panic that maybe I had made the wrong choice to learn Racket. Or maybe I jumped on the Racket train at the wrong time.

Thanks,

Travis 

Greg Trzeciak

unread,
Jul 14, 2019, 9:49:46 PM7/14/19
to Racket Users
Not willing to enter the discussion I feel incompetent about, just for a sake of completeness I will mention another previous attempt that wasn't mentioned before (alternative to sweet/wisp):

Jack Rosenthal

unread,
Jul 15, 2019, 8:22:27 AM7/15/19
to Christopher Lemmer Webber, Racket Users, Arne Babenhauserheide
I think you make valid points, I just wanted to provide an alternate
opinion...

On Sun, 14 Jul 2019 at 13:44 -0400, Christopher Lemmer Webber wrote:
> - The challenge with s-expressions is largely in anxiety with something
> that looks extremely alien. I suspect there's more fear from
> instructors than students in encountering a lisp syntax; my
> experience is that introducing someone who doesn't know differently
> to a parenthetical syntax isn't scary for them, and they tend to like
> it. But people who have *started out* with experience in a non-lispy
> language tend to find it scary.

On the contrary, there are plenty of other languages to choose from for
non-SE syntax, including many which have been successfully used as a
teaching language (Python, Java, ...).

Yes, some people use Racket as a teaching language. But given Racket's
position in the languages ecosystem, instructors probably come to Racket
due to it's unfamiliar syntax...

>
> - Nonetheless, assumptions that various math operators should be infix
> is understandable because that's what people see today.

One of my gripes from writing and reading (reviewing) C code on a daily
basis is that I have a hard time remembering the precedence of the
operators beyond PEMDAS. Things get murky when trying to figure out the
order of the other operators. And as soon as you start allowing infix,
you better allow extending it, for better or worse.

> - I am indeed very for growth in the community, though my main interest
> in growth is in seeing a wider diversity of participants than just
> raw numbers. Obviously other peoples' mileage may vary.

At what point are you still growing Racket instead of some other (new)
language. Do we really need another Python?

--
Jack M. Rosenthal
http://jack.rosenth.al

That code? Must have been the last guy...

signature.asc

Hendrik Boom

unread,
Jul 15, 2019, 8:47:25 AM7/15/19
to Racket Users
On Mon, Jul 15, 2019 at 01:22:20PM +0100, Jack Rosenthal wrote:
>
> One of my gripes from writing and reading (reviewing) C code on a daily
> basis is that I have a hard time remembering the precedence of the
> operators beyond PEMDAS. Things get murky when trying to figure out the
> order of the other operators. And as soon as you start allowing infix,
> you better allow extending it, for better or worse.

The one I always have trouble with is the precedence between prefix * and
postfix []. There would have been no confusion if both had been postfic
operators. Mind you, then they might have had to use a different symbol for
dereference to avoid confusion with multiplication.

Abstract syntax is clean. Concrete syntax is a rat's nest of confusion.

-- hendrik

Jack Rosenthal

unread,
Jul 15, 2019, 9:10:11 AM7/15/19
to Racket Users
On Mon, 15 Jul 2019 at 08:47 -0400, Hendrik Boom wrote:
> On Mon, Jul 15, 2019 at 01:22:20PM +0100, Jack Rosenthal wrote:
> > One of my gripes from writing and reading (reviewing) C code on a daily
> > basis is that I have a hard time remembering the precedence of the
> > operators beyond PEMDAS. Things get murky when trying to figure out the
> > order of the other operators. And as soon as you start allowing infix,
> > you better allow extending it, for better or worse.
>
> The one I always have trouble with is the precedence between prefix * and
> postfix []. There would have been no confusion if both had been postfic
> operators. Mind you, then they might have had to use a different symbol for
> dereference to avoid confusion with multiplication.

*p++

;)

--
Jack M. Rosenthal
http://jack.rosenth.al

Computers were a mistake.
-- Ethan Hunter

signature.asc

Hendrik Boom

unread,
Jul 15, 2019, 9:35:06 AM7/15/19
to Racket Users
On Mon, Jul 15, 2019 at 02:10:05PM +0100, Jack Rosenthal wrote:
> On Mon, 15 Jul 2019 at 08:47 -0400, Hendrik Boom wrote:
> > On Mon, Jul 15, 2019 at 01:22:20PM +0100, Jack Rosenthal wrote:
> > > One of my gripes from writing and reading (reviewing) C code on a daily
> > > basis is that I have a hard time remembering the precedence of the
> > > operators beyond PEMDAS. Things get murky when trying to figure out the
> > > order of the other operators. And as soon as you start allowing infix,
> > > you better allow extending it, for better or worse.
> >
> > The one I always have trouble with is the precedence between prefix * and
> > postfix []. There would have been no confusion if both had been postfic
> > operators. Mind you, then they might have had to use a different symbol for
> > dereference to avoid confusion with multiplication.
>
> *p++

Pascals postfix ^ for this right.

p++^ or p^++
p[1]^ or p^[1]

Of course in C we'd then need a new symbol for xor.

-- hendrik

Hendrik Boom

unread,
Jul 15, 2019, 9:49:32 AM7/15/19
to Racket Users
The one problem I have with s-expression syntax is deep indentation with
tail-nesting.

In one lisp-like language I solved this by letting

( blah blah blah / foo foo foo / bar bar bar )

abbreviate

( blah bah blah ( foo foo foo ( bar bar bar )))

With indentation this gives

( blah blah blah
/ foo foo foo
/ bar bar bar
)

instead of

( blah blah blah
( foo foo foo
( bar bar bar )))

It really helps when the blah's, foo's and bar's are complicated multiline
subexpressions.

It linearizes long chains of nesting, and works very well with if chains.

It also works with single-variable let clauses, though it invites a syntax
like

(let definiens definiendum blah)
instead of
(let ((definiens definiendum)) blah)

with the latter form needed only for letrec. Adding this to existing scheme
would probably need a different name for 'let'.

The problem I see with this is that all the convenient characters to use for
'/' have already been taken.

This might not be such a problem for a completely new #lang, though.

-- hendrik

Matthias Felleisen

unread,
Jul 15, 2019, 12:19:16 PM7/15/19
to Racket Users


> On Jul 14, 2019, at 1:44 PM, someone wrote:
>
> - I am indeed very for growth in the community, though my main interest
> in growth is in seeing a wider diversity of participants than just
> raw numbers. Obviously other peoples' mileage may vary.


This is politics and politics has no business whatsoever on this mailing list. I believe there are things such as Facebook, Instagram and other Web-chambers where political opinions are welcome and echoes will always confirm your opinions.

;; - - -

Our policy has always been that everyone, absolutely everyone, is welcome on this technical list to discuss technical issues. We don’t exclude anyone. And everyone gets treated the same and gets productive responses if possible. In particular, politics stays off this list; it’s divisive enough in the rest of the world.

Thank you — Matthias

Jack Firth

unread,
Jul 15, 2019, 1:06:12 PM7/15/19
to Racket Users
Matthias, I ask that you please not respond to discussion about the diversity of the Racket community by saying it's a political topic and politics have no place here. That statement alone is political and makes many people feel unwelcome, including me.

On the topic of a new syntax: I am strongly in favor. I think it will remove barriers to entry that have deterred many potential Racketeers. And if there's one community I trust to put care and thoughtfulness into a surface syntax design, it's the Racket community.

David Storrs

unread,
Jul 15, 2019, 1:54:21 PM7/15/19
to Jack Firth, Racket Users
In the language of web forums: +1 Insightful to Jack Firth's comments.


Back on topic:
The question that is most important to me is: Once #lang racket2 is designed and produced and out in the world, will #lang racket still be actively supported? If not, will there be tooling available to convert source files back and forth between racket and racket2, and will there be a commitment to keeping that tooling up to date? I have no problem treating racket2 as an object format that I can decompile when I want to work on someone else's code, or compile to when I want to publish my own.  

Clear communication: The following is my personal feeling and emotional reaction. I understand that the core Racket team has no reason to be influenced by it, and I am offering it merely as a data point:

If the scenarios I asked about aren't on the table, I
 feel like I might as well start evaluating other Lisp variants now. If I wanted to work in something that looked like Python or C and had the cognitive load of Python or C then I would work in Python or C. It would make me much more employable.


--
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/a63d9bdb-4d5d-49e8-9451-d6524ac24752%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Christopher Lemmer Webber

unread,
Jul 15, 2019, 1:55:02 PM7/15/19
to Jack Firth, Racket Users
Jack Firth writes:

> Matthias, I ask that you please not respond to discussion about the
> diversity of the Racket community by saying it's a political topic and
> politics have no place here. That statement alone is political and makes
> many people feel unwelcome, including me.

Likewise... and I find it troubling that I did not specify a mechanism
for improving diversity, just stated that it would be nice to see it
improved, and this was stated as a problem.

>> Our policy has always been that everyone, absolutely everyone, is
>> welcome on this technical list to discuss technical issues. We don’t
>> exclude anyone. And everyone gets treated the same and gets productive
>> responses if possible. In particular, politics stays off this list; it’s
>> divisive enough in the rest of the world.

If absolutely everyone is welcome, why is not absolutely everyone here?

It does not seem to be controvercial to state that we would like more
middle schoolers using Racket; indeed, this appears to be the goal of
Racket 2. If we extend that logic, there is no reason we cannot wish
for aiming for that level of success for other groups.

I agree that programming should be absolutely for everyone, that is part
of what brought me to Racket and I think it is uniquely positioned to
meet that goal. I look forward to coming to RacketCon in the future,
looking around, and feeling that it looks like we are achieving that
dream.

- Chris

Matthias Felleisen

unread,
Jul 15, 2019, 1:55:59 PM7/15/19
to Jack Firth, Racket Users

Jack,

the word “diversity” is inherently political. It is designed as a wedge, a tool to separate people into groups and then from each other. It is used as a kudgel by one side of the political spectrum to relentlessly hit the other side. It was bad enough to have been told that there were too many “cis-gendered white males” at RacketCon.

My message was not one of __politics__ but of __policy__. (And for the record, you have no clue what my political views are or how I deal with the diversity of individuals in this community.) I do not wish to see this mailing list turn into another political echo chamber, because then I have to remove myself from it and the public Racket community. If people wish to discuss the politics of diversity in the Racket community, please create a Facebook group and go there.

— Matthias

David Storrs

unread,
Jul 15, 2019, 1:56:08 PM7/15/19
to Jack Firth, Racket Users
Hazards of reading email from the top down: Apparently there is a commitment to keeping #lang racket working. Phew! Thank you, core team!
Message has been deleted

Neil Van Dyke

unread,
Jul 15, 2019, 2:27:05 PM7/15/19
to Racket Users
While we're all still figuring out how to best welcome and support
everyone in CS-ish things, maybe it should be mentioned that Racketeers
have some awareness and appreciation of familiar concerns, including
from a research perspective (starting at least 15 years ago):

> High school teachers who implement HTDP report similar success stories
> as colleges but in a less measurable manner. Still, the HTDP
> curriculum has had an interesting measurable effect concerning female
> students. Several instructors reported that female students like the
> HtDP curriculum exceptionally well. In a controlled experiment, an
> HTDP-trained instructor taught a conventional AP curriculum and the
> Scheme curriculum to the same three classes of students. Together the
> three classes consisted of over 70 students. While all students
> preferred our approach to programming, the preference among females
> was a stunning factor of four. An independent evaluator is now
> investigating this aspect of the project in more depth.
  -- Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, Shriram
Krishnamurthi, ``The Structure and Interpretation of the Computer
Science Curriculum,'' Journal of Functional Programming, 2004.
http://www.ccis.neu.edu/racket/pubs/jfp2004-fffk.pdf

Wesley Kerfoot

unread,
Jul 15, 2019, 2:28:00 PM7/15/19
to Racket Users
Has anyone considered http://shriram.github.io/p4p/ as an alternative?

The idea in a nutshell is to get rid of the implicit `(begin ...)` that many of the forms have, and use that to reduce the number of required parentheses for parsing, and add in some extra syntactic sugar in the form of `:` (colon) to further reduce the need for parens.

It retains the prefix notation for most things as well, and does not require giving special meaning to braces.

Neil Van Dyke

unread,
Jul 15, 2019, 2:34:31 PM7/15/19
to Racket Users
Wesley Kerfoot wrote on 7/15/19 2:28 PM:
> Has anyone considered http://shriram.github.io/p4p/ as an alternative?

This might represent Shriram's current thinking (and is what I was
alluding to before): https://www.pyret.org/

I'll wait for the official community process to commence, before I get
deep in discussion.

David Storrs

unread,
Jul 15, 2019, 2:38:20 PM7/15/19
to Matthias Felleisen, Jack Firth, Racket Users
On Mon, Jul 15, 2019, 11:55 AM Matthias Felleisen <matt...@felleisen.org> wrote:

Jack,

the word “diversity” is inherently political. It is designed as a wedge, a tool to separate people into groups and then from each other. It is used as a kudgel by one side of the political spectrum to relentlessly hit the other side. It was bad enough to have been told that there were too many “cis-gendered white males” at RacketCon.

[...]

I do not wish to see this mailing list turn into another political echo chamber, because then I have to remove myself from it and the public Racket community. [...]

It sounds like you've had some tough experiences lately, and, quite reasonably, you don't want to go through that again. I totally sympathize; I have just finished a very unpleasant judicial harassment by the oversensitive moderators of a forum where I publish fiction. It's exhausting and bruising.

It actually might not be a bad idea for you to step away for a few days and get your energy back -- I'm mostly doing that on my forum.  If that's not something you want to do, you might find the conversation less infuriating if you try to focus on the Charitable Reading technique: put things down to poor word choice or miscommunication instead of malice. If someone says something that you feel is offensive, insensitive, etc, assume they didn't mean it that way and look for an alternate interpretation. For example, I assumed that the use of "diversity" was in the sense of "variety of experience and viewpoint" not race, gender, etc. I totally sympathize with not wanting the list -- and, in particular, a thread about language design -- to transform into a social justice debate. That's offtopic. Still, I'm sure we would all agree that the arrival of people with new ideas and experience could only be helpful to Racket.


— Matthias







> On Jul 15, 2019, at 1:06 PM, Jack Firth <jackh...@gmail.com> wrote:
>
> Matthias, I ask that you please not respond to discussion about the diversity of the Racket community by saying it's a political topic and politics have no place here. That statement alone is political and makes many people feel unwelcome, including me.
>
> On the topic of a new syntax: I am strongly in favor. I think it will remove barriers to entry that have deterred many potential Racketeers. And if there's one community I trust to put care and thoughtfulness into a surface syntax design, it's the Racket community.
>
> On Monday, July 15, 2019 at 10:19:16 AM UTC-6, Matthias Felleisen wrote:
>
>
> > On Jul 14, 2019, at 1:44 PM, someone wrote:
> >
> > - I am indeed very for growth in the community, though my main interest
> >   in growth is in seeing a wider diversity of participants than just
> >   raw numbers.  Obviously other peoples' mileage may vary.
>
>
> This is politics and politics has no business whatsoever on this mailing list. I believe there are things such as Facebook, Instagram and other Web-chambers where political opinions are welcome and echoes will always confirm your opinions.
>
> ;; - - -
>
> Our policy has always been that everyone, absolutely everyone, is welcome on this technical list to discuss technical issues. We don’t exclude anyone. And everyone gets treated the same and gets productive responses if possible. In particular, politics stays off this list; it’s divisive enough in the rest of the world.
>
> Thank you — Matthias
>
>
> --
> 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/a63d9bdb-4d5d-49e8-9451-d6524ac24752%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
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.

Matthew Butterick

unread,
Jul 15, 2019, 3:51:57 PM7/15/19
to Racket Users, Matthias Felleisen
[forked from "The case, and a proposal, for elegant syntax in #lang racket2"]


On 07 15 19, at 10:55 AM, Matthias Felleisen <matt...@felleisen.org> wrote:

the word “diversity” is inherently political. It is designed as a wedge, a tool to separate people into groups and then from each other. It is used as a kudgel by one side of the political spectrum to relentlessly hit the other side. It was bad enough to have been told that there were too many “cis-gendered white males” at RacketCon. 


For those who weren't there: the comment about "cis-gendered white males" [1] was made from the stage by RacketCon 2019 speaker Bradley Kuhn, president of the Software Freedom Conservancy, which now oversees Racket. Bradley was invited to speak about "Conservancy and Racket: What We Can Do Together".

I enjoyed Bradley's talk. But I'm now unclear about the policy relationship between Conservancy & Racket. 

IIUC, as a Conservancy project, Conservancy's policies are now necessarily Racket's policies, even if that wasn't the case before. This seems clearly spelled out in the fiscal-sponsorship agreement Racket executed (which was shared with this list last year) — that Racket is "subject at all times to the direction and control of Conservancy’s Board of Directors". [2]


I do not wish to see this mailing list turn into another political echo chamber, because then I have to remove myself from it and the public Racket community. If people wish to discuss the politics of diversity in the Racket community, please create a Facebook group and go there. 

Stepping gingerly here, it does seem that Bradley Kuhn and Conservancy intend that some notion of "diversity" becomes an explicit part of Racket's outward policy orientation (and not, say, relegated to a private Facebook group). He said so at RacketCon. [1]

For this reason Matthias, I'm not clear whether you're speaking for yourself in this case (as you sometimes do) or for Racket management (as you sometimes do). Are you saying that on a personal level, it's not your favorite aspect of the Conservancy relationship? Or are you saying that Racket, as a Conservancy project, is repudiating part of Conservancy's policy platform?

Sam Tobin-Hochstadt

unread,
Jul 15, 2019, 4:35:35 PM7/15/19
to Matthias Felleisen, Racket Users
Matthias, I disagree with this. First, we all believe that the Racket community is one of the most important parts of Racket. Given that, how to make it the community we want it to be, and how to welcome as many new people to our community as possible, are fundamental to what we discuss on this list. You, and many others in the Racket community, have done great work making computing accessible to new people and people who are underrepresented, and I hope we can do more of that for the Racket community itself, along both of the axes that Chris mentioned.  

Second, while I agree that this list is not an appropriate place for general political discussion, the things we do here cannot be entirely separated from things we might call politics. For example, making it possible for more people to create software and to understand the systems around them is political, just as making a welcoming community is political. We can't entirely avoid politics, even if we wanted to, and instead we have to do the right things together for our communities. 

Sam

--
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.

For more options, visit https://groups.google.com/d/optout.
--
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.

Hendrik Boom

unread,
Jul 15, 2019, 5:03:39 PM7/15/19
to Racket Users
On Mon, Jul 15, 2019 at 11:26:06AM -0700, Wesley Kerfoot wrote:
> Has anyone considered http://shriram.github.io/p4p/ as an alternative?
>
> The idea in a nutshell is to get rid of the implicit `(begin ...)` that
> many of the forms have, and use that to reduce the number of required
> parentheses for parsing, and add in some extra syntactic sugar in the form
> of `:` (colon) to further reduce the need for parens.

Does current Racket already have a meaning for ':'?
Are there any other characters that are still free?

-- hendrik

Maciek Godek

unread,
Jul 15, 2019, 6:14:42 PM7/15/19
to Racket Users


W dniu niedziela, 14 lipca 2019 19:44:30 UTC+2 użytkownik cwebber napisał:
[...]

 - Nonetheless, assumptions that various math operators should be infix
   is understandable because that's what people see today.

I'd recommend to do some crawling on Racket code base to see what percent of used functions are "math operations" -- my guess is that it's going to be very small.
While I can see some reasons behind having infix syntax, namely -- asymmetric binary prediates -- most of it can be resolved within s-expressions (I have described it in SRFI-156).

Another place where I think infix could be handy is in functions' type signatures in typed/racket.

I believe that, rather than

(: list-length (All (A) (-> (Listof A) Integer)))

it would be better to write something like:

(declare list-length : (All (A) (Listof A) -> Integer))

or

(declare (list-length (Listof ,A)) -> Integer)

But this also could be easily achievable within the realm of s-expressions.

Shriram Krishnamurthi

unread,
Jul 15, 2019, 10:07:19 PM7/15/19
to Racket Users
P4P is also very much "current", as far as I'm concerned. (In fact, I'm quite likely about to use it in a new setting.) Pyret is a parallel branch effort. 

Pyret is "let's just go all out and design a new syntax". Specifically, I was tired of dealing with people who wouldn't read How to Design Programs because of the syntax, and wanted to be able to communicate its ideas to them. We realized that a new syntax could go a long ways. It has. But I still dream in parentheses. (-:

P4P, in contrast, was my attempt at an answer to "how far can we go with Racket's existing mechanisms?"

Indeed, the original P4P is flawed in that it seems to take Racket as the base language. In retrospect, this isn't what I meant. I meant for P4P to be a syntax that layers atop whatever underlying (semantic) language you want, as a different reader. It wasn't really implemented that way, but should have been/should be. Then you could use any existing Racket language with P4P syntax as its surface.

Shriram

Shriram Krishnamurthi

unread,
Jul 15, 2019, 11:41:12 PM7/15/19
to Racket Users
Another Racketeer here who's been in the community since day 0.

We have various views and people in the community. But our commitment to making tools and learning available to all, open to all, and catering to all — what many of us label diversity — is, I hope, demonstrated by our actions.

Several of us work ceaselessly on Bootstrap, easily one of the most diverse computing offerings in the US. Our numbers are beyond what programs dream of. And yet we keep working on improving our diversity impact [https://www.bootstrapworld.org/impact/]. That means not only what most people consider — women and underrepresented minorities — but also other kinds of underrepresentation in computing: the visually-impaired, those with learning disabilities (new project just starting up), etc., etc. And Bootstrap is listed right on the box [https://racket-lang.org].

Other things we've done include pioneering free online texts. Matthias et al's HtDP was one of the first such books (especially prominent ones, from a prominent publisher). Why? Because reaching out across economic divides was infinitely more important that royalties. To this day, most prominent texts don't follow this policy. Yet HtDP proudly does, as do many other books we've written (like PLAI and PAPL).

Mailing lists are not great places for nuance and differences of interpretation of words. (Twitter is even worse!) But many long-standing Racket folks care very deeply about what I believe others here refer to as diversity — perhaps even forms of it not initially intended, but hopefully also welcome — and have put $ and time where it matters.

Shriram

Konrad Hinsen

unread,
Jul 16, 2019, 5:31:03 AM7/16/19
to Sam Tobin-Hochstadt, Matthias Felleisen, Racket Users
Sam,

> Matthias, I disagree with this. First, we all believe that the Racket
> community is one of the most important parts of Racket. Given that,
> how to make it the community we want it to be, and how to welcome as
> many new people to our community as possible, are fundamental to what
> we discuss on this list.

I can see the utility of a forum to discuss these questions, but does it
have to be this list?

My experience is that community introspection can easily invade on-line
discussions to the point of drowning everything else, and driving away
people who are more interested in the stated goal of the community than
in its management and policies.

Konrad.

David Storrs

unread,
Jul 16, 2019, 8:38:19 AM7/16/19
to Konrad Hinsen, Sam Tobin-Hochstadt, Matthias Felleisen, Racket Users
The list is named racket-users, so the question of "who do we want as Racket users?" seems pretty on-point to me. Still, I get how it might not interest everyone. Maybe just mute this thread?

--
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.

Konrad Hinsen

unread,
Jul 16, 2019, 2:31:40 PM7/16/19
to David Storrs, Racket Users
David Storrs <david....@gmail.com> writes:

> The list is named racket-users, so the question of "who do we want as
> Racket users?" seems pretty on-point to me. Still, I get how it might not
> interest everyone. Maybe just mute this thread?

It's not so much this thread as future threads that are likely to
arrive, judging from what has happened in many other places.

The name of the list was chosen aeons ago in different circumstances,
so I don't think it should be the basis for defining the list's purpose
today. The question is rather whether we want to combine or separate
community introspection and community purpose. I am for separating.

Konrad.

Gustavo Massaccesi

unread,
Jul 16, 2019, 2:46:16 PM7/16/19
to Christopher Lemmer Webber, Racket Users, Arne Babenhauserheide
I always imagined racket2 as racket with a few minor backward incompatible changes, for example make `length` generic, drop `struct`, remove guarantees about freshness of results. I.E. Most of https://github.com/racket/racket/wiki/Racket2  I also don't like that `syntax-property` is used to get and to set the properties but I doubt it's a common opinion.

Perhaps I'm overestimating the changes, but this looks like a new language. Why not use another name?

Also, it would be nice to have a rough timeline. 5 years?

Gustavo

 

On Sun, Jul 14, 2019 at 2:44 PM Christopher Lemmer Webber <cwe...@dustycloud.org> wrote:
The context of this email is the proposal by Matthew Flatt that we move
to an easier-to-accept surface syntax for #lang racket2.

Matthew Flatt has heard more than enough from me of concern about this
proposal.  But I should indicate that I'm highly sympathetic to the
goal.  I would like to lay out the following observations:


 - The challenge with s-expressions is largely in anxiety with something
   that looks extremely alien.  I suspect there's more fear from
   instructors than students in encountering a lisp syntax; my
   experience is that introducing someone who doesn't know differently
   to a parenthetical syntax isn't scary for them, and they tend to like
   it.  But people who have *started out* with experience in a non-lispy
   language tend to find it scary.

 - Nonetheless, assumptions that various math operators should be infix
   is understandable because that's what people see today.

 - I am indeed very for growth in the community, though my main interest
   in growth is in seeing a wider diversity of participants than just
   raw numbers.  Obviously other peoples' mileage may vary.

 - We are at serious risk in this pivot of losing some key things:

   - Many communities I have been in that have undertaken such a large
     pivot to increase popularity expend enormous energy in the move to
     the new thing, and in that process, the project actually collapses.
     What I'm trying to say is that a pivot is a gamble; we should
     calculate our odds carefully.  (Indeed, the first thing I thought
     when I heard that this might happen was, did I make a mistake in
     shifting my work to Racket?  It is unlikely I would have come to
     Racket if there wasn't an equivalent amount of elegance.)

   - I'm not sure if I could have understood Racket Week with a syntax
     that didn't have the elegance of s-expressions.  This is not to say
     that *no* syntax can have that level of elegance where things can
     be so clear, however.

IIRC Matthew's proposal for "#lang racket2" was something like the
following:

 a) function(args ...) should work.
 b) infix is necessary for math, such as 3 + 4
 c) parentheses should be possible for grouping

The weird thing about the last one being that this is already kind of
true in s-expressions, but by ~default this also results in application.

Let me add one more suggested design goal:

 - the new syntax should must not be significantly less elegant than
   s-expressions.

Is there a way to achieve this?  I actually think the best path forward
is to have a surface syntax that actually maps completely to
s-expressions, which is in fact universal that it can work with *any*
s-expression syntax.

I would suggest starting with Wisp as the basis for examining this:

  https://dustycloud.org/blog/wisp-lisp-alternative/
  https://srfi.schemers.org/srfi-119/srfi-119.html

Sweet-expressions may also be an alternative to explore.  However, I
think Wisp is a more elegant base; it can transform *any* wisp code into
s-exp code.  Not discussed in my blogpost about Wisp is that it also
supports infix via {3 + 4}.  So ok, now we have that.  And we can still
group:

  {3 + {8 + 4}}

So that's points b) and c), but we don't have a) yet.  Could we add it?

I think we can extend wisp with one thing and get everything we want: if
you have func(arg1 arg2 arg3) where the parenthesis comes *immediately*
after the symbol, that is rewritten to (func arg1 arg2 arg3).  I will
call this version ~Wisp.

With all this, observe the following code rewritten from Scheme to ~Wisp:

  (define (rgb-maker mk)
    (lambda (sz)
      (vc-append (colorize (mk sz) "red")
                 (colorize (mk sz) "green")
                 (colorize (mk sz) "blue"))))

  define rgb-maker(mk)
    lambda(sz)
      vc-append(colorize(mk(sz) "red")
                colorize(mk(sz) "green")
                colorize(mk(sz) "blue"))

Here is another chunk of code, taken from HTdP2:

  (and (or (= (string-length "hello world")
              (string->number "11"))
           (string=? "hello world" "good morning"))
       (>= (+ (string-length "hello world") 60) 80))

To:

  and(or({string-length("hello world") = string->number("11")}
         string=?("hello world" "good morning"))
      {{(string-length "hello world") + 60} >= 80})

And in fact the latter can transform itself *directly* into the former.
And the former technically is also still valid Wisp: you can embed
s-expressions into it and they still work.

I think this satisfies the requirements that Matthew laid out.

There's another major advantage of this.  We can now write languages
that work either like:

  #lang s-exp "mylang.rkt"

or:

  #lang wisp "mylang.rkt"

The main thing that Wisp is missing right now is editor tooling so that
doing indentation is convenient.  But that's more than feasible to add,
imo.

I think this is the best way to move forward without creating
significant divisions, throwing out valuable things we have, or making
future Racket Week courses all that much harder.  What do people think?

 - Chris


--
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.

rocketnia

unread,
Jul 16, 2019, 4:32:44 PM7/16/19
to Racket Users
On Tuesday, July 16, 2019 at 11:46:16 AM UTC-7, gustavo wrote:
I always imagined racket2 as racket with a few minor backward incompatible changes, for example make `length` generic, drop `struct`, remove guarantees about freshness of results. I.E. Most of https://github.com/racket/racket/wiki/Racket2

Yeah, I second this. At one point I was looking forward to "racket2" because I'd like the language to remove struct subtyping. which is essentially a backwards-incompatible change to conventional notions of how first-class values in the Racket runtime work, something that would affect nearly all #langs. I've figured out techniques to work around this in what I'm doing (basically by using struct-like things that aren't quite structs), so I'm not very opinionated about it anymore, but this is the primary example of what I expected racket2 to be about. Many of the things on that page are similar, involving technical changes that more or less can't be achieved without backwards incompatibility.

As much as I find it worrying that racket2 would be kicked off with infix syntax (something which I think of as an unnecessary sticking point in the way of prospective macro writers and language designers, and hence a move *toward* elitism *as opposed to* welcoming everyone), I find it underwhelming that the next breath is "don't worry, we won't change #lang racket," since that dashes many of the reasons to hope for a racket2 in the first place.

- Nia

Stephen De Gabrielle

unread,
Jul 16, 2019, 5:04:56 PM7/16/19
to Gustavo Massaccesi, Arne Babenhauserheide, Christopher Lemmer Webber, Racket Users
Thanks for reminding me of 

As it is mostly quite old, I’ve updated it with a link back to the RFC’s repository.

Kind regards
Stephen
PS see you in London on Friday ;)


For more options, visit https://groups.google.com/d/optout.
--
----

Alexis King

unread,
Jul 16, 2019, 8:18:24 PM7/16/19
to rocketnia, racket...@googlegroups.com
On Jul 16, 2019, at 15:32, rocketnia <rok...@gmail.com> wrote:

I find it worrying that racket2 would be kicked off with infix syntax (something which I think of as an unnecessary sticking point in the way of prospective macro writers and language designers, and hence a move *toward* elitism *as opposed to* welcoming everyone)

I think this fear is natural and understandable, but I want to take a moment and urge everyone to think bigger than that, even if we as programmers are often trained not to. Do not think “because we are moving to a syntax for which macros are harder to express, the language we create will have an inferior or more difficult to use macro system.” If we were setting out to responsibly engineer a new language on a deadline, that thought would be right on the money… but we’re not doing that. Racket is a research language, from an ever-growing community full of very smart people who have produced lots of quite significant research results. They have taken problems that used to seem untenable and made them perfectly achievable (and indeed, often achieved!).

So instead of thinking about all the ways Matthew’s proposed syntax is a compromise that necessarily comes with certain downsides, think of it as a challenge: how do we take all the lovely things we’ve come to enjoy and take for granted in #lang racket and do them in a language with a less regular syntactic structure? How do we make writing great macros as easy in #lang racket2 as it already is in #lang racket? That means figuring out both what the primitives are and what the DSLs look like—syntax/parse did not naturally follow from hygiene and syntax objects, as much as it sometimes feels that way. I am not saying it is easy, and I’m not saying it’s even guaranteed to eventually succeed: perhaps we will fail. But I don’t think we have any reason to suspect we will just yet.

It can’t start by being everything we want it to be, of course; things take time. I just think that thinking about things as such a stark dichotomy is disingenuous and self-defeating. Obviously, we should not aim to become more elitist, on any axes, so let’s aim not to be. This is time for pie-in-the-sky brainstorming, not risk management. Having existing research to build on helps, but even that isn’t required. So although I know firsthand how hard it can be as an software engineer to think about what we want without worrying about how we can build it, let’s be aspirational and exploratory for a bit.

Alexis

P.S. If your qualm with moving from s-expressions is one of aesthetics, not ease or ability, I admit I can’t argue with you there. But I don’t imagine those kinds of discussions are likely to go anywhere productive, anyway—see Wadler’s law.

Greg Hendershott

unread,
Jul 16, 2019, 9:55:09 PM7/16/19
to racket...@googlegroups.com
The stated purpose of this change was to increase Racket's popularity.

Someone asked, if Racket were already more popular, would this proposal
be made? The answer was, probably not.

It seems we're jumping over some questions:

1. More popular, among who?

[About "research language": Is it primarily popularity in "academia",
e.g. see more Racket in classrooms, in papers, and on conference
slides. Or in "industry"? Of course both is nice, but if we ever must
choose one as a priority, which one?]

2. How popular? Are we aiming for as popular as Clojure? Haskell?
Python? Java? JavaScript?

3. What are various possible ways to achieve this popularity, including
-- but not limited to -- changing the surface syntax?

4. Which are most likely to succeed? Which are most likely to backfire?

[Backfire? See e.g. New Coke. Or Lotus 1-2-3 vs. Excel. Also, I have
some experience trying to make software products more popular.
Sometimes successfully. Sometimes not. It's difficult. Most things
you try, don't help. Some hurt. It is pretty typical for e.g.
salespeople to complain, "How can we sell more if we don't add
certain exact features the competition has?". This is the way of
salespeople. ;) Often the features are added, at great effort, and
it turns out not to help at all. Sometimes, it actually alienates
existing customers, who chose you for the distinctive feature the
salespeople wanted killed. No more customers, just worse
word-of-mouth.]

4. Do we have some sense of how to rank them on effort and risk?

5. Given all that, what should we do?


I think it would be a mistake to skip this discussion.

Of course, if the PLT team wants to discuss and decide, privately,
that's their prerogative. In that case I wish they'd share some of the
choices considered and rationale. This would help folks understand who
Racket is intended for, going forward.


-----------------------------------------------------------------

p.s. I am NOT saying the following is what the decision should be. It is
only AN example. I don't even know if it would be my first choice --
because having the discussion is the whole point of figuring that out.
Having said that:

Let's say we wanted to aim (next, for now) for roughly "Clojure" level
of popularity. There are multiple companies using it, jobs, etc. It's
not nearly as popular as Java or Python, which is both good and bad.
Anyway, Clojure is relatively popular, "in spite of" sexprs, at least
partly because it runs on the JVM and JavaScript. As the Racket-on-Chez
effort concludes, and we wonder, what next, maybe a next step would be
to work on other backends, which IIRC was one of the stated benefits of
doing R-on-C.

Again, I'm not saying this is necessarily my preference or "vote". I'm
saying it's an example of a plan that flows from the previous plan.
People can understand why, immediately. It builds on top of Racket's
existing identity and "fan base", and keeps a distinctive feature.


p.p.s. The syntax proposal also seems to muddy the LoP and DSL messsage.
Maybe it's not strictly a contradiction. But it's a little confusing:
"LoP is great! You can choose the best way to express each part of each
program. Now, only some parts of some programs do a lot of math, for
which infix is nice. So guess what? We're going to urge everyone to
switch the default/public/core language to infix syntax. Just please
update documentation and books and tutorials and blog posts and gists
and Stack Exchange and...." So if this proposal indeed goes forward,
there probably needs to be some explainer or FAQ for this.

Greg Hendershott

unread,
Jul 16, 2019, 10:08:10 PM7/16/19
to racket...@googlegroups.com
p.p.p.s or whatever level of "p" I'm on:

The core team including Matthew have put decades of work into Racket.
The effort and dedication is amazing. So if Matthew wanted to decree
that he's been working on this a quarter century and just wants to
change surface syntax, next, dammit? I would have no possible
counter-argument or complaint. Really. I am incredibly grateful for
everything I've been able to learn and do with Racket.

At the same time, this seems like a juncture where Racket has an
opportunity to say who it is for, mostly. That is often a difficult
discussion because you can't be all things to everyone. And people can
feel some anxiety or irritation about change that they may or may not
want. I think the best thing to be done is go ahead and articulate who
Racket is for, people can digest and do whatever they need to do, and
things will eventually sort out fine.

Matthew Flatt

unread,
Jul 16, 2019, 10:40:17 PM7/16/19
to Greg Hendershott, racket...@googlegroups.com
At Tue, 16 Jul 2019 21:55:03 -0400, Greg Hendershott wrote:
> The stated purpose of this change was to increase Racket's popularity.

The purpose I personally stated was to remove an obstacle to Racket
ideas. It's perhaps fair to characterize that as "increase Racket's
popularity", but I'd like to have my specific characterization here for
anyone who might care to draw a distinction.

> Of course, if the PLT team wants to discuss and decide, privately,
> that's their prerogative. In that case I wish they'd share some of the
> choices considered and rationale. This would help folks understand who
> Racket is intended for, going forward.

If any part of the Racket project leadership is discussing this, they
aren't including me, and I wouldn't participate at this point. We are,
however, currently discussing a proposal for a process for community
discussion about what we should do.

The idea that the Racket project leadership is discussing this is
entirely plausible, of course, given the way things have operated in
the past. Let me emphasize again, however, that you should take Aaron
Turon's keynote as evidence that we do not want to do things the same
way this time.


> So if Matthew wanted to decree that he's been working on this a
> quarter century and just wants to change surface syntax, next

Just in case anyone has forgotten, since the live stream was recorded,
I can quote myself verbatim:

I am not standing here today saying this this is the direction we
should go. I want to get the idea out there and start a conversation
about what we should do.


Apologies for answering your message very sparsely, but it's because I
think your message part of a discussion that we should organize in a
different way. Of course, I'm not stopping anyone from posting, anyway.

I regret that I did not understand the importance of setting up a good
forum for discussion before even offering the idea. Live and learn.


Matthew


Hendrik Boom

unread,
Jul 16, 2019, 10:52:27 PM7/16/19
to racket...@googlegroups.com
On Tue, Jul 16, 2019 at 10:08:05PM -0400, Greg Hendershott wrote:
> p.p.p.s or whatever level of "p" I'm on:
>
> The core team including Matthew have put decades of work into Racket.
> The effort and dedication is amazing. So if Matthew wanted to decree
> that he's been working on this a quarter century and just wants to
> change surface syntax, next, dammit? I would have no possible
> counter-argument or complaint.

Especially no complaint if #lang racket remains the language we use now.
We already have another popular surface syntax for racket: Scribble.
No conflict!

-- hendrik

Christopher Lemmer Webber

unread,
Jul 16, 2019, 11:01:39 PM7/16/19
to Matthew Flatt, Greg Hendershott, racket...@googlegroups.com
Matthew Flatt writes:

> The idea that the Racket project leadership is discussing this is
> entirely plausible, of course, given the way things have operated in
> the past. Let me emphasize again, however, that you should take Aaron
> Turon's keynote as evidence that we do not want to do things the same
> way this time.
>
>
>> So if Matthew wanted to decree that he's been working on this a
>> quarter century and just wants to change surface syntax, next
>
> Just in case anyone has forgotten, since the live stream was recorded,
> I can quote myself verbatim:
>
> I am not standing here today saying this this is the direction we
> should go. I want to get the idea out there and start a conversation
> about what we should do.
>
>
> Apologies for answering your message very sparsely, but it's because I
> think your message part of a discussion that we should organize in a
> different way. Of course, I'm not stopping anyone from posting, anyway.
>
> I regret that I did not understand the importance of setting up a good
> forum for discussion before even offering the idea. Live and learn.

Hi Matthew,

Thanks for your response. FWIW I really appreciated Aaron Turon's
keynote and I think it did give good indication that leadership hopes
to involve the community in the process.

In a way, Racket is also uniquely positioned to be able to experiment
here. The #lang aspect of Racket means we can take a "try it before
we buy it" approach, or rather, before we go all in on buying it. I
have been thinking the last few days that this even gives us
flexibility that whatever syntax is decided on could start out as a
"merely surface syntax" approach before moving to "core idioms": we
could try as a community to put that language's syntax on most of the
introductory documents and etc and teach courses with it for a period
before deciding to switch any key semantics, even if any were to
change.

I can't think of any other language environment that has the
opportunity for that level of experimentation, and that seems like a
feature to me.

That said, I do think that all of Greg's comments are useful food for
thought. :)

Greg Hendershott

unread,
Jul 17, 2019, 2:19:03 AM7/17/19
to Matthew Flatt, racket...@googlegroups.com
Thank you for replying.

I didn't mean to suggest I thought these things were already happening.
I don't.

And I'm sorry my attempt to express gratitude by saying you had every
right to decree it, sounded like I thought you actually would do it that
way. I don't.

I (mis?)understood that working groups would be to hash out technical
details -- not to set the basic direction and goals for the whole
project. I've seen that latter kind of discussion can be difficult even
in a small group. So I would understand *if* you decided to do that part
in private. OTOH if you decided to try it in public, that's great, too.

Whatever way the discussion would take place, I was suggesting some
questions to discuss. That's what I was trying to say even if I didn't
write as clearly as I hoped.

rocketnia

unread,
Jul 17, 2019, 12:32:21 PM7/17/19
to Racket Users


On Tuesday, July 16, 2019 at 5:18:24 PM UTC-7, Alexis King wrote:
So instead of thinking about all the ways Matthew’s proposed syntax is a compromise that necessarily comes with certain downsides, think of it as a challenge: how do we take all the lovely things we’ve come to enjoy and take for granted in #lang racket and do them in a language with a less regular syntactic structure? How do we make writing great macros as easy in #lang racket2 as it already is in #lang racket?

I know parts of this are sort of a response to the group, but I appreciate you reminding me of the pie-in-the-sky aspect. I've long wanted to see some more comprehensive reforms of the core language, and I'm excited about some of the other topics being surfaced in the RFCs repo issues. It would be so good if more Racket #langs could intermix, and how better to do that than to have a single language where even infix syntaxes are convenient to access?

It's just that the usual kind of wish list I have for Racket is for it to get a more regular syntactic structure. So many things in Racket are ad hoc groupings of parentheses, keywords, and DSL-specific mixfix syntaxes, when I believe having prefix syntax in their place would be slightly more conducive to people who need to recreate big chunks of the language. The harder it is to recreate the language, the more it's like a building with no fire exits. Eventually some leadership (if not today's leadership, then someday's) will make some mistake or some harmful decision, and the users will have to scramble out of a two-story window with whatever codebases they can gather.

Will there be a particular catastrophic inflection point like that someday? Maybe, I dunno. I think it's more of a long-running catastrophe that isn't evenly distributed, and we're the survivors. Will prefix really help that much? ... I don't know. It was my "Hey, I can build that!" entrypoint into writing my first several languages, I've seen it serve the same role for many people, and it's now my refuge from all the mountains of parentheses in my CPS JS code. Among those other experiences, the Sofware Freedom Conservancy talk has led me to think that it's not just me who finds it seriously important that Racket has inspired and equipped people to make their first several languages. But I don't really know beyond a rule of thumb.

Regardless, this one change to Racket isn't really inviting catastrophe all by itself. I use Racket precisely because it's the most exitable language I know. It has oodles of extension points, it's open source, there are established ways to compile Racket to alternative languages when the need arises, there are even paths to port code to other languages without even leaving behind Racket compatibility... It's good stuff. Racket isn't a building with no exit doors, just a building where one of the most prominent doors is being converted to a fancy automatic door and I'm fretting about whether it's the kind of door that can be pushed open in case the mechanism isn't working. :-p

Again, yes, thank you for reminding me that there are a lot more exciting improvements on the table than just this, and that this is quite an opportunity. Something I'm looking forward to is that if this opportunity is played well -- yes even this infix syntax opportunity -- it's a chance to bring together a lot of the community's fantastic developments into a single well-polished combination. :)

-Nia

Brian Adkins

unread,
Jul 17, 2019, 12:33:20 PM7/17/19
to Racket Users
Some great points Alexis.

I should've learned by now to be wary of my knee-jerk reactions :) My initial reaction to the idea that Racket2 *might* have an infix syntax was to feel quite unsettled! To be clear, I like the idea of Racket2 being able to break backward compatibility if it makes it easier to move forward, but adding syntax seems to create an identity crisis for a lisp. Sweeping syntax changes for a language that already has syntax is one thing, but introducing syntax to a lisp is on another level IMO.

After a ten year search for a new programming language (ending Nov 2018), in which I heavily weighted both effectiveness/productivity & joy in programming, I chose Racket. In my 8 months of full time Racket development, I don't think a week has gone by where I haven't been pleasantly surprised by something in Racket. Racket School just piled on many more reasons why I was thrilled to be able to program in Racket full time. So the timing of the proposal, from a purely *personal* perspective, was poor - from the peak of (possibly) inflated expectations, to the trough of disillusionment!

I suppose it's possible that my love for parens came primarily from seeing that s-expressions made code transformations easier for me (although, I also like other aspects of essentially working with an abstract syntax tree). And I admit a weakness in being able to imagine a combination of infix syntax w/ a new macro system that's as nice to use as the current Racket way. I do remember liking Haskell's syntax when I spent time with it during my search, and I *think* I recall feeling that I missed some things (e.g. list comprehensions) about that syntax when I chose Racket, but that what the parens allowed for was worth it, so *maybe* if we come up with an elegant syntax that was no more difficult for language extension than what we have now, I might like it.

At this point, I'm a little less unsettled about a possible new syntax. I (naively?) think the Racket core team & wider community probably have a fairly large intersection of shared aesthetics that values elegance, expressive power, conciseness, ease of language extension, etc. I lean strongly toward minimalism, and, as an example, despite Haskell being a huge language from one perspective, it does allow for elegant and concise code.

I'm skeptical of the value of an infix syntax for reaching the stated goal, but as a newcomer, I feel that the folks who have invested years of their lives in developing Racket should certainly feel free to ask, and try to answer, the question.

Having said that, I can almost assure you that if this current discussion was happening when I was considering Racket initially, I would not have felt comfortable choosing it (possibly for irrational reasons), and I think it's clear that this type of change will result in both the loss of existing users and the gain of new users, and it's not at all clear to me which will be greater.

However, I can't *unsee* what I've seen with language oriented programming (and the downsides to running on the JVM are too great ;), so I'm happily "stuck" for the time being :)

Brian Adkins
Message has been deleted

Mário Guimarães

unread,
Jul 17, 2019, 7:54:28 PM7/17/19
to Racket Users
Hello, community!

Let me tell a few words about the idea of transitioning Racket to a traditional syntax to gain popularity: I think this idea is a fallacy. Racket is not popular due to its s-expression syntax, because Clojure has such a syntax, and still, it seems popular. So I don't think such step will raise the adoption of Racket.

There is nothing new in having a traditional syntax language with Lisp-like macros. There is one, it's Elixir. Note that I have lots of experience writing complex macros in Elixir, and I expect writing macros in an s-expression language to be much easier, simply because in such a language, its notation and its AST are isomorphic, i.e., they share the same syntax. Let me explain this: in Elixir, sometimes, the way to verify if a macro generates the code we want, is to see what this code's AST looks like, which in Elixir is a kind of s-expression (yes!), and from this, infer how to build the AST inside the macro using the Elixir notation; this effort is totally unnecessary in languages in which the notation and the AST are the same thing.

In short: Clojure is a popular s-expression language on the JVM, and Elixir is a popular Lisp-2 language on the ErlangVM, consequently, the `Racket 2` language will contribute nothing to Racket's wide adoption. In fact, I think it will be a strategic mistake, if popularity is all about. 

Does Racket wants to be popular in the industry? Then Racket must focus on being a language-oriented programming ecosystem on a popular VM, like the ErlangVM, the JVM, and the WebAssemblyVM. This means to stop working on the RacketVM, if there's such a thing, and to start moving Racket's language-oriented programming features into these popular VMs. I don't think that having a kind of Elixir++ on an unpopular VM, will make the industry adopt such a language.

For example, I would love to see Racket become a statically typed Lisp-like language-oriented programming ecosystem on the Erlang VM. I am sure if this ever happens, there will be hordes of programmers jumping immediately into such ecosystem. (Ehh, I think the Shen language is the closest thing there is, but oh my, nothing can have a more terrible marketing strategy than that of Shen).

To conclude, I wish a great future to Racket, and will continue following its future development. Ah, I like the Hackett idea also, very very interesting, and promising direction, but again it needs to target a popular VM.

Cheers,
Mário Guimarães

Hendrik Boom

unread,
Jul 17, 2019, 9:50:24 PM7/17/19
to Racket Users
On Wed, Jul 17, 2019 at 04:52:37PM -0700, Maria Gabriela Guimarães wrote:
>
> Does Racket wants to be popular in the industry? Then Racket must focus on
> being a language-oriented programming ecosystem on a popular VM, like the
> ErlangVM, the JVM, and the WebAssemblyVM. This means to stop working on the
> RacketVM, if there's such a thing, and to start moving Racket's
> language-oriented programming features into these popular VMs.

There may be performance advantages to the Racket VM, so I wouldn't
stop developing it. But adding those other popular VMs may well be a
win.

-- hendrik

Christopher Lemmer Webber

unread,
Jul 17, 2019, 9:55:51 PM7/17/19
to Hendrik Boom, Racket Users
The work that Matthew Flatt is doing on Racket-on-Chez should be opening
up the possibility of running Racket on multiple other foundations, is
my understanding from conversations in the past. So I don't think we
need to pivot, since opening up the possibility for this is already on
track.

Daniel Prager

unread,
Jul 17, 2019, 11:50:30 PM7/17/19
to Matthew Flatt, Racket Users
I'm confused on one point.

Why would a new canonical notation be preferable to, say, also fully supporting an alternative general notation (like Shriram's p4p, or a derivative thereof) or even multiple notations in addition to retaining good old s-expressions?

The idea would be that you could transform freely and readably between alternative notations, enabling round-tripping without degradation.

I imagine that effectively providing tooling, syntax-extension, good error messages, and documentation across multiple notations would be (ahem) challenging, but so long as we're dreaming big ...


Dan

David Storrs

unread,
Jul 18, 2019, 1:46:47 AM7/18/19
to Daniel Prager, Matthew Flatt, Racket Users
Two things that I would like to see in Racket2 would be return values being standard practice and the ability to return nothing.

Racket has a lot of functions that return #<void>; that's not helpful.  In almost every case, there is a sensible thing to return and it would be better to return it -- for example, when you set something, return it.  It doesn't need to change any existing code, since the existing code ignores the return value.  Likewise, no one has to worry about remembering exactly what it is that gets returned; just ignore the return value like you're already doing.

The other thing I'd like to see would be the option to return nothing.  Not #<void>, '(), or #f.  Nothing.  It's useful e.g. when you want to simultaneously transform and filter a list.

--
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.

Sorawee Porncharoenwase

unread,
Jul 18, 2019, 2:16:37 AM7/18/19
to David Storrs, Daniel Prager, Matthew Flatt, Racket Users
The other thing I'd like to see would be the option to return nothing.  Not #<void>, '(), or #f.  Nothing.  It's useful e.g. when you want to simultaneously transform and filter a list.

Would (values) satisfy your criteria?

#lang racket

(define (my-filter-map proc xs)
  (match xs
    ['() '()]
    [(cons x xs)
     (call-with-values
      (thunk (proc x))
      (case-lambda
        [() (my-filter-map proc xs)]
        [(x) (cons x (my-filter-map proc xs))]))]))

(my-filter-map (λ (x) (if (odd? x) (values) (add1 x))) '(1 2 3 4)) ;=> '(3 5)

One thing I don’t like about it is that zero values (and multiple values in general) are really unwieldy to work with and doesn’t compose well with the rest of Racket. You can for example translate v >>= f in Haskell to just (and v (f v)) in Racket. But trying to do the same thing with zero values is a headache.


On Wed, Jul 17, 2019 at 11:50 PM Daniel Prager <daniel....@gmail.com> wrote:
I'm confused on one point.

Why would a new canonical notation be preferable to, say, also fully supporting an alternative general notation (like Shriram's p4p, or a derivative thereof) or even multiple notations in addition to retaining good old s-expressions?

The idea would be that you could transform freely and readably between alternative notations, enabling round-tripping without degradation.

I imagine that effectively providing tooling, syntax-extension, good error messages, and documentation across multiple notations would be (ahem) challenging, but so long as we're dreaming big ...


Dan

--
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/CAFKxZVV-njHNCCLDP-RsDq%2BjbXrOGpOnaEp9Ob4ugTbdtmckAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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.

Tom Gillespie

unread,
Jul 18, 2019, 4:09:34 AM7/18/19
to Sorawee Porncharoenwase, David Storrs, Daniel Prager, Matthew Flatt, Racket Users
I was going to mention that common lisp has a notion of return arity, and that certain functions can return zero results. I didn't realize that (values) also worked in racket. Zero return arity has some nasty consquences in existing systems. Both racket and guile barf on expressions like (eq? (values) (values)) and like NaN results with zero arity should probably always not be equal. Without having any idea of the actual state of the art, I would guess that type systems can handle zero arity returns but would guess that there may be some implementation overhead. This seems related to the question: How do you detect that 'nothing' has happened (re: to why do analog clocks start at 12)? Unlike nearly every other language I have ever encountered Racket supports pretty much all of the possible solutions, with (values), (void), and (null)/'(). In principle this means that we can choose whichever solution works best for our use case, but leaves open the question of how the default choice of (void) as well as the diversity of options impacts code quality, readability, and terseness. I'm sure someone has done a study on that but a quick search produced nothing obvious. I also expect that some of the long time members of the community could also provide some insight into the design decisions to include an explicit representation of void in the language (seems to have happened some time back in 2005). If I had to guess, having an explicit representation makes the language more homogeneous since you aren't forced to check whether a result has zero return values every single time but instead can simply check whether the value returned is void (in a strict sense it is impossible to test the equality of something with nothing, in line with the NaN example before -- there isn't even a register with a value in it for (values)). Would love to hear from those with more knowledge of the history here.
Tom


James Platt

unread,
Jul 18, 2019, 11:52:30 AM7/18/19
to Racket Users
Like others have said, I'm not sure that syntax is really the issue with Racket adoption. For me, the difficulty in moving to Racket from other languages is not the syntax, it's other things. Lot's of parentheses don't bother me. Writing (2 + 2) as (+ 2 2) is a little weird but It's not going to stop me from using Racket. Maybe there are other examples of infix notation where it really helps for the syntax to be more like natural language but I can't think of an example right now.

One issue is that Racket is documentation assumes more of a computer science background than I have. My single biggest suggestion in this regard is to use examples... lots of examples. The documentation shows you the syntax but that's not the same thing as understanding how something actually works or where it fits in with other elements of the base language.

Also related to the background of the users is, for example, the family of functions including car, cdr, caar, cddadr, etc.. I puzzled over the question of why these functions even exist for quite a while. I had never heard of this way of doing things before. As I understand it, these functions are basically around for historical reasons. There is no compelling need for me to learn them for the purpose of writing my own code and so I haven't been using them. It's only a matter for understanding other people's code. During Racket Week and Racketcon, when I saw these functions being used, I understood to the point of realizing that the point was to pull a value out of whatever they were used on. I couldn't tell you which value.

There has to be some compromise between having flexibility to do things lots of different ways and having limits to what a programmer needs to know to read other people's code. I have had the experience of writing a Perl script and then looking at some one else's Perl script, which does the exact same thing, and not being able to make head nor tail of it. AppleScript is much more limited and easier to understand. Part of that is just the limited scope of the language but they also have the philosophy that it is more important to make code easy to read than easy to write. I agree with that decision a lot of the time. R seems to me to strike a pretty good middle ground position in this area.

A phrase which came up several times during Racket Week and Racketcon was "...a trap for the unwary." There seem to be a lot of these in Racket. I'm already pushing the TL;DR boundary pretty hard so I'll just suggest looking at the video and seeing where these this phase came up and whether there are any general categories of problems where something can be done.

Hendrik Boom

unread,
Jul 18, 2019, 1:15:07 PM7/18/19
to Racket Users
On Thu, Jul 18, 2019 at 11:52:24AM -0400, James Platt wrote:
>
> Also related to the background of the users is, for example, the
> family of functions including car, cdr, caar, cddadr, etc.. I
> puzzled over the question of why these functions even exist for quite
> a while. I had never heard of this way of doing things before. As I
> understand it, these functions are basically around for historical
> reasons. There is no compelling need for me to learn them for the
> purpose of writing my own code and so I haven't been using them.
> It's only a matter for understanding other people's code. During
> Racket Week and Racketcon, when I saw these functions being used, I
> understood to the point of realizing that the point was to pull a
> value out of whatever they were used on. I couldn't tell you which
> value.

I still use the car/cdr congomerations. They are quite useful when
parsing a list.

-- hendrik

Hendrik Boom

unread,
Jul 18, 2019, 1:20:17 PM7/18/19
to Racket Users
On Thu, Jul 18, 2019 at 01:47:53AM -0400, David Storrs wrote:
> Two things that I would like to see in Racket2 would be return values being
> standard practice and the ability to return nothing.

It would be useful in typed racket to have a type that indicates that
the expression never returns a value.

-- hendrik

Brian Adkins

unread,
Jul 18, 2019, 1:48:12 PM7/18/19
to Racket Users
One thing that's still bothering me is the admission that if Racket
was already popular enough we wouldn't be considering the syntax
change. This was an answer to a question in a live setting, and I am
prone to mis-interpreting/understanding, so I very much want to cut
Matthew some slack since he only had a few seconds to reply.

I feel framing the purpose (i.e. primarily to gain more users) of
Racket2 in this manner is problematic. One reason is that the ultimate
end (without some arbitrary limit) seems like it would have to be
similar to existing popular languages since that's clearly what more
programmers want - exactly how popular do we want to be? Another is
that it feels like a marketing driven effort vs. an engineering driven
effort i.e. prioritizing psychological appeasement over technical
excellence. I believe marketing is important, but I prioritize it
below technical excellence in this context.

My vague understanding of the idea of Racket2 (prior to Sunday) was
that it was a chance to make changes based on decades of learning by
allowing backward compatibility to be broken if it made the resulting
language better. After Sunday, I was left with the feeling that the
Racket developers were considering a huge & risky undertaking in which
the end result may not be better (objectively) than the current
language with the hope that people who rejected Racket previously will
now respect us for bending over backward to accommodate them, and join
us. I think it would be difficult for me to respect a programming
language community that invested such a huge effort for a lateral
move.

I think more people (both existing users and new users) could get
excited about Racket2 if it was primarily about making Racket
objectively better and only secondarily about overcoming the
aesthetic objection to parens. The message of "After years of effort,
now you can program in Racket without using so many parens!" does not
seem compelling to me.

My hope is that the primary goal of Racket2 is to provide objective
improvements to the language, and that a secondary goal of
attracting more users helps in deciding between similar means of
accomplishing the primary goal.

If the primary goal of Racket2 truly is to attract more programmers to Racket,
I think it would be valuable to take a step back and consider various
means to that end. While syntax may be important in accomplishing that
goal, I don't think it's clear that it's the most important.

Maybe the core team can take some time and clearly articulate the
goal(s) for Racket2 from which everything else flows?



Matthew Flatt

unread,
Jul 18, 2019, 2:56:28 PM7/18/19
to Brian Adkins, Racket Users
At Thu, 18 Jul 2019 10:48:11 -0700 (PDT), Brian Adkins wrote:
> One thing that's still bothering me is the admission that if Racket
> was already popular enough we wouldn't be considering the syntax
> change. This was an answer to a question in a live setting, and I am
> prone to mis-interpreting/understanding, so I very much want to cut
> Matthew some slack since he only had a few seconds to reply.

Indeed, I would not have intended to answer simply "yes" to the
question "would you stay with the same syntax if Racket were already
popular enough?".

> Maybe the core team can take some time and clearly articulate the
> goal(s) for Racket2 from which everything else flows?

Working on it.

Justin Zamora

unread,
Jul 18, 2019, 3:47:51 PM7/18/19
to Brian Adkins, Racket Users
On Thu, Jul 18, 2019 at 1:48 PM Brian Adkins <lojic...@gmail.com> wrote:
> I think more people (both existing users and new users) could get
> excited about Racket2 if it was primarily about making Racket
> objectively better and only secondarily about overcoming the
> aesthetic objection to parens. The message of "After years of effort,
> now you can program in Racket without using so many parens!" does not
> seem compelling to me.

The discussions about changing syntax are not about aesthetics. There are some
genuine pain points in Racket th