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

[Christopher Lemmer Webber]

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]

I sent this about 5 minutes before Jay announced
https://github.com/racket/racket2-rfcs :)

[Matthew Flatt]

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]

(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]

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):

http://breuleux.net/blog/liso.html

[Jack Rosenthal]

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

[Hendrik Boom]

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]

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

[Hendrik Boom]

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]

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]

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

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]

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]

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]

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]

Hazards of reading email from the top down: Apparently there is a commitment to keeping #lang racket working. Phew! Thank you, core team!

[Neil Van Dyke]

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]

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]

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]

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]

[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?

[1] https://youtu.be/xSjk2PdQm5k?t=17682

[2] https://sfconservancy.org/projects/apply/ConservancyFSATemplate.pdf

[Sam Tobin-Hochstadt]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Thanks for reminding me of 

https://github.com/racket/racket/wiki/Racket2

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Mário Guimarães]

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]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAFKxZVV-njHNCCLDP-RsDq%2BjbXrOGpOnaEp9Ob4ugTbdtmckAw%40mail.gmail.com.

[Sorawee Porncharoenwase]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKodKrWNeL3tJQ5uO4X64jKzBVmYY2P9BgLsd%3Dqh8bhSQyw%40mail.gmail.com.

[Tom Gillespie]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CADcueguTp19B7Yqb9nZM%3DJfiofWU4-JBdC-aaoFXq4vthUe3NQ%40mail.gmail.com.

[James Platt]

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]

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]

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]

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]

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]

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 that could be fixed with alternate
syntax. For instance,
it's easy for structure and array access to become unwieldy in
practice. Even a simple
example can show how awkward it can be. Suppose you have:

(struct person (first middle last))
(define john (person "John" "Allen" "Smith"))

Now you want the person's initials. In Racket, the code is:

(string (string-ref (person-first john) 0)
(string-ref (person-middle john) 0)
(string-ref (person-last john) 0))

There's a load of cognitive and syntactic overhead compared to something like:

john.first[0] + john.middle[0] + john.last[0]

Even as someone who has programmed in Scheme for 30 years, I have to spend
a couple seconds to grasp what the Racket code is doing, while the alternative
syntax is almost instantly understandable.

Making changes to eliminate such pain points may help new users to
consider Racket,
but even if they don't, there is still plenty of benefit to existing
Racket programmers.

Justin

[Brian Adkins]

You bring up an excellent point, but it does seem to beg the question of why use Scheme given there are numerous other languages with a similar syntax to what you described?

I'm not trying to be argumentative - as a relatively new lisper, it was my understanding that while adding some verbosity, s-expressions enabled macro writing, and in turn, macros can eliminate some of the "cognitive and syntactic overhead". Also, "cognitive and syntactic overhead" may be somewhat subjective (ever waste time looking up operator precedence?), for example, I like the ubiquity of the pattern (operator operand1 operand2 ...) - it's simple to understand vs. many, context-sensitive constructs.

If it weren't for the promised value of language extension functionality provided by Racket, I *may* have been satisfied with a strict, dynamically typed version of Haskell :)  However, I'm not really sure about that - I think I weight simplicity & orthogonality *much* more than most programmers, so Scheme makes me happy. I think I would rather "clean up" your Racket example with syntax extension than use infix expressions with dot and [ ] operators, but that's just due to my subjective, aesthetic preferences.

We all have a unique perspective on what makes code beautiful; I'll keep an open mind that Racket2 may allow me to continue to write beautiful code.

[Robert R.]

On Thursday, July 18, 2019 at 3:47:51 PM UTC-4, Justin Zamora wrote:

(string (string-ref (person-first john) 0)
        (string-ref (person-middle john) 0)
        (string-ref (person-last john) 0))

There's a load of cognitive and syntactic overhead compared to something like:

john.first[0] + john.middle[0] + john.last[0]

The issue there is imo, insufficient abstraction. There is a tendency (this happens often in JS) to code at a very low level when you are given neat tricks like this. Alternatively, (not that I'm saying structs are perfect or this is the best way to go), given your example, I would do something like this:

(define (get-initial str)
  (string-ref str 0))

(define (first-initial person)
  (get-initial (person-first person)))
(define (middle-initial person)
  (get-initial (person-middle person)))
(define (last-initial person)
  (get-initial (person-last person)))

(define (get-initials person)
  (string
   (first-initial person)
   (middle-initial person)
   (last-initial person)))

Then you are just looking at (get-initials john), which is the simplest to read.

As a relatively new programmer myself (1 year experience so far) I admit that my first thought on hearing about the syntax change was disappointment. Although getting through HtDP wasn't easy (I read it 3 times!), it was love at first sight for me. Rather than memorizing precedence rules, or parens wrapping out of caution, everything was immediately clear for me. I think that many people are trained to believe "this is the way to program", based on whatever they were taught in school or what they encountered first, leading to a familiarity bias. (I am self-taught + a bootcamp graduate) Many people wanted to stay with assembly (because that's what they knew) when higher level languages like C came about, and the same thing happened again with the newer dynamic languages. Many systems programmers still refer to languages like JavaScript as "scripting" languages in a rather dismissive way, because they are very different from what they are used to. (not as strongly typed for one)

On the plus side, we've seen lots of higher level features filter down too, like pattern matching in Rust, and first class or nameless functions becoming a standard expected by programmers. Maybe the change to lisp is just too different from what most people are taught, but I'm not sure a syntax change will improve the situation. One obvious question I have would be, if Racket is changed to resemble something closer to, say, Python, why would people want to switch? They already have a familiar syntax and lots of libraries, and the draw of a "programmable programming language" is not high for people looking at just getting a project done. (I think those types are the ones unsatisfied with existing tools, and are looking for something better) I think a much bigger factor in adoption of a language has to do with industry applicability, just plain practical need, and some kind of compatibility with what is already available. Clojure is a good example imo. Although on the other hand, sometimes surprises can be good, so there is no criticism from me. I will certainly miss it if the change does go through.

One last point I wanted to add is that while leaving the current Racket around for compatibility is nice, it is no comfort for people who enjoy the style. The default choice is the one that people tend to use, which is why when I found out about class syntax for JavaScript, I was completely opposed. It seems like a nice sugar for Java/C developers, but JS is a different beast and doesn't actually have them, leading to all sorts of problems. Since it is a very familiar style though, and officially blessed by the standards people, it is the dominant form, as opposed to the superior (imo) and truer direct object linking (Object.create() or simple object literal returns from a "constructor"). Anyway I'm rambling now. I'd certainly like to see what ideas people come up with.

[Benjamin Slade]

To add another perspective of a relative new-comer to Racket, I became
interested in Racket because it was clearly a lisp, with sexps &c. When
I was shopping around for a reasonable modern lisp to develop things in,
Racket being clearly recognisable syntactically as a lisp was a definite
pro for me – and an encouragement for adoption – rather than an
obstacle. I strongly suspect that had I come across Racket as a lisp
with a very un-lisp-like syntax, I would have passed quickly on to
considering other options.

For me, a major attraction of Racket over other options was a clear path
for making cross-platform GUI applications, which is something that
seems rather tricky in other lisps (I spent a good bit of time looking
at options for cross-platform GUIs with Common Lisp, where Qtools seems
to be the best option, but it is much more complicated than the built-in
functionality in Racket).

(For `car`, `cdr`, `cons` - again, these are basic small pieces of lisp
and I would be disconcerted not to find them in the standard language. I
think they're very useful for 'low-level' things; `first`, `rest` could
be promoted as the 'standards' for higher level list interactions,
perhaps usefully also for people familiar with Clojure.)

--
Benjamin Slade - https://babbagefiles.xyz

[Jesse Alama]

On 18 Jul 2019, at 19:15, Hendrik Boom wrote:

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

I think I know what you mean. I used to do that, too, till I discovered
match (https://docs.racket-lang.org/reference/match.html). That can save
you a lot of code that's essentially: "if the cadaadr is this, then do
that, but if the cdddadr looks like this, do that instead".

[Robert R.]

Let me revise what I said actually, in the spirit of optimism. If an alternate syntax is considered, one thing I would suggest that is somewhat in line with Justin, is something like “visually structured data”.

I think as humans we prefer to see things and have them be simple and interesting, and text is less simple to process and less interesting than a few powerful symbols.

So something like a list, ex. ‘(1 2 3), is very appealing to us. Doubly so when you can do things like quasiquote/unquote, or unquote splicing, but without the keywords. ex. `(1 ,var 4) In Lisp, we only seem to do this with lists.

In JavaScript, we went from arr.concat(arr2) to [...arr, ...arr2]. The latter form is very elegant and pleasant to look at, with less cognitive load. (You read it as, make a new array, and then dump the contents of arr and then arr2 into it) No longer is there any thought about what is getting concatenated with what, or whether concat is an array or a string operation.

The same could be said about object/hash table syntax. ex. { age: 5, name: “ashley” }. This led to similar shortcut forms like { age, name }, for taking two variables and putting them into a new object along with their values, or using the same spread operator to concisely move data from one object to another. Being able to put expressions in any of these, including strings, is also very powerful. ex `Hello ${name}`

Clojure has adopted a similar literal for hash tables: { :age 24, :name “steve” }

I can concur that these are nicer than nesting commands like (make-hash) and (set-hash blah blah blah), because they are easier to visualize, and because you feel like you are working with the structure directly as opposed to interfacing with it from a distance using a command.

I think this explains why people like overloading the plus operator for string concatenation over using a string append function, or array indexing, even into a string.

Whatever form a Racket2 might take, I hope it embodies a similar elegance and simplicity. (and expressive power)

[Tom Gillespie]

Apologies for the long mail. I wanted to get
these thoughts out now while they are fresh.
Tom

Can Racket make semantics a matter of syntax?
If it can, can it produce errors when certain
syntactic forms are incompatible with the
specified semantics? Can all forms in the
language be mapped to all runtime features
such that each form can be marked as compatible
or incompatible with each feature?

#+proper-tail-calls
#+continuations
#+delimited-contiuations
#+unwind-protect
#+strong-static-types
#+event-loop
#+interpreted-same-as-compiled
#+jit
#+c-preprocessor-style-macros

I was revisiting slib today.
I tried to port it about 3 years ago, and had had no success.

Does LOP work?
This is an academic question.
Can we convince new, untrained folk, to use LOP?
This is a promulgation question.

I think that one powerful argument in favor of LOP would be to use
the Racket ecosystem to implement and support the entire history of
scheme programs.

This demonstration would be a feat that to my knowledge no other programming
environment has ever been able to achieve.

Schemes are notorious for their ... creative extension of standards.
If Racket can demonstrate and provide a practical solution for taking
random scheme code (e.g. by adding #lang r4rs as the first line of a file),
and having the semantics just work, then that would be game changing
beyond the wildest dreams of even the most cynical academics. This
couldn't happen without a monumental effort to provide facilities for
capturing language semantics in a meaningful way beyond simple syntax.

This thread started as syntax, but the quote from Matthias during
the introduction to Racket School seems quite relevant. The real
prize here is not in creating the greatest syntax ever known to humanity [0]
but in the mapping between syntax and semantics. Of the many goals that
Racket2 could pursue, this seems like the one that could have the most
lasting impact. Leave the syntax to #lang algo-me-harder. Syntax can
devolve in a political issue, and in the happy realm of Turing completeness
everyone can have whatever they want as far as syntax is concerned.
You can have all the unicode delimiters you want, I just need my λ.
The real challenge (it seems) is to provide a tool that makes it
possible to translate the semantics of one language to another in
a way that is consistent, understandable, and ideally, performant.
(If it is not performant, then an even greater prize would be to
be able to show which syntactic feature was missing performant
semantic support in the offending runtime.)

It seems to me that Matthew has paved the way for this. The differences in
semantics between Chez Scheme and Racket and Matthew's solutions provide
solid examples for future semantic extensions to Racket. They also provide
a taxonomy of the kinds of changes that would need to be made other runtimes
to support a performant implementation of Racket's syntax.

I can appreciate why Matthew might like to consider alternate direction
after having spent the last 2 years working on performance optimizations
and semantics translation. However, I wonder whether the knowledge gained
as a result is equally valuable. Could it be implemented into Racket
itself? Said another way, can we have #lang common-lisp with all the
syntax, working as a Lisp-2, and have a performant implementation of
unwind-protect that can be used in `#lang r4rs with-extended-semantics`?
Even if we couldn't do this, could Racket be the place where we can
prove (by virtue of the machinery that it provides) that continuations
and unwind-protect are incompatible at a fundamental level? Matthew's
work also means that a solution to this problem might also look like
a page in the documentation which provides a comprehensive overview of
which runtimes provide performant and correct implementations of certain
language features, allowing users to choose their runtime to fit their
needs.

From a practical standpoint, writing new code almost seems silly when
you can burgle libraries that have had man centuries of development
put into them by writing the translation layer for the semantics --
especially if we get Racket's support for locating bugs by way of syntax
objects.

This vision for Racket2 is beyond pie in the sky, and perhaps a departure
for the usual vision for LOP, but I wonder whether Racket is now ideally
poised to act as the bridge for the infinite and as yet unimagined syntaxes
of the future and the enormous variety of existing runtimes.

I consider it a mark of the maturity of the community that leadership is
planning how to manage the community politics around the next phase of
the language, well in advance of any transition. However, I can't help
but wonder whether there are goals that we all agree on that would avoid
the need for a political process altogether. Maybe the objective of the
political process should be just that -- to find a direction which obviates
the need for said process.

---

[0] The idea that there can be "One syntax to rule them all" seems a
fundamental fallacy to me. Human brains are different. They prefer
different things for structural genetic reasons, as well as for reasons
of habit and familiarity. Trying to optimize for a single most-appealing
form will always alienate someone. Of all the languages out there, Racket
and LOP seem ideally poised to achieve such an individual fit [1].
[1] https://www.thestar.com/news/insight/2016/01/16/when-us-air-force-discovered-the-flaw-of-averages.html

---

On a completely unrelated note: while we are thinking about the future,
an industrial strength package manager could be a huge boon. Obstacles to
ideas come in many forms, and over time I have found that running the first
hello world program on a system can be on of the hardest and most time
consuming challenges. Reducing the friction all around the ecosystem
seems like it might have the same kind of effect of making any tiny micro
optimizations in a compiler. Individually they don't seem to make any
difference, but together they are revolutionary.

[Brian Adkins]

This may seem like a nitpick, but I think there would be a *huge* shift in attitudes if the suggestion for an infix syntax was framed in a similar manner to Typed Racket as opposed to Racket 2. The latter seems to imply a premature conclusion, where the former proposes a question to be answered by the community i.e. if people do flock to #lang infix, then the people will have spoken. Let #lang infix win by merit, not by decree!

Required re-reading: "The Evolution of Lisp" https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf

Thanks to @rplevy for the reminder of that paper.

Brian

[Hendrik Boom]

On Fri, Jul 19, 2019 at 08:54:41AM -0700, Brian Adkins wrote:
> This may seem like a nitpick, but I think there would be a *huge* shift in
> attitudes if the suggestion for an infix syntax was framed in a similar
> manner to Typed Racket as opposed to Racket 2. The latter seems to imply a
> premature conclusion, where the former proposes a question to be answered
> by the community i.e. if people do flock to #lang infix, then the people
> will have spoken. Let #lang infix win by merit, not by decree!

And, presumaby we'll also get #lang typed-infix

>
> Required re-reading: "The Evolution of Lisp"
> https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf

-- hendrik

[Matthew Flatt]

At Tue, 16 Jul 2019 21:55:03 -0400, Greg Hendershott wrote:
> [...]
> I think it would be a mistake to skip this discussion.

Agreed, so I'll offer my take on these specific questions, at least if
you'll humor my read of "more popular" as "lower barrier".

At Tue, 16 Jul 2019 21:55:03 -0400, Greg Hendershott wrote:
> 1. More popular, among who?

I think we should be aiming for programmers generally. Some of those
programmers will still be in school, but I haven't noticed a huge
difference in the way students approach things and the way practicing
programmers do.

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

I'll skip this one, because I don't see how to read it as "lower
barriers".

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

Other ways I see to lower barriers are more documentation, running on
more platforms/VMs (as also suggested in this thread), and improved
tools.

> 4. Which are most likely to succeed? Which are most likely to backfire?
> [...]
> 4. Do we have some sense of how to rank them on effort and risk?

Changing the surface syntax seems on the high-effort --- high-risk --
high-reward end of the scale.

Documentation is more on the medium-effort --- low-risk -- low-reward
end. We need more, but we (and you specifically) have put significant
effort here, and there's bound to be a diminishing reward to saying the
same thing a little better and in different ways unless we also somehow
find new voices.

Running on more VMs is high-effort -- medium-risk -- medium-reward. We
know how to do this, but it takes a long time. Building Racket on
Scheme, which should be about the easiest possible choice, took a
couple of years (and counting); then again, we were aiming for a very
high level of compatibility, which might not always be necessary. There
are ongoing projects here and they should certainly continue, because
they hit a good point in the risk--reward spectrum. Maybe I am
personally burnt out on this direction, so I am motivated to reason in
favor of a different problem.

Improved tooling also seems high-effort -- medium-risk --
medium-reward. I'll defer to those who concentrate more on tools,
including the author of Racket mode for Emacs, to suggest a priority
for this one.

> 5. Given all that, what should we do?

You have a more than my 2 cents already. :)

[Matthew Flatt]

At Fri, 19 Jul 2019 08:54:41 -0700 (PDT), Brian Adkins wrote:
> This may seem like a nitpick, but I think there would be a *huge* shift in
> attitudes if the suggestion for an infix syntax was framed in a similar
> manner to Typed Racket as opposed to Racket 2. The latter seems to imply a
> premature conclusion, where the former proposes a question to be answered
> by the community i.e. if people do flock to #lang infix, then the people
> will have spoken. Let #lang infix win by merit, not by decree!

I agree that the process would have to be something like that. Compared
to projects like Typed Racket, a syntax change in Racket2 probably
requires more people. Also, Typed Racket took on the design constraint
that it should fit Racket as-is as much as possible, while a syntax
change would come with more expectation of migration. It's maybe just a
difference of degree, though.

[Matthew Flatt]

At Tue, 16 Jul 2019 15:45:36 -0300, Gustavo Massaccesi wrote:
> Also, it would be nice to have a rough timeline. 5 years?

N years, anyway. 5 years seems like too long for a plan, although fine
as an actuality. I'd aim for 2 years and try to believe that, so maybe
it could actually happen in 3-4 years.

[Greg Hendershott]

[[ Note: I sent this yesterday but the Google list server bounced it.
Although I told Matthew I was fine leaving it that way, with only
him seeing it, he encouraged me to post it again. ]]


Thank you for replying, Matthew.

It sounds like surface syntax, other back-ends, and better tooling and
documentation are the available ideas for enabling more people to use
Racket.

Of these, the one for which you have energy and enthusiasm is as I said
before a valid and extremely important consideration.

Within that decision space I wouldn't prolong the discussion.

> Improved tooling also seems high-effort -- medium-risk --
> medium-reward. I'll defer to those who concentrate more on tools,
> including the author of Racket mode for Emacs, to suggest a priority
> for this one.

Speaking of that, I had some plans what to do next. Even explore some
modest open-source funding. But Sunday morning hit the Pause button.

On Twitter I'm seeing some parody of old, sour, inflexible lispers who
only love sexprs. You know, fighting the inevitable electric car, which
is apparently on their lawn. Funny and unfair, both.

Although there are many ways and reasons to caricature me -- and I
heartily encourage anyone to do so, it's great fun! -- this doesn't
happen to be one of them. I spent a couple decades with C/C++. As my
mid-life crisis, instead of buying a sports car I learned Racket and
Emacs. Sexprs weren't a big deal; the new (to me) concepts were. Yes,
I've grown to really enjoy sexprs for editing (paredit), richer
identifier names, and not needing to check the tiresome board game rules
for operator precedence. But it's not like I can't use C or JS or Rust
or Haskell or Python or whatever syntax productively, especially when
not creating macros. In fact I can use those syntaxes by, say, using
those languages.

So for me, it's more like, "Well. If Racket will change that way, and
I'm skeptical it will help adoption, that feels like an inflection
point; a nudge to look around. Maybe spend more time with Rust or
Haskell or X, for the next ~10 years."

I'm not saying this is strictly logical. It's how I feel now. I'm also
not claiming it should be any input whatsoever into decisions made,
except maybe to the extent I'm representative of more people (and maybe
not even then).

Even if I decided to spend less time with Racket, I expect it would be
more like a slow cross-fade. This is not an abrupt, "So Long and Thanks
for All the Standard-Fish" announcement. :)

But seriously I feel like I need to wait for the dust to settle, digest,
understand where things will be in a couple years.

---

To answer your question, things like paredit, parinfer and fructure are
very interesting. With respect to adoption? Paredit seems like something
people try/abandon several times before it "sticks". I did; four times.
Since he was RacketCon, I should have mentioned Phil Hagelberg's
wonderful comment: "If you don't think paredit is for you, then you need
to become the kind of person paredit is for." :) So my uninformed first
question is, are structured editing tools equally as hard/easy as text
sexprs, for beginners? And OMG what about people who've already learned
the "obvious" syntax? I don't know. I'll mull that over and other
tooling ideas.

And as I already mentioned in my talk, support for indentation probably
needs to be per-module not just per-lang.

[Brian Adkins]

On Monday, July 22, 2019 at 9:53:35 AM UTC-4, Greg Hendershott wrote:

> Improved tooling also seems high-effort -- medium-risk --
> medium-reward. I'll defer to those who concentrate more on tools,
> including the author of Racket mode for Emacs, to suggest a priority
> for this one.

Speaking of that, I had some plans what to do next. Even explore some
modest open-source funding. But Sunday morning hit the Pause button.

On Twitter I'm seeing some parody of old, sour, inflexible lispers who
only love sexprs. You know, fighting the inevitable electric car, which
is apparently on their lawn. Funny and unfair, both.

Yup, saw the same thing, but, heh, the internet is nothing if not a fantastic straw man factory :)

 

Although there are many ways and reasons to caricature me -- and I
heartily encourage anyone to do so, it's great fun! -- this doesn't
happen to be one of them. I spent a couple decades with C/C++. As my
mid-life crisis, instead of buying a sports car I learned Racket and
Emacs. Sexprs weren't a big deal; the new (to me) concepts were. Yes,
I've grown to really enjoy sexprs for editing (paredit), richer
identifier names, and not needing to check the tiresome board game rules
for operator precedence. But it's not like I can't use C or JS or Rust
or Haskell or Python or whatever syntax productively, especially when
not creating macros. In fact I can use those syntaxes by, say, using
those languages.

So for me, it's more like, "Well. If Racket will change that way, and
I'm skeptical it will help adoption, that feels like an inflection
point; a nudge to look around. Maybe spend more time with Rust or
Haskell or X, for the next ~10 years."

Very astute observation re: the motivation for some to start looking around. 

I think I've personally made this a "tempest in a tea pot", and I now feel much better about continuing to be able to develop in #lang racket for a long, long time. However, one of my past frustrations is how good the lisp community has been at dividing and conquering itself. Being unfamiliar with some of Racket's unique benefits, I initially felt it was simply the best Scheme I could choose for professional development. Being 8 months into a large project in Racket, and seeing some of Racket's unique benefits more clearly now, I already know there are no other lisps that could currently lure me away, but folks who are just now looking may be getting a sense of some identity confusion. And I admit checkout out Chez Scheme a little more recently, but it would be too painful to give up Racket's benefits over Chez.

I already spent 10 years with SML, Haskell, OCaml, Rust, Julia, among others, and concluded Racket was the best for me, so I really, *really* don't want to start that process again!

 

I'm not saying this is strictly logical. It's how I feel now. I'm also
not claiming it should be any input whatsoever into decisions made,
except maybe to the extent I'm representative of more people (and maybe
not even then).

Even if I decided to spend less time with Racket, I expect it would be
more like a slow cross-fade. This is not an abrupt, "So Long and Thanks
for All the Standard-Fish" announcement. :)

But seriously I feel like I need to wait for the dust to settle, digest,
understand where things will be in a couple years.

Please don't wait for the dust to settle Greg! 

While I think the Racket core team did a pretty poor job of communicating (only partly due to my ignorance) how someone who is primarily interested in using #lang racket should feel about continuing with #lang racket, my current (possibly naive?) sense is that I shouldn't be concerned. However, how I personally feel is irrelevant if enough other folks start looking around for lispier pastures :(

[Neil Van Dyke]

Brian Adkins wrote on 7/22/19 1:28 PM:

> Being unfamiliar with some of Racket's unique benefits, I initially
> felt it was simply the best Scheme I could choose for professional
> development.

Same here.  (Long-timers have heard my story too many times... After I
picked Scheme for my new super-productive R&D language (I'd mostly been
using Java for research, and a couple urgent research prototypes in
Emacs Lisp for bizarre reasons, after using mainly C and C++
professionally), I started writing missing libraries (`html-parsing`
includes my first Scheme code, and it shows).  I originally wrote
portable Scheme, and tested it on *many* Schemes, but later decided I
couldn't turn down the advantages of Racket (nee PLT Scheme), and so
moved to it primarily.)

I still keep certain other Schemes in mind, for their particular
strengths, and who knows when someone will come up with another one with
a from-scratch implementation (e.g., targeting GPU/TPU, or
groundbreaking scalability in some regard).  And also seeing how RnRS
develops, though sadly I don't currently have time/funding to contribute
directly to it myself.)

> Being 8 months into a large project in Racket, and seeing some of
> Racket's unique benefits more clearly now, I already know there are no
> other lisps that could currently lure me away,

Racket is my overall favorite Lisp, too (maybe someday Racket2 will
be).  I also have to acknowledge fondness of the Scheme foundation, the
legendary greatness of Common Lisp, the innovations of Clojure, etc. 
Lisp is a big community, all with our own charming accents and mixes,
and we don't talk as often as we should.

> how someone who is primarily interested in using #lang racket should
> feel about continuing with #lang racket

Perhaps it will also continue to blossom, during the Racket2 linguistic
Renaissance.  (For example, there are a few quality-of-life extensions
one might propose to `#lang racket`, to little opposition, when everyone
is focused on the new thing.)

[Arie Schlesinger]

Hi,

I would appreciate any advice  with combining and using Racket and Jupyter Notebook, if somebody has used these two.

Thanks,

Arie 

--
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/5d34617a.1c69fb81.383c7.0155SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

[Will Jukes]

I teach Scheme and Python on different contexts, to middle and high school students with varying degrees of programming background (beginner to ~fairly advanced), and wanted to share what I perceive kids to struggle with when learning Scheme relative to other languages, and how I think some of these changes might help (or hurt) my students.

• Kids struggle with parentheses, but they also struggle with car and cdr (first and rest), the notion of an expression, the difference between a symbol and a string, recursion (obvious) etc. Parenthesized syntax isn't special in this regard.
• Many constructs in Python, however, pose just as much trouble (the off-sides rule is a big one, especially if they have prior exposure to curly braces syntax), including pretty pedestrian stuff like the difference between a string literal and a variable name, or the difference between defining and calling a function.
  
• Whether or not students have prior programming experience they tend to bring in assumptions about what programming is supposed to look like, and s-expressions are quite contrary to that. However, they are not especially difficult to learn, relative to other programming constructs.
• I think a lot of complaints about s-expressions come from people who understand themselves as competent programmers but struggle with a language that works very unlike anything they've encountered before (it works the same in reverse; I learned lisp first, and still frequently write buggy python code that looks like `map(lambda x: x + 1, some_list.sort())`).
  
• I think minimizing parentheses would probably make for more readable code and would probably help my students, but it would do so primarily by not looking so ostentatiously different than what people are used to; people would be slower to assume they don't have any idea about what's going on.
• On the other hand, parenthesized syntax is a natural way of conveying the difference between statements and expressions, and that's lost in moving away from parenthesized syntax, so there's some trade-off there.
  

On Sunday, July 14, 2019 at 1:44:30 PM UTC-4, cwebber 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

[Shriram Krishnamurthi]

To riff on Will's message:

In the Bootstrap:Algebra materials, we use Racket syntax because it's a powerful pedagogic device. Recently, for various reasons, we've ported this over to another language called Pyret (while also maintaining the Racket version; it hasn't been deprecated). 

Pyret has an almost-traditional infix syntax. It turns out infix is actually much worse for the concepts we try to teach in that curriculum. Of course it can be done, but the irregularity of infix — which is barely noticed or even appreciated in some contexts — is a real headache there. We have to work against it, rather than it working for us.

So, especially in education:

(a) the subtleties of syntax are manifold and sometimes unexpected

(b) there's an enduring value to our (beloved) syntax, so it'll never go away (-:

Shriram

[gfb]

In our CS1 for humanities and social science the parenthetical syntax has not only not been a problem, it really appears far easier/better. As sk and other bootstrappers and htdpers have known for a long time, unless one focuses on already familiar numerical algebraic expressions, irregularity is a hindrance.

I've taught the exact same material at the start of a 3rd year CS PL course, and the students there didn't find the syntax as easy as one would hope for students with that much CS “experience”. In fact, unsurprisingly, many find the syntax as hard as expected for having trained on very different syntaxes (especially when they are unclear about the semantics that were attached to those syntaxes). Although the switch to teaching the start of the course with literally the same materials, with the students knowing that, seems to have reduced resistance substantially (presumably they don't want to be seen as complaining about something 1st year humantities students are fine with).

[Hendrik Boom]

On Wed, Jul 24, 2019 at 08:06:18AM -0700, Will Jukes wrote:
> - On the other hand, parenthesized syntax is a natural way of conveying

> the difference between statements and expressions, and that's lost in
> moving away from parenthesized syntax, so there's some trade-off there.

Is there a difference between statements and expressions? Other than
statements returning a data type that takes no space to represent?

-- hendrik

[Alexander Shopov]

To whoever will implement a new syntax forRacket, may I give the following resources. I really hope they are widely known and I am just stating the obvious common knowledge.

There have been previous attempts of using an alternative syntax:

 * M-expresisons - dating to the original McCarthy Lisp paper http://www-formal.stanford.edu/jmc/recursive.pdf, https://en.wikipedia.org/wiki/M-expression#cite_note-3

 * I-expressions - https://srfi.schemers.org/srfi-49/srfi-49.html

On a semi related note: I would also recomment this recent (2017) lecture by Guy Steele: It's Time for a New Old Language https://www.youtube.com/watch?v=dCuZkaaou0Q on the most popular programming language in computer science (definitely not Scheme as it has no compiler, interpreter or specification)

Kind regards:

al_shopov

--
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/20190724204753.dwvr6ji5nzbfd7jr%40topoi.pooq.com.

[Greg Hendershott]

> I've taught the exact same material at the start of a 3rd year CS PL
> course, and the students there didn't find the syntax as easy as one would
> hope for students with that much CS “experience”. In fact, unsurprisingly,
> many find the syntax as hard as expected for having trained on very
> different syntaxes (especially when they are unclear about the semantics
> that were attached to those syntaxes). Although the switch to teaching the
> start of the course with literally the same materials, with the students
> knowing that, seems to have reduced resistance substantially (presumably
> they don't want to be seen as complaining about something 1st year
> humantities students are fine with).

This makes me wonder if some experienced programmers dislike simple
syntax, not just because it is unfamiliar to them, but also because it
is too simple to serve as an effective in-group filter. If humanities
students are comfortable, we must raise the barrier to entry. ;)


p.s. I just now stumbled across the Iron Ring obtained from the Ritual
of the Calling of an Engineer. Probably everyone has heard of this
except me, but if anyone hasn't:

https://en.wikipedia.org/wiki/Ritual_of_the_Calling_of_an_Engineer

[Hendrik Boom]

On Thu, Jul 25, 2019 at 09:42:10PM -0400, Greg Hendershott wrote:
>
> This makes me wonder if some experienced programmers dislike simple
> syntax, not just because it is unfamiliar to them, but also because it
> is too simple to serve as an effective in-group filter. If humanities
> students are comfortable, we must raise the barrier to entry. ;)

the real question is, "What is simple syntax?"
or, "Who or what finds it simple?"

Human beings find natural language really simple to use.

Computer programs find natural language really hard, and like recursion
and parentheses.

Natural languages use a wide variety of syntaactic forms and even have
practical limits on nesting depth.

-- hendrik

[Dario Maiocchi]

HI all,

I would personally be unhappy if in racketlang2 we would remove the  (). I don't think they represent a real issue. 

Just to share my personal experience a professional programmer. I learned clojure  like 7 months ago and now I'm learning racketlang and  I never felt the () as a barrier.

best

[Chris Stephenson]

Parantheses and learners - experience with 14-18 year olds

I have just finished giving a two week intensive course to 14-18 year olds at the Mathematics Village near Ephesus in Turkey

The course is based on Bootstrapworld Algebra and Reactive. Internet is very poor in the village, so we cannot use the web based WeScheme versiosn of the course(s).

We have converted  the Pyret language of the Reactive course to Racket for two reasons:

(a) A change of syntax between the two halves had proved confusing for students

(b) We don't have an offline Pyret, we had found online to be unusable in ptractice with our flaky internet connections and setting up a local server just looked to be too much work.

So we have a variety of experience with our 14-18 year olds, Beginners Language Racket, Pyret, #lang racket with structs.

Do we have parenthesis problems?

Yes. Worse for students with previous programming experience. We solved them by educating our students in the clues given by drRacket - colouring matching parenthesis. But the most useful trick we taught is to select the whole function and use tab to autoformat it. This immediately makes parenthesis errors obvious. Make of that what you will. Does that mean that an indentation based format would be better? I am not sure.

We certainly did *not* see any benefit from giving the second week in indentation based Pyret, as we did three years ago. Pyret was a pain. Error messages were not clear and the whole change confused students. Including students who had used Python, because the syntax looked familiar but the underlying language was different - being functional.

Other problems?

Two language features caused us trouble, being the cause of impenetrable bugs in student code:

(a) Implicit begin .. end in function body. I have been writing Scheme for 20 years, and I **didn't know this existed**, always writing begin .. end in the very rare cases it was needed.

Beginner Student (imho correctly) treats this as an error. I would be happy if advanced Racket also treated it as an error. You can end up with bizarre results if it is allowed and you don't notice what you have done. It allows, encourages even, paranthesis errors. 

(b)  Conds allowed without else. Even beginner student allows this. It causes bugs. In htdp/universe you can end up with a void universe or a void somewhere in univers. the error emerges a long distance in space and time from the code that causes it. Make else clauses compulsory.

That's my two cents worth. 

[Sorawee Porncharoenwase]

Pyret was a pain. Error messages were not clear and the whole change confused students.

Can you elaborate more on this? My personal experience with Pyret is that it has an exceptionally good error message, except when an internal error occurs (which should not happen).

Two language features caused us trouble, being the cause of impenetrable bugs in student code: 

 

(a) Implicit begin .. end in function body. I have been writing Scheme for 20 years, and I **didn't know this existed**, always writing begin .. end in the very rare cases it was needed. 

Beginner Student (imho correctly) treats this as an error. I would be happy if advanced Racket also treated it as an error. You can end up with bizarre results if it is allowed and you don't notice what you have done. It allows, encourages even, paranthesis errors. 

Well, why do your students use `#lang racket` rather than student languages?

And in my opinion, imposing students' programming environment constraints to professional programming environment is probably not a good idea. There are people who use `#lang racket` in imperative style. Forcing them to write `begin` everywhere will just cause a hassle.

Pyret has this feature, by the way.

 

(b)  Conds allowed without else. Even beginner student allows this. It causes bugs. In htdp/universe you can end up with a void universe or a void somewhere in univers. the error emerges a long distance in space and time from the code that causes it. Make else clauses compulsory.

A lot of people agree with you. Here's a (pre-) RFC on the issue: https://github.com/racket/racket2-rfcs/issues/39

[Shriram Krishnamurthi]

Pyret was a pain. Error messages were not clear and the whole change confused students.

Can you elaborate more on this? My personal experience with Pyret is that it has an exceptionally good error message, except when an internal error occurs (which should not happen).

IMO, Pyret's parse errors are terrible. To some extent they are an unavoidable consequence of infix, but it doesn't matter: parse errors just suck, even for me, even today, even as one of the three longest-running Pyret programmers. 

The run-time errors are (again IMO) much better than Racket's.

Chris, FYI, Bootstrap:Reactive was in Racket to begin with, so there may not have been a need to "convert" it…

Shriram

[Chris Stephenson]

Hi Shriram

Nice to hear from you!

In a course for 14-18 year olds where we are rigorously enforcing the design recipe, the overwhelming majority of errors are, indeed, syntax errors. (Except for missiing-else conds, of course)

So that was what I meant. Pyret syntax errors are reported confusingly. Infix just messes things up. And in my view prefix does not present a problem for students

Conversion: Indeed we did find an old version of Reactive in Racket, by which time we had already translated the newer Pyret version into Turkish and also introduced some experience based changes of our own. So what we had in our hands had diverged in several ways from the old Racket version. So we were merging the changes we had made and also translating the Turkish langauge documentation from Pyret to Racket.  

I understand the critcisms for using lang racket rather than advanced student in the second week , after using beginner in the first.   Given that advanced student also accepts else-less conds (the worst source of hard-to-find errors) and we wanted to use the new Racket struct syntax (and struct-copy which can make HtDP universe code much shorter) we were pushed in that direction. I dont think we paid any other penalty for using lang racket. If we had had struct and struct-copy in advanced student, we would have used it. I am sure that is something we could have solved ourselves ... but ....time...

Thanks for your views. 

Chris

[George Neuner]

On Wed, 21 Aug 2019 03:48:29 -0700, Sorawee Porncharoenwase
<sorawe...@gmail.com> wrote:

> On Wed, 21 Aug 2019 02:55:46 -0700 (PDT), Chris Stephenson
> <cjkste...@gmail.com> wrote:

>> (b) Conds allowed without else. Even beginner student allows this. It
>> causes bugs. In htdp/universe you can end up with a void universe or a void
>> somewhere in univers. the error emerges a long distance in space and time
>> from the code that causes it. Make else clauses compulsory.
>>
>
>A lot of people agree with you. Here's a (pre-) RFC on the issue:
>https://github.com/racket/racket2-rfcs/issues/39

I don't like the idea of compulsory 'else' - for 'cond' or 'case' or
'match' or ...

'Else' isn't needed if all input cases are covered, but in almost all
real world uses, the compiler is not able to prove the 'else' is
unneeded so as to prevent emitting code for it. And depending on how
the compiler structures the tests (cond is simple, case less so),
adding 'else' into the mix may increase execution time as well.


YMMV,
George

[Hendrik Boom]

On Wed, Aug 21, 2019 at 02:55:46AM -0700, Chris Stephenson wrote:
> Parantheses and learners - experience with 14-18 year olds

...
...

>
> Do we have parenthesis problems?
>
> Yes. Worse for students with previous programming experience. We solved
> them by educating our students in the clues given by drRacket - colouring
> matching parenthesis. But the most useful trick we taught is to select the
> whole function and use tab to autoformat it. This immediately makes
> parenthesis errors obvious. Make of that what you will. Does that mean that
> an indentation based format would be better? I am not sure.

There are three things here:

* The notation the language uses for nesting
* The visual appearance of the code
* The intentions of the programmer

The problem exists when these conflict.

The solution exists when the programmer can see that his intentions to
not match the code.

Autoformatting the function accomplishes this by making the appearance
match the language's notation. Especially if it's easy to do.
Letting the editor signal mismatches between indentation and semantics
is also effective.
Colouring the brackets helps for bracket clusters within a line.

Hand-indenting (as in Python) also accomplishes this, but is more work.

But an additional effective technique is to enable notation for
tail-nesting parentheses, so there are fewer physical parentheses to
match up.

e.g. (a b ; c d ; e f) for (a b (c d (e d)))

Or
( a b
; c d
; e f)

but Racket would need another character than ';' for this. Are there
any left?

-- hendrik

[Hendrik Boom]

On Wed, Aug 21, 2019 at 10:52:57AM -0400, George Neuner wrote:

>
> I don't like the idea of compulsory 'else' - for 'cond' or 'case' or
> 'match' or ...
>
> 'Else' isn't needed if all input cases are covered, but in almost all
> real world uses, the compiler is not able to prove the 'else' is
> unneeded so as to prevent emitting code for it. And depending on how
> the compiler structures the tests (cond is simple, case less so),
> adding 'else' into the mix may increase execution time as well.

What about treating a missing 'else' as a run-time error if and only
if control gets that far.

That would require code that intends nothing to be done to have an
explicit 'else' saying so.

Except for notation, this would seem to meet your demands for semantic
expressibility.

-- hendrik

[Shriram Krishnamurthi]

I agree that struct-copy is almost essential. That's why it's baked into the syntax of Pyret (where we're very sparing in what we provide syntactic surface to). It might be better to just import struct-copy and leave the language-level intact, in the future (if not create a language level that reflects this).

--
You received this message because you are subscribed to a topic in the Google Groups "Racket Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/racket-users/ewWuCvbe93k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/bae23873-6837-415c-97ff-d7c0879873ad%40googlegroups.com.

[Gustavo Massaccesi]

The expander in racket adds something equivalent to

    [else (void)]

if there is no else clause. (Try an example with the Macro Stepper.) So an explicit else clause would not change the speed of the programs.

In some cases the compiler can prove that the else part is not necessary and drop it, Also, I think that the compiler in RacketCS can notice that it has no side effects and also drop it if the result is ignored (but I'm not 100% sure).

Gustavo

[Christopher Lemmer Webber]

Chris Stephenson writes:

> Parantheses and learners - experience with 14-18 year olds
>
> I have just finished giving a two week intensive course to 14-18 year olds
> at the Mathematics Village near Ephesus in Turkey

Very interesting email all around!

> (a) A change of syntax between the two halves had proved confusing for
> students

You actually touched on something that has been at the back of my mind
for a while. Else where in this discussion:

Matthew Flatt writes:

> At Sat, 20 Jul 2019 18:07:40 -0400, Christopher Lemmer Webber wrote:

>> - Are people happy? Is this meeting their needs? Get community input.
>> At this point, if the community is happy enough, and if it appears
>> that *newcomers* (including in the educational space) are happy
>> enough, now we can focus on switching the core Racket system over
>> to ~Honu-as-the-basis.

>
> I agree that the process would have to be something like that.
>

> I'm skeptical of starting with teaching languages in the sense of BSL,
> ISL, and ASL. That sets up some different problems --- ones that Pyret
> has directly addressed/explored. (Obviously, we should pay attention to
> Pyret.)

I've been thinking about this, and I think that it's hard enough *for
me* to jump between different syntaxes. If there was a switch to ~Honu
as being the default, it really should be ~Honu everywhere... not ~Honu
in one place and Pyret like syntax in the other (or vice versa). That
kind of context switch is really hard.

In my experience, the most empowering thing for students is "being able
to write programs that do cool things". If we use different syntaxes, I
think this will feel like the worlds between a "beginner's language" and
the "main world of Racket" will feel like too much of a jump... I know
*I* get intimidated by a shift in syntax, and I'm sure that for
students, it's even harder.

Gerald Sussman explained Python's success, and the reason for the switch
from Scheme and SICP to a Python based curriculum, as being because
Python had for whatever reason libraries that allowed students to be
able to lego together examples very quickly. I've made the case that
Racket is the Python of lisps... even if we aren't continuing to have a
lispy syntax by default, we should realize that this is a strength we
don't want to lose. If there's a syntax gulf between the restricted
student languages and the "main" language, we'll diminish that value
we're providing to newcomers.

[Christopher Lemmer Webber]

Christopher Lemmer Webber writes:

> Gerald Sussman explained Python's success, and the reason for the switch
> from Scheme and SICP to a Python based curriculum, as being because
> Python had for whatever reason libraries that allowed students to be
> able to lego together examples very quickly. I've made the case that
> Racket is the Python of lisps... even if we aren't continuing to have a
> lispy syntax by default, we should realize that this is a strength we
> don't want to lose. If there's a syntax gulf between the restricted
> student languages and the "main" language, we'll diminish that value
> we're providing to newcomers.

More on that:

https://cemerick.com/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program/

Though I also saw him explain this in a talk, I forget which one, maybe
it was:

https://vimeo.com/151465912

... but I don't have time to review again.

[George Neuner]

Not at all.  Obviously, I'm not a beginner:  when I choose to leave out
'else', it is not a mistake - I intend that nothing should happen if no
explicit case was matched.  An implicit runtime error would represent
completely different semantics ... well defined maybe, but completely
different nonetheless.

More importantly, the code generation consequences exist regardless of
whether the 'else' is explicit or implicit:  it requires extra tests
which may affect the overall structuring and performance of the [set of]
tests.  As I alluded to above, 'cond' wouldn't be affected very much
because it compiles quite straightforwardly into a series of 'if's' that
correspond directly to the source.  However 'case' is a different matter.

I admit that I haven't looked to see how Racket compiles 'case' ... and
there are many possible variations due to the flexibility of the
construct.  However, I have some non-Scheme-related experience with
compiler implementation, and in general, 'case' presents many more
opportunities wrt 'cond' to generate better optimized, out-of-order (wrt
the source) testing.  Requiring an implicit 'else' introduces
considerable extra complexity, and may (not necessarily will, but may)
hamper generating an optimal test sequence for the explicit cases.


This is something that may become more apparent with the switch to
RacketCS because the Chez compiler does much more optimization and
produces native code.  From a compiler implementor's view, the surface
syntax of the language largely is irrelevant - it impacts introspection
and metaprogramming, but quite a lot of syntax related stuff has little
or no effect on generated code.  However, some of the things that have
been mentioned (at various times) have very real consequences for
generated code: things like automatic currying, 'statement' vs
'expression', arbitrary numbers of return values, implicit 'else',
generic stream access to (raw) collections, generic port access to
strings, N-dimension arrays vs vectors of vectors, incremental typing,
etc.  It's the features themselves which affect the generated code that
I worry about much more than what syntax is used.


That said, I *like* the Lispy syntax.  I do think there are some
opportunities to reduce the number of parentheses needed, but the
consistent prefix nature of S-exprs is - I think - what makes Racket
(and Scheme and Lisp) *easier* to learn than many other languages.
Remembering all the operator precedences in infix languages is a PITA.

I dislike in some FPLs remembering that I *must* use parentheses in
certain cases, while in other cases they are optional (or even
disallowed).  I loathe significant whitespace (indentation) as in Python
- counting spaces is just as stupid as counting parentheses [and yes, a
decent editor can address either problem, but jeez ... even Fortran
dropped its indentation requirements decades ago].

I don't think "popularity" is a very good reason to change language
syntax - but as long as S-expr Racket remains a viable, completely
*supported*, language, then I don't have a problem with development of a
parallel infix version.

YMMV,
George

[George Neuner]

Yes.  But in most cases, it is impossible to prove that the 'else' is
unnecessary.  And as I mentioned in my reply to Hendrick, 'cond' is
pretty simple, but an 'else' - implicit or explicit - can screw up
optimizing tests in a 'case'.

George

[Chris Stephenson]

Yes this year we put a lot of effort into reducing any kind of change between the two halves of the course, even changes of approach independent of language

This worked well for students. the first 5 days or so was a slightly enhanced version of Bootstrapworld Algebra. 

However, we wanted more on logical operators and on symbolic values, so we expanded the exercise a that has a butterfly trying to stay out of danger in a garden to include well in the middle of the garden. So the butterfly has to stay within the garden and outside the well. Then the size of the garden and the size and position of the well become variables...  This was a good preparation for the second half in which students designed a game from the ground up using 2htdp/universe.

Our "killer app" was to introduce vector arithmetic the moment we had structs. We did the math and the programming together and built a set of vector arithmetic functions /vector addition subtraction, vector/scalar multiplication, dot product, magnitude)

Then.. we introduced an object struct that had an imgae and three vectors - location, velocity acceleration. Once the students have developed functions to move and draw thewse objects they have a very powerful and simple tool in their hands.

Updating an object is like this

location, velocity, acceleration -> location+velocity, velocity+acceleration, acceleration  (all vector arithmetic, of course)

We introduced structs for the first time on Sunday morning. By Monday evening they had objects moving in parabolic arcs on the screen under the effect of "gravity"

This created a "wow" effect and students were then able to produce quite impressive games by the end of the course on Saturday sfternoon.

The "wow" effect is really important...        It gave students confidence.

I am not sure how easy this would have been in another language environment. the 2htdp/universe framework and the design recipe certainly were very important.

By the end of the 2 weeks even the most stalwart previous programmers had been converted to the benefits of the design recipe. Ad most of the newbies had produced quite sophisticated games far from the standard form provided for them in the first 5 days.

Of the difficulties we faced with students, syntax errors were the most common, missing else clauses and errors associated with implicit begin end were the most intractable.

Our students face the additional difficulty that all error message are in a foreign language (English) that many of them do not know well, some know hardly at all 

The only language trick we did was to use a  macro for struct definition so that every struct automatically had an inspector and so structs printed out nicely and EXAMPLE (ie check-expect) worked for structs. Except we called it ÖRNEK (which is example in Turkish) 

CS

[Jon Zeppieri]

On Wed, Aug 21, 2019 at 2:43 PM George Neuner <gneu...@comcast.net> wrote:
>
>
> On 8/21/2019 1:13 PM, Gustavo Massaccesi wrote:
> > The expander in racket adds something equivalent to
> > [else (void)]
> > if there is no else clause. (Try an example with the Macro Stepper.)
> > So an explicit else clause would not change the speed of the programs.
> >
> > In some cases the compiler can prove that the else part is not
> > necessary and drop it, Also, I think that the compiler in RacketCS can
> > notice that it has no side effects and also drop it if the result is
> > ignored (but I'm not 100% sure).
>
> Yes. But in most cases, it is impossible to prove that the 'else' is
> unnecessary.

Yes, but this is why `else` doesn't slow anything down. Unless the
compiler can prove that it's unnecessary, an `else` clause going to be
there whether you write it explicitly or not, which is exactly what
Gustavo wrote above.

> And as I mentioned in my reply to Hendrick, 'cond' is
> pretty simple, but an 'else' - implicit or explicit - can screw up
> optimizing tests in a 'case'.
>

Racket's `case` is an implementation of this approach:
http://scheme2006.cs.uchicago.edu/07-clinger.pdf

It is not significantly complicated by `else`. And that approach was
created in the context of Scheme, which leaves the return value
unspecified when none of the tests are successful. That seems like it
should offer more opportunities for optimization, but I don't think
this approach is any less efficient when the unsuccessful result is
specified as #<void> (as it is in Racket) than when it is not.

- Jon

[George Neuner]

On 8/21/2019 3:25 PM, Jon Zeppieri wrote:
> Racket's `case` is an implementation of this approach:
> http://scheme2006.cs.uchicago.edu/07-clinger.pdf
>
> It is not significantly complicated by `else`. And that approach was
> created in the context of Scheme, which leaves the return value
> unspecified when none of the tests are successful. That seems like it
> should offer more opportunities for optimization, but I don't think
> this approach is any less efficient when the unsuccessful result is
> specified as #<void> (as it is in Racket) than when it is not.
>
> - Jon

Thanks for the pointer!

'case' in Scheme is an interesting challenge for compilation because it
can involve dispatching on multiple types, each having its own
comparison ordering.  I would hope that Racket leverages generic table
searches where possible - depending on the use, generating a complete
static dispatch routine everywhere can result in explosive growth of the
code.  [Not that I've seen this happen, but I haven't had occasion to
experiment in Racket with extremely large or complicated 'case' 
constructs.]

George

[Gustavo Massaccesi]

[I remember an old discussion about this, but I can't find the message.]

For small number of clauses, case is expanded to a bunch of if. When there are more than ¿12? it may be use a hash table or binary search. It has a few tricks:

https://github.com/racket/racket/blob/master/racket/collects/racket/private/case.rkt

Gustavo

--

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/a8dd208d-dd3f-a2a7-3d20-3c1027932ac9%40comcast.net.