The case, and a proposal, for elegant syntax in #lang racket2
6,437 views
Skip to first unread message
Christopher Lemmer Webber
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
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
Jul 14, 2019, 1:53:06 PM7/14/19
to Racket Users, Arne Babenhauserheide
Matthew Flatt
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
> The context of this email is the proposal by Matthew Flatt that we move
> to an easier-to-accept surface syntax for #lang racket2.
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
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
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
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...
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.
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.
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.
language. Do we really need another Python?
--
Jack M. Rosenthal
http://jack.rosenth.al
That code? Must have been the last guy...
Hendrik Boom
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
>
> 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.
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
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++
> 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.
;)
Computers were a mistake.
-- Ethan Hunter
Hendrik Boom
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.
> 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++
p++^ or p^++
p[1]^ or p^[1]
Of course in C we'd then need a new symbol for xor.
-- hendrik
Hendrik Boom
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
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
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.
;; - - -
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
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.
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
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
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
> 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.
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.
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
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
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
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
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
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.
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
Jul 15, 2019, 2:34:31 PM7/15/19
to Racket Users
Wesley Kerfoot wrote on 7/15/19 2:28 PM:
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.
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
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/87B3D875-42D4-4951-B08D-96BF28468EF8%40felleisen.org.
Matthew Butterick
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
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/B7391FF7-FDE7-42A5-921D-BA9B78B463C9%40felleisen.org.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/B7391FF7-FDE7-42A5-921D-BA9B78B463C9%40felleisen.org.
Hendrik Boom
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?
>
> 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 ':'?
> 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.
Are there any other characters that are still free?
-- hendrik
Maciek Godek
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
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
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
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.
> 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.
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
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/c6319b95-b166-e29b-9d0d-2f1f2a3bd774%40fastmail.net.
Konrad Hinsen
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
> 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?
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
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/87wogkqzo0.fsf%40dustycloud.org.
rocketnia
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
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 ;)
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAPaha9Nr9V38bXLbq%3DDf8195ur2udyk0WzWS-OjMpFgh8Vdb%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
----
Alexis King
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
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
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