Re: [racket-users] Racket2 possibilities

[Samuel Ainsworth]

As a former Racket user but not a current member of the Racket community, I 
thought I might toss in my 2c. My reasons for not using Racket are 
essentially,
1. Parentheses make my head hurt.
2. DrRacket is slow, and VSCode integration is weak.

I've heard the "surface syntax doesn't matter" arguments before, and 
frankly I find them to be condescending oftentimes. "Oh, you find this 
parenthetical syntax confusing? That's cute." The reality is clear: syntax 
is the user interface to a programming language. And anyone who claims that 
user interfaces don't matter is simply delusional. Although parentheses 
have a religious following, it should be noted that members of the Racket 
community have an understandable selection bias on this issue. The rest of 
the programming world just doesn't seem to feel the same way. 

I sense that many of the parenthistas among you may discount my experience 
as coming from one of the "unenlightened," a lesser soul trapped in a desk 
job writing Java for the last 10 years who has not yet been shown the 
light. But in fact I was trained in Racket by one of its creators. I'm also 
a PhD student in computer science and an early adopter of languages. I am 
aware of and admire much of the research that's gone into the Racket that 
exists today. I see the beauty in language's foundations. I've even 
attended RacketCon. Still, I dread having to work in Racket. It's not lost 
on me that Racket is a "better" language than Python in many respects. It's 
just that Python offers a much, _much_ better user experience in terms of 
its package ecosystem, developer experience and, yes, syntax.

As an outsider it seems clear to me that if the Racket community wishes to 
spread the gospel of language-oriented programming, it must shed its 
historical attachment to parentheses. I see Pyret as being the first domino 
to fall in this regard.

Just my 2c,
Samuel

On Monday, July 22, 2019 at 8:20:55 PM UTC-7, Andrew Gwozdziewycz wrote:
>
> On Mon, Jul 22, 2019 at 7:15 AM Alexis King  > wrote: 
> > 
> > On Jul 22, 2019, at 14:16, Dexter Lagan  > wrote: 
> > To say that Racket is so defined by its syntax that it will cease to be 
> distinguishable from any other language if it is changed is absurd, and 
> it’s frankly insulting to all the people who have put so much effort into 
> every part of Racket. 
>
> You have an advantage of being well invested in the Racket ecosystem 
> already. How do you convince someone _else_, perhaps in industry, that 
> Racket is interesting? It's pretty hard to say: "Look! Scribble and 
> Typed Racket, and contracts, and 10 other things make up this really 
> awesome ecosystem all running on a single VM, and they can all share 
> code!" Why? Because it's a _lot_ to digest, a _lot_ to try to 
> understand / invest in, and we live in a world where Go, a language 
> that effectively contains only 1970s language technology, is 
> dominating because of its simplicity and distinct lack of features. 
>
> On the other hand, people look at parens, think Lisp, completely 
> discount it because they heard "parens were really annoying to read," 
> or had a bad experience in college, and then move on anyway. People 
> judge a book by its cover, and they judge a language by its syntax. 
>
> Growing a language community is _really, really, really hard_, and is 
> only going to get harder as Racket grows in complexity, and other 
> languages come up that have immediately familiar syntax, and a simple 
> to understand core. A new syntax might checkmark the first point, but 
> I kind of think that the #lang ecosystem, _might actually be doing a 
> disservice_ to Racket. It's all the traditional complaints about 
> macros "you have to learn the original author's DSL" mixed with "you 
> have to learn the original author's half broken / buggy parser / 
> syntax and quirks, the new semantics it adds on, _and_ the library 
> that goes along with it, too." Oh, and "it's all mixed in with this 
> other stuff written in #lang racket, with these silly parens. I AM 
> CONFUSED!" 
>
> Not sure how to resolve all this, and I'm sorry for lacking a central 
> thesis in my reply, except to say that "syntax matters" and "Racket 
> isn't easy" ... 
>
> -- 
> http://www.apgwoz.com 
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/6db41009-cc9b-4129-b2d1-18007eec650f%40googlegroups.com.

Re: [racket-users] Racket2 possibilities

[Andrew Gwozdziewycz]

On Mon, Jul 22, 2019 at 7:15 AM Alexis King  wrote:
>
> On Jul 22, 2019, at 14:16, Dexter Lagan  wrote:
> To say that Racket is so defined by its syntax that it will cease to be 
> distinguishable from any other language if it is changed is absurd, and it’s 
> frankly insulting to all the people who have put so much effort into every 
> part of Racket.

You have an advantage of being well invested in the Racket ecosystem
already. How do you convince someone _else_, perhaps in industry, that
Racket is interesting? It's pretty hard to say: "Look! Scribble and
Typed Racket, and contracts, and 10 other things make up this really
awesome ecosystem all running on a single VM, and they can all share
code!" Why? Because it's a _lot_ to digest, a _lot_ to try to
understand / invest in, and we live in a world where Go, a language
that effectively contains only 1970s language technology, is
dominating because of its simplicity and distinct lack of features.

On the other hand, people look at parens, think Lisp, completely
discount it because they heard "parens were really annoying to read,"
or had a bad experience in college, and then move on anyway. People
judge a book by its cover, and they judge a language by its syntax.

Growing a language community is _really, really, really hard_, and is
only going to get harder as Racket grows in complexity, and other
languages come up that have immediately familiar syntax, and a simple
to understand core. A new syntax might checkmark the first point, but
I kind of think that the #lang ecosystem, _might actually be doing a
disservice_ to Racket. It's all the traditional complaints about
macros "you have to learn the original author's DSL" mixed with "you
have to learn the original author's half broken / buggy parser /
syntax and quirks, the new semantics it adds on, _and_ the library
that goes along with it, too." Oh, and "it's all mixed in with this
other stuff written in #lang racket, with these silly parens. I AM
CONFUSED!"

Not sure how to resolve all this, and I'm sorry for lacking a central
thesis in my reply, except to say that "syntax matters" and "Racket
isn't easy" ...

--
http://www.apgwoz.com

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CADoGzserVCpTmxrOPRiTKabaHaN4O%3D1WKcbR_Wqga8E70k_c_g%40mail.gmail.com.

Re: [racket-users] Racket2 possibilities

[Dexter Lagan]

  More specifically, I was referring to design goals for S-expressions:
-- generality: S-expressions should be good at representing arbitrary data. 
 -- readability: it should be easy for someone to examine and understand the 
structure of an S-expression. 
 -- economy: S-expressions should represent data compactly. 
 -- tranportability: S-expressions should be easy to transport over 
communication media (such as email) that are known to be less than perfect. 
 -- flexibility: S-expressions should make it relatively simple to modify and 
extend data structures. 
 -- canonicalization: it should be easy to produce a unique "canonical" form of 
an S-expression, for digital signature purposes. 
 -- efficiency: S-expressions should admit in-memory representations that allow 
efficient processing.

  These are just as relevant today as they were 50 years ago. Why change 
something that works?
Dex

> On Jul 22, 2019, at 4:15 PM, Alexis King  wrote:
> 
>> On Jul 22, 2019, at 14:16, Dexter Lagan  wrote:
>> 
>> A parens-less Racket2 would become Crystal.
> 
> 
> No it won’t. I am quite confident that Racket with any syntax will not be 
> like any other language that currently exists. What other language has 
> Racket’s advanced, robust compile-time metaprogramming support, its 
> higher-order contract system, its #lang mechanism (applied to great effect in 
> technologies like Scribble and Typed Racket), its 
> language-as-an-operating-system support for runtime sandboxing and 
> introspection, and its featureful and extensible FFI, among many other 
> things? To say that Racket is so defined by its syntax that it will cease to 
> be distinguishable from any other language if it is changed is absurd, and 
> it’s frankly insulting to all the people who have put so much effort into 
> every part of Racket.
> 
> If you believe Racket’s syntax is its most important feature, and that 
> everything else that sets it apart from other languages is pragmatically 
> irrelevant, I can’t really argue with that. I disagree, but it’s a matter of 
> opinion. That said, that kind of criticism isn’t very constructive, since I 
> don’t know how to interpret it beyond “I really like parentheses,” which is 
> hardly actionable or debatable.
> 
> I make no claims of representing the will of PLT, so I could be wrong, but I 
> think discussing what about s-expressions you like—and what about other 
> syntaxes you dislike—is on-topic and can produce constructive discussion. But 
> although it’s possible I didn’t read it carefully enough, the link you 
> provided doesn’t seem to have much in the way of that sort of explanation… it 
> seems to focus on how to most usefully take advantage of s-expressions, but 
> it doesn’t compare them to other formats.
> 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/4F504C9A-9D20-4A79-B136-A7C0D0F7DABD%40gmail.com.

Re: [racket-users] Racket2 possibilities

[Dexter Lagan]

  Like I said, my limited experience makes my opinion of limited interest. I’m 
really only speaking from a practical standpoint, meaning, how a Python or Java 
programmer would see Racket. For example, I have no experience with language 
design, and I only used Racket and Scribble as-is. Most people I talk to use 
Python, Go or Java because of their tooling, and don’t complain about Go’s lack 
of generics.

  I entirely agree with you, Racket is much more than another Scheme, and 
reducing it to its syntax isn’t fair. However, coming from object and 
imperative languages, and looking at Racket’s surface, one wouldn’t suspect 
there’s so much under the hood without digging deeper. It’s quite difficult to 
explain why Racket is so powerful, precisely when people stop at the 
parentheses.

  All that to say, I apologize if I offended anyone, and only wish to suggest 
there might be ways to make Racket more appealing without reinventing the 
wheel. My personal wish list doesn’t contain anything more advanced than what’s 
already there: for my use, faster startup and a slightly more advanced GUI 
framework and editor would be enough.

  What I’m suggesting is that if we want to expose Racket to a broader 
audience, maybe we could start at the bottom and target the more basic users?

Dex

> On Jul 22, 2019, at 4:15 PM, Alexis King  wrote:
> 
>> On Jul 22, 2019, at 14:16, Dexter Lagan  wrote:
>> 
>> A parens-less Racket2 would become Crystal.
> 
> 
> No it won’t. I am quite confident that Racket with any syntax will not be 
> like any other language that currently exists. What other language has 
> Racket’s advanced, robust compile-time metaprogramming support, its 
> higher-order contract system, its #lang mechanism (applied to great effect in 
> technologies like Scribble and Typed Racket), its 
> language-as-an-operating-system support for runtime sandboxing and 
> introspection, and its featureful and extensible FFI, among many other 
> things? To say that Racket is so defined by its syntax that it will cease to 
> be distinguishable from any other language if it is changed is absurd, and 
> it’s frankly insulting to all the people who have put so much effort into 
> every part of Racket.
> 
> If you believe Racket’s syntax is its most important feature, and that 
> everything else that sets it apart from other languages is pragmatically 
> irrelevant, I can’t really argue with that. I disagree, but it’s a matter of 
> opinion. That said, that kind of criticism isn’t very constructive, since I 
> don’t know how to interpret it beyond “I really like parentheses,” which is 
> hardly actionable or debatable.
> 
> I make no claims of representing the will of PLT, so I could be wrong, but I 
> think discussing what about s-expressions you like—and what about other 
> syntaxes you dislike—is on-topic and can produce constructive discussion. But 
> although it’s possible I didn’t read it carefully enough, the link you 
> provided doesn’t seem to have much in the way of that sort of explanation… it 
> seems to focus on how to most usefully take advantage of s-expressions, but 
> it doesn’t compare them to other formats.
> 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/B6F04E29-2123-410E-85EB-2E51FA554BC5%40gmail.com.

Re: [racket-users] Racket2 possibilities

[Alexis King]

> On Jul 22, 2019, at 14:16, Dexter Lagan  wrote:
> 
> A parens-less Racket2 would become Crystal.


No it won’t. I am quite confident that Racket with any syntax will not be like 
any other language that currently exists. What other language has Racket’s 
advanced, robust compile-time metaprogramming support, its higher-order 
contract system, its #lang mechanism (applied to great effect in technologies 
like Scribble and Typed Racket), its language-as-an-operating-system support 
for runtime sandboxing and introspection, and its featureful and extensible 
FFI, among many other things? To say that Racket is so defined by its syntax 
that it will cease to be distinguishable from any other language if it is 
changed is absurd, and it’s frankly insulting to all the people who have put so 
much effort into every part of Racket.

If you believe Racket’s syntax is its most important feature, and that 
everything else that sets it apart from other languages is pragmatically 
irrelevant, I can’t really argue with that. I disagree, but it’s a matter of 
opinion. That said, that kind of criticism isn’t very constructive, since I 
don’t know how to interpret it beyond “I really like parentheses,” which is 
hardly actionable or debatable.

I make no claims of representing the will of PLT, so I could be wrong, but I 
think discussing what about s-expressions you like—and what about other 
syntaxes you dislike—is on-topic and can produce constructive discussion. But 
although it’s possible I didn’t read it carefully enough, the link you provided 
doesn’t seem to have much in the way of that sort of explanation… it seems to 
focus on how to most usefully take advantage of s-expressions, but it doesn’t 
compare them to other formats.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/9AA3072F-1688-4424-B911-3C0190622661%40gmail.com.

Re: [racket-users] Racket2 possibilities

[Jay McCarthy]

On Sun, Jul 21, 2019 at 1:12 PM Alexis King  wrote:
> It is easy to foresee a transition away from s-expressions as a restriction 
> on what can be expressed via macros, mostly since non-s-expression languages 
> with macro systems (such as Haskell and Elixir, to name just two) usually 
> impose such restrictions. But that is what is so remarkable about Honu: its 
> macros allow what is really a superset of Racket’s current syntactic 
> flexibility. I think the paper has a good explanation of why this is, I just 
> don’t think it points out the implications explicitly enough, so if this is a 
> surprise to you, go back and take another look.

This point by Alexis, IMHO, is the big reason for thinking about
Racket2 for me. The parenthesis notation of Racket is a restriction to
make certain things easy, but we now know a lot more than we did in
the past, so we can keep those things easy while removing the
restriction that keeps us from doing more interesting things.

Jay

--
Jay McCarthy
Associate Professor @ CS @ UMass Lowell
http://jeapostrophe.github.io
Vincit qui se vincit.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAJYbDamD75CtipY3TQLaNDsVAGq4Os8kziqzZqBT0ZjATiZTzg%40mail.gmail.com.

Re: [racket-users] Racket2 possibilities

[Alexis King]

> On Jul 21, 2019, at 00:19, Matthew Flatt  wrote:
> 
> I have in mind "Honu: Syntactic Extension for Algebraic Notation through 
> Enforestation", GPCE 2012. It shows how we can bridge the relatively linear 
> structure of non-() programs to the tree structure of S-expressions. 
> Specifically, the bridge is called "enforestation". It sits roughly between 
> the reader and the expander, but enforestation needs to be interleaved with 
> expansion to get the level of expressiveness that Racketeers would expect.

To add a few of my own thoughts on this: in light of recent events, I reread 
the Honu paper more closely this past week, and I would strongly encourage 
anyone who is invested in surface syntax to do the same. It is a beautiful 
paper. Crucially, it is beautiful not because it does anything complex but 
because it solves a hard problem in a simple, elegant way. If you have any 
misgivings about what might happen to the expressiveness of the macro system if 
we were to move away from s-expressions, it is required reading.

What the paper does not do is editorialize (as it shouldn’t), so I will do so 
myself. The techniques described in the Honu paper are dramatically superior to 
alternative approaches I have seen, for two reasons:

“Automatic parenthesis insertion” approaches like sweet, wisp, liso, etc. 
invariably demand users think about the desugared, parenthesized form. Macros 
are ultimately still defined by parsing syntax objects built from 
s-expressions, so every extra pair of parentheses suddenly matters, even if 
they’re invisible and no reasonable built-for-purpose syntax would care about 
them. This is a terrible experience, and it forever condemns these approaches 
to be second-class citizens.

Honu’s macros, in contrast, operate much closer to the concrete syntax, and 
they don’t require thinking about implementation details of the language. We 
demand our Racket macros be real abstractions, and Honu lets them stay that way.

It is easy to foresee a transition away from s-expressions as a restriction on 
what can be expressed via macros, mostly since non-s-expression languages with 
macro systems (such as Haskell and Elixir, to name just two) usually impose 
such restrictions. But that is what is so remarkable about Honu: its macros 
allow what is really a superset of Racket’s current syntactic flexibility. I 
think the paper has a good explanation of why this is, I just don’t think it 
points out the implications explicitly enough, so if this is a surprise to you, 
go back and take another look.

Of course, it’s not all roses. The existing Honu implementation lays sturdy 
foundations, but it doesn’t include a syntax/parse equivalent: there’s no 
Honu-native DSL for writing Honu macros. A lot of the ideas in syntax/parse 
should carry over, but there are more than a few new wrinkles to be ironed out. 
On top of that, there are open questions about everything from documentation to 
tooling to what the appropriate syntax for the base language ought to be.

I understand that many people in the Racket sphere are very fond of 
s-expressions for a variety of reasons, something that was made abundantly 
clear to me in the several dozen replies I got to a twitter comment I made on 
the matter.  I 
certainly can’t assuage all fears of losing them, but I sincerely hope that the 
second point I made above sinks in for others like it has for me: there are 
ways a change in syntax can be enabling, not simply a compromise for some 
non-specific “other people.” Wouldn’t it be wonderful if we could design new 
languages, embedded or otherwise, with whatever syntax we wish as easily as we 
can design them in Racket today using s-expressions? Going down this path has 
the potential to move us much closer to that reality, and I, for one, think 
that’s exciting.
 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/FE3BEE8D-4380-4540-B478-F0BB424A5C4E%40gmail.com.

Re: [racket-users] Racket2 possibilities

[Hendrik Boom]

On Sat, Jul 20, 2019 at 08:53:17PM -0700, Andrew Gwozdziewycz wrote:
> 
> I'm in favor of a different syntax if it doesn't add new semantics
> along with it. I'm also in favor of an s-expression based syntax that
> uses less parens all together. In other words, I think a way to
> proceed might be to have syntax be actually surface, and completely
> inter-changeable, such that if I prefer s-expressions, Dr Racket
> allows me to edit that way. If I prefer an infix representation, Dr
> Racket can read the s-expressions and convert it to infix, and convert
> it back on save (Or the other way around depending on the code base
> preferences).

Scribble is an example of how two syntaxes can coexist in one source file.

-- hendrik

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20190721134310.r275b7qt2vji3igl%40topoi.pooq.com.

Re: [racket-users] Racket2 possibilities: Honu

[Hendrik Boom]

On Sat, Jul 20, 2019 at 06:07:40PM -0400, Christopher Lemmer Webber wrote:
> Hi Matthew,
> 
> As someone who (unintentionally) caused maybe some of the debate to get
> out of hand (or did I?) I would like to open by saying that both your
> last email to the prior thread and also this email are both very
> encouraging.
> 
> I'll skip everything else and jump straight to:
> 
> Matthew Flatt writes:
> 
> > How to Proceed
> > --
> >
> > Ideally, we would first decide on whether we want to try changing
> > surface syntax ever. Then, only if we have enough consensus that it's
> > worth a try, we could move on to setting overall goals and picking a
> > roadmap. Finally, if the planing of the roadmap succeeds, we could
> > follow it while getting into the details.
> >
> > Unfortunately, it doesn't work like that. We need concrete examples to
> > discuss the possibility of changing syntax, potential roadmaps to see
> > whether there's anywhere we want to go, and so on. Some of the
> > discussion will necessarily put a cart before a horse. Delving into
> > some details may incorrectly give the impression that prerequisites
> > are a foregone conclusion. We've seen all of that already, starting
> > with my attempt to open up the discussion in the middle of RacketCon
> > and probably continuing with this message. Perhaps we can just accept
> > that this is all okay in the spirit of working together.
> >
> > I originally thought that we should have a more specific process in
> > place for discussion at this point, but I think I've been proved
> > wrong. Let's just discuss, for now. I'll be posting more myself.
> 
> For the sake of discussion, maybe it's easiest to just assume "Racket
> attempts a move to a Honu derivative" as its surface syntax, which I'll
> call ~Honu for now.  (I'm not saying that we know that will happen, I
> just think it's a good place to start discussing.)  As you have already
> said, this will not prevent the existance of "#lang racket" keeping the
> syntax many in the community (including myself) already love.
> 
> As you said, changing the surface syntax is high-risk, possibly
> high-reward.  I agree with that, though I think Racket is uniquely
> positioned to lower the risk dramatically *because* of the #lang
> infrastructure.  Is a "try it before we fully buy it" approach maybe
> possible?  Maybe, for one thing, this could reduce community anxiety
> and improve our chances to explore.
> 
> Here, maybe is a way it could be done:

I found a page about Honu here: https://docs.racket-lang.org/honu/index.html

It looks elegant.  But I'd have to try it out on some serious problem 
to see if it's as elegant as it looks. 

> 
>  - First, port the teaching languages and etc over to Honu.  Try
>teaching some classes with just-Honu syntax.  This is *before*
>trying to switch the "internals" of Racket over.

I'd start "porting" the main language over.  It's essential to get 
early experience with nontrivial use.

>  - Encourage a large portion of the community to try to write as many
>tools using ~Honu as possible.  How do people like it?  What can be
>improved?
>  - Begin switching the core docs over, maybe even as a fork.  It might
>be a pain to maintain two doc forks, but maybe it is worth it.
>I suspect that Scribble might even make the task easier, since
>autogenerating two manuals from mostly the same source might not
>be too hard.

You would wnt a fork, if only to keep the *large* collection of 
existing #lang racket users ans developers happy.

If you are careful in maintaining line-by-line integrity between Racket 
documentation and Honu documentation, you might not find it difficult 
to merge Racket documentation updates into the Honu documentation 
repository.

And you would want to be able to autogenerate *three* manuals:  a 
Racket manual, a Honu manual, and a manual for both together.  It's 
quite likely people will want to use the two together.

>  - Switch all the default examples on racket-lang.org over to ~Honu.
>  - 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.
> 
> What do you think?  This seems like a clean transition plan to me that
> also allows for us to test, readjust, and even allows us to "stage
> before we commit", which seems like a big win.
> 
> Thoughts?
>  - 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20190721133827.625ekvgc74aya5sy%40topoi.pooq.com.

Re: [racket-users] Racket2 possibilities

[Matthew Flatt]

At Sat, 20 Jul 2019 18:07:40 -0400, Christopher Lemmer Webber wrote:
> As you said, changing the surface syntax is high-risk, possibly
> high-reward.  I agree with that, though I think Racket is uniquely
> positioned to lower the risk dramatically *because* of the #lang
> infrastructure.  Is a "try it before we fully buy it" approach maybe
> possible?  Maybe, for one thing, this could reduce community anxiety
> and improve our chances to explore.
> 
> Here, maybe is a way it could be done:
> 
>  - First, port the teaching languages and etc over to Honu.  Try
>teaching some classes with just-Honu syntax.  This is *before*
>trying to switch the "internals" of Racket over.
>  - Encourage a large portion of the community to try to write as many
>tools using ~Honu as possible.  How do people like it?  What can be
>improved?
>  - Begin switching the core docs over, maybe even as a fork.  It might
>be a pain to maintain two doc forks, but maybe it is worth it.
>I suspect that Scribble might even make the task easier, since
>autogenerating two manuals from mostly the same source might not
>be too hard.
>  - Switch all the default examples on racket-lang.org over to ~Honu.
>  - 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.)

But a separate branch to try porting examples and modules and to
explore new documentation certainly makes sense at some point.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5d3461aa.1c69fb81.a32b9.44c1SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

Re: [racket-users] Racket2 possibilities

[Andrew Gwozdziewycz]

Thank you for writing this.

On Sat, Jul 20, 2019 at 11:49 AM Matthew Flatt  wrote:

> Possible Language Changes
> -
>
> The Racket community has long discussed possibilities for Racket2. Here
> are a few potential changes from the wish list:

I like this list of changes. I'd feel great about Racket 2 if it
doubled down on removing concrete types in favor of interfaces /
abstract types. I'd feel great about Racket 2 if pattern matching was
core, and I didn't have to think about `case-lambda` and friends. I'd
feel great about structures / records if I didn't have a million
different options when defining them. I'd feel great about Racket 2 if
we introduced "arc"-like accessors, and conveniences that removed the
need for nested function calls (e.g. `(foo-name afoo)` vs
`afoo.name`)...

I'd feel great about Racket 2 if it maintained the curation and
simplicity of R*RS Scheme, but with modern conveniences that reduced
keystrokes and line width without giving up expressivity.


> Surface Syntax
> --
>
> You won't find a wish for significant changes the Racket surface
> syntax anywhere on the Racket2 wish list. Nevertheless, I've suggested
> tacking it on.

I'm in favor of a different syntax if it doesn't add new semantics
along with it. I'm also in favor of an s-expression based syntax that
uses less parens all together. In other words, I think a way to
proceed might be to have syntax be actually surface, and completely
inter-changeable, such that if I prefer s-expressions, Dr Racket
allows me to edit that way. If I prefer an infix representation, Dr
Racket can read the s-expressions and convert it to infix, and convert
it back on save (Or the other way around depending on the code base
preferences).

As Lispers we've all argued that surface syntax doesn't matter for
years, trying to get people to not see our choices as "Lots of
Infuriating Stupid Parentheses." So, why not go all in on this and
show that we really believe it?

I realize I'm asking for a pony, _and_ a horse...

-- 
http://www.apgwoz.com

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CADoGzscCM%3D53pBq5tVvxhVMiUc4A3bJocKo5RL3qtmpzNdJoAA%40mail.gmail.com.

Re: [racket-users] Racket2 possibilities

[Jay McCarthy]

As a procedural matter, I think that the Github repository is a great
way to communicate about specific ideas in way that ideas stay
connected and don't get forgotten.

https://github.com/racket/racket2-rfcs/

Right now, basically all of the discussion is in the issues, as people
work together to gather ideas. I think eventually we need to try to
write longer-form proposals about the details.

I think Matthew's point about trying to write down some concrete
examples would be extremely valuable as issues to spur discussion.

--
Jay McCarthy
Associate Professor @ CS @ UMass Lowell
http://jeapostrophe.github.io
Vincit qui se vincit.

On Sat, Jul 20, 2019 at 2:49 PM Matthew Flatt  wrote:
>
> This message is intended as a prose form of what I said at RacketCon,
> but it includes some extra explanation triggered by the discussion so
> far. Where that happens, I apologize that it isn't in the form of a
> more direct response in the original thread.
>
> The Racket2 Idea
> 
>
> Racket's design and implementation is on solid ground, and from this
> point, it can continue to evolve and improve in many ways. No matter
> how Racket evolves, the community is committed to preserving what we
> have achieved: today's `#lang racket` programs will run in the future,
> and today's `#lang racket` modules can be used in future Racket
> programs. At the same time, the current language design may be close to
> a local maximum, and it's not in the nature of the Racket community to
> be satisfied with a local maximum.
>
> By starting all programs with `#lang`, we have created a path to leap
> from one peak of design to a different, higher peak without sacrificing
> the old one and while staying Rackety. Roughly, that's what we mean by
> "Racket2". The name "Racket2" stands for some language that builds on
> the current Racket technology and implementation, but that may not
> directly accommodate the same bindings and expression forms that appear
> in the body of a `#lang racket` module.
>
> Although we could literally write `#lang racket2` for modules in the
> new language, "Racket2" is normally understood as a placeholder for a
> more distinct name. As a matter of branding, perhaps the language would
> be called "Racket X" for some good X --- shortened to "X" in some
> contexts --- and Racket X program would be written with `#lang X` line
> at the top. Maybe the name depends on how different Racket2 turns out
> to be from Racket, so it makes sense to pick a name later.
>
> Venturing out from Racket's current peak opens a large space of
> possibilities, so the first step is to agree on a set of goals to be
> met by the next peak. The goals can serve as a starting point for
> developing roadmap for deciding on technical details in a follow-up
> process.
>
> Possible Language Changes
> -
>
> The Racket community has long discussed possibilities for Racket2. Here
> are a few potential changes from the wish list:
>
> * Rename functions to make the conventions more uniform, and make
>   better use of keyword arguments to reduce names and increase
>   consistency.
>
> * Change structures types to have more or fewer features.
>
> * Use generic datatypes (such as streams) pervasively, instead of
>   writing code that expects a particular concrete representation (such
>   as lists).
>
> * Make strings immutable by default (e.g., result of `format` or
>   `string-append`).
>
> * Adjust the semantics of common syntax forms, such as raising an error
>   on fall-through for `cond` or `match`, and change the meaning of some
>   primitives, such as making `integer?` mean "exact integer".
>
> * Make pattern matching more pervasive and available by default.
>
> * Change module, evaluation, and loading callbacks (e.g., protocol for
>   `current-module-name-resolver`) to improve errors and extensibility.
>
> More changes have been suggested, and no doubt many other changes would
> make sense. As a first cut, to synthesize some principles from these
> ideas --- as a way of selecting which wishes should be tackled and how
> --- the current wish list might be organized and summarized by two
> overall goals:
>
> * Make the language more consistent
>
>   Consistency means making terminology and binding names more
>   consistent, and it means unifying related syntactic constructs. For
>   example, the `define` and `define-syntax` forms should perhaps be
>   less syntactically distinct. Similarly, pattern matching and syntax
>   matching seem closely related and could benefit from using the same
>   pattern language. Also, pattern matching should be pervasively
>   available among binding forms. Etc.
>
> * Make the language constructs more generic
>
>   In many ways, the current Racket language and libraries encourage
>   the use of concrete data structures instead of abstract datatypes.
>   The `map` function works on lists, for example, not arbitrary
>   streams, and even `for` demands concrete declarations like 

Re: [racket-users] Racket2 possibilities

[stewart mackenzie]

Let's keep this light and fun, especially for the implementor, who
shouldn't be bogged down with parens-or-die commentry. How about treating
it as yet another #lang, albeit one of interest as core members have an
itch to scratch. Let's cross the bridge of moving docs/website/drastic
stuff when there's an implementation that passes muster. Choose a silly and
fun code name to start off with, a bit of self deprecation and irony goes
far. The new language needs to earn the title of racket2, a name with much
gravity.

I'm looking forward to #lang not(racket2) as, certainly, I'll learn new
things. A whole new world drawing from the best of research and Racket.

With that, bloody well have at this problem Matthew, more power to you.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CA%2BLh%3Dn2Oh_syWvM_dUGeahBHKX%3DpBJyrA1-3J1atBeeuYuGrHg%40mail.gmail.com.

Re: [racket-users] Racket2 possibilities

[Christopher Lemmer Webber]

Hi Matthew,

As someone who (unintentionally) caused maybe some of the debate to get
out of hand (or did I?) I would like to open by saying that both your
last email to the prior thread and also this email are both very
encouraging.

I'll skip everything else and jump straight to:

Matthew Flatt writes:

> How to Proceed
> --
>
> Ideally, we would first decide on whether we want to try changing
> surface syntax ever. Then, only if we have enough consensus that it's
> worth a try, we could move on to setting overall goals and picking a
> roadmap. Finally, if the planing of the roadmap succeeds, we could
> follow it while getting into the details.
>
> Unfortunately, it doesn't work like that. We need concrete examples to
> discuss the possibility of changing syntax, potential roadmaps to see
> whether there's anywhere we want to go, and so on. Some of the
> discussion will necessarily put a cart before a horse. Delving into
> some details may incorrectly give the impression that prerequisites
> are a foregone conclusion. We've seen all of that already, starting
> with my attempt to open up the discussion in the middle of RacketCon
> and probably continuing with this message. Perhaps we can just accept
> that this is all okay in the spirit of working together.
>
> I originally thought that we should have a more specific process in
> place for discussion at this point, but I think I've been proved
> wrong. Let's just discuss, for now. I'll be posting more myself.

For the sake of discussion, maybe it's easiest to just assume "Racket
attempts a move to a Honu derivative" as its surface syntax, which I'll
call ~Honu for now.  (I'm not saying that we know that will happen, I
just think it's a good place to start discussing.)  As you have already
said, this will not prevent the existance of "#lang racket" keeping the
syntax many in the community (including myself) already love.

As you said, changing the surface syntax is high-risk, possibly
high-reward.  I agree with that, though I think Racket is uniquely
positioned to lower the risk dramatically *because* of the #lang
infrastructure.  Is a "try it before we fully buy it" approach maybe
possible?  Maybe, for one thing, this could reduce community anxiety
and improve our chances to explore.

Here, maybe is a way it could be done:

 - First, port the teaching languages and etc over to Honu.  Try
   teaching some classes with just-Honu syntax.  This is *before*
   trying to switch the "internals" of Racket over.
 - Encourage a large portion of the community to try to write as many
   tools using ~Honu as possible.  How do people like it?  What can be
   improved?
 - Begin switching the core docs over, maybe even as a fork.  It might
   be a pain to maintain two doc forks, but maybe it is worth it.
   I suspect that Scribble might even make the task easier, since
   autogenerating two manuals from mostly the same source might not
   be too hard.
 - Switch all the default examples on racket-lang.org over to ~Honu.
 - 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.

What do you think?  This seems like a clean transition plan to me that
also allows for us to test, readjust, and even allows us to "stage
before we commit", which seems like a big win.

Thoughts?
 - 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/87tvbgz7f7.fsf%40dustycloud.org.

Re: [racket-users] Racket2 possibilities

[Neil Van Dyke]

Matthew Flatt wrote on 7/20/19 2:49 PM:

We need concrete examples to discuss the possibility of changing syntax, 
potential roadmaps to see whether there's anywhere we want to go, and so on.


Procedural suggestions people might want to do:

* There's a lot of prior work, and it might really help discussion if we 
all have a shared baseline awareness of it.  Does someone have a 
comprehensive list of links (or want to assemble such a list) of the 
noteworthy attempts at non-paren syntax in Lisps?  (Offhand, but I know 
there's more: Honu, Shriram's work, the SRFI one, Python (which Norvig 
called a Lisp), Dylan's change, M-expressions, and some of the countless 
others, especially in CL.)  Also, maybe there's also some separate work 
in good syntax transformers for non-sexp that we should all know about 
at this point?


* With that shared baseline, would people like to highlight on 
"racket-users" promising ideas from that prior work, as well as post 
their own ideas (informed by prior work)?


* In group creative brainstorming, there's a procedural thing that's 
sometimes really helpful.  Basically, there's a phase/mode in which the 
top goal is to elicit ideas, and no critical commentary is permitted.  I 
don't presume to suggest any rules, and probably shouldn't be a hard 
rule in this case, but maybe many people will just tend to lean towards 
that, organically, initially.  Then, a little later, get more into 
critiquing, and see what new ideas/insights that then generates.  (Where 
this idea comes from, there's also a bunch of other modes and roles, and 
ways to be aware of and explicitly signal what kind of contribution 
you're making, but, to start with, I just wanted to toss out this one 
very simple idea.)


--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/3dd5f0ea-5a65-5cd5-258d-f5c466bba2a7%40neilvandyke.org.