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.

[racket-users] Re: Racket2 possibilities

[Brian Adkins]

On Monday, July 22, 2019 at 6:17:47 PM UTC-4, Zelphir Kaltstahl wrote:
>
> I just want to give one thought as input to this discussion and will 
> admit, that I did not read every (but some) of the posts above.
>
> When I write code in Racket or Scheme, I mostly like the parentheses, as 
> they make writing the code easy. I can very easily select a block and move 
> it around, without introducing any syntax errors. I can also quickly see 
> what the scope of something is, what other expression it is in. I don't get 
> these things from languages without this many parentheses or without 
> s-expression syntax. I need my parentheses as markers for my cursor to 
> quickly jump around. It is the most pleasant code typing experience I've 
> ever had. So when considering to move away from parentheses, please also 
> consider the burden that those parentheses take away from the person 
> writing the code. When I edit for example Python code, things are not clear 
> when moving around code. This is worse in Python than in other languages, 
> which at least have curly braces (but usually some other annoying 
> deficiencies). If there was a move away from this many parentheses (read 
> markers for my cursor), it would have to provide equal editability, for it 
> to be attractive to me. A design based on indentation or something like 
> that is not going to cut it for me. And what else would be used as start 
> and end markers for expressions? Wouldn't that in essence just be another 
> form of "parentheses", just looking different? How would any editor know, 
> where an expression starts and ends for easy selection and moving around, 
> if there were no such markers? So far I got no idea how that could be done 
> without introducing loads of new constraints about how you can nest 
> expressions into the language. So it beats me. Maybe my imagination in this 
> area is still somewhat limited.
>
> Just my 2c.
>

 Zelphir:

Since you mentioned you haven't read all the posts (and who could blame 
you, there's a lot!), I wanted to mention that the core team has stated you 
will continue to be able to program in #lang racket with s-expressions, and 
it will continue to be "well supported."

If Racket, with it's Scheme heritage, can't continue to support a 
Scheme-like programming experience, what that would say about language 
oriented programming?

As Matthew said, "Don't Panic" :)

Thanks,
Brian

-- 
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/2f538039-5d73-4273-ae9d-d1dd0febdef4%40googlegroups.com.

Re: [racket-users] Scribble reinstallation

[Ben Greenman]

You should be able to keep the current Racket,
download a snapshot build,
and run the `/bin/drracket` inside the snapshot

https://www.cs.utah.edu/plt/snapshots/

-- 
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/CAFUu9R7mnyoeUwP%2B%3DmAFDJv%2BgCZ_OQ7UHDDA80zErrSo_mzQGw%40mail.gmail.com.

Re: [racket-users] Re: Racket2 possibilities

[Breck Yunits]

Hi Zelphir,

Your concerns are absolutely warranted.

>From what I've seen there is no advantage that editors can give you with
parens, that they can't do better without parens, *given that you've
written loads of tests and done the grunt work to make that happen*.

Hence, it doesn't make sense to advocate for removing parens for Racket2
until all the code and tests are written for the different editors that
make the parens-less experience fantastic, and folks can compare the 2 side
by side. So if folks are working toward that, please let me know as I'd
love to help out.

-Breck

On Mon, Jul 22, 2019 at 12:17 PM Zelphir Kaltstahl <
zelphirkaltst...@gmail.com> wrote:

> I just want to give one thought as input to this discussion and will
> admit, that I did not read every (but some) of the posts above.
>
> When I write code in Racket or Scheme, I mostly like the parentheses, as
> they make writing the code easy. I can very easily select a block and move
> it around, without introducing any syntax errors. I can also quickly see
> what the scope of something is, what other expression it is in. I don't get
> these things from languages without this many parentheses or without
> s-expression syntax. I need my parentheses as markers for my cursor to
> quickly jump around. It is the most pleasant code typing experience I've
> ever had. So when considering to move away from parentheses, please also
> consider the burden that those parentheses take away from the person
> writing the code. When I edit for example Python code, things are not clear
> when moving around code. This is worse in Python than in other languages,
> which at least have curly braces (but usually some other annoying
> deficiencies). If there was a move away from this many parentheses (read
> markers for my cursor), it would have to provide equal editability, for it
> to be attractive to me. A design based on indentation or something like
> that is not going to cut it for me. And what else would be used as start
> and end markers for expressions? Wouldn't that in essence just be another
> form of "parentheses", just looking different? How would any editor know,
> where an expression starts and ends for easy selection and moving around,
> if there were no such markers? So far I got no idea how that could be done
> without introducing loads of new constraints about how you can nest
> expressions into the language. So it beats me. Maybe my imagination in this
> area is still somewhat limited.
>
> Just my 2c.
>
> --
> 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/bf0b5dd1-8802-4c78-af7a-4231ae30ad60%40googlegroups.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/CAOgHByu0RLROGMvdXxO0uCTDGN69u%3DgAp8c%2B9vtiSzSPRF91Dg%40mail.gmail.com.

[racket-users] Re: Racket2 possibilities

[Zelphir Kaltstahl]

I just want to give one thought as input to this discussion and will admit, 
that I did not read every (but some) of the posts above.

When I write code in Racket or Scheme, I mostly like the parentheses, as 
they make writing the code easy. I can very easily select a block and move 
it around, without introducing any syntax errors. I can also quickly see 
what the scope of something is, what other expression it is in. I don't get 
these things from languages without this many parentheses or without 
s-expression syntax. I need my parentheses as markers for my cursor to 
quickly jump around. It is the most pleasant code typing experience I've 
ever had. So when considering to move away from parentheses, please also 
consider the burden that those parentheses take away from the person 
writing the code. When I edit for example Python code, things are not clear 
when moving around code. This is worse in Python than in other languages, 
which at least have curly braces (but usually some other annoying 
deficiencies). If there was a move away from this many parentheses (read 
markers for my cursor), it would have to provide equal editability, for it 
to be attractive to me. A design based on indentation or something like 
that is not going to cut it for me. And what else would be used as start 
and end markers for expressions? Wouldn't that in essence just be another 
form of "parentheses", just looking different? How would any editor know, 
where an expression starts and ends for easy selection and moving around, 
if there were no such markers? So far I got no idea how that could be done 
without introducing loads of new constraints about how you can nest 
expressions into the language. So it beats me. Maybe my imagination in this 
area is still somewhat limited.

Just my 2c.

-- 
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/bf0b5dd1-8802-4c78-af7a-4231ae30ad60%40googlegroups.com.

Re: [racket-users] Re: (ninth RacketCon) videos

[Jens Axel Søgaard]

>
>
> On Friday, July 19, 2019 at 12:19:44 PM UTC-7, Matthew Flatt wrote:
>>
>> Individual videos for this year's RacketCon talks are now available:
>>
>>  https://www.youtube.com/playlist?list=PLXr4KViVC0qJp4_2uTTAOjt-4URQBAR4c
>>
>
Den man. 22. jul. 2019 kl. 23.36 skrev Kees-Jochem Wehrmeijer <
henc...@gmail.com>:

> Thanks very much! Will your talk also be available Matthew? After all the
> racket2 talks it sparked here, I'm kind of curious.
>

It's available here:

https://www.youtube.com/watch?v=dnz6y5U0tFs

/Jens Axel

-- 
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/CABefVgxpvXZg6Dqz-paDqzLAV6dOULKDOCxSsK6L1D2thQbyRA%40mail.gmail.com.

[racket-users] Re: (ninth RacketCon) videos

[Kees-Jochem Wehrmeijer]

Thanks very much! Will your talk also be available Matthew? After all the 
racket2 talks it sparked here, I'm kind of curious.

On Friday, July 19, 2019 at 12:19:44 PM UTC-7, Matthew Flatt wrote:
>
> Individual videos for this year's RacketCon talks are now available: 
>
>  https://www.youtube.com/playlist?list=PLXr4KViVC0qJp4_2uTTAOjt-4URQBAR4c 
>
>

-- 
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/1705e13e-f51b-48d2-be8f-e3515746707f%40googlegroups.com.

[racket-users] Re: Racket2 possibilities

[Breck Yunits]

Aloha folks,

I had to miss RacketCon this year as we have a new 6 month old at home and 
couldn't make the trek out.

But I would love to lend my efforts to support the initiative to explore a 
Racket universe without parens. If folks out there are working on this, 
shoot me an email (bre...@gmail.com or yun...@hawaii.edu) and let me know 
how I can best help.

I've been working on such a research effort since 2012. I call the notation 
Tree Notation http://treenotation.org/. Basically what I propose is 
splitting things up into 2 concepts: the base Tree Notation (which is 80% 
similar to I-Expressions), and then languages on top of that (which is 
where the #lang could come in).

This syntax is less fragile (
https://twitter.com/breckyunits/status/1153016840769007616) and makes 3 
things much easier: program synthesis, data science, and visual programming.

I think dropping parens would make a big difference and would be a great 
move for "Racket2"!

-Breck



On Saturday, July 20, 2019 at 8:49:13 AM UTC-10, 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 

Re: [racket-users] on reducing barriers in the Racket community

[Neil Van Dyke]

Matthew Butterick wrote on 7/21/19 4:46 PM:

But as was true for a lot of kids like me during that era, computers were a 
refuge. They never judged me. They rewarded my curiosity.


There's a complementary acceptance component to the microcomputer 
revolutions, which I think are relevant to Racket/tech community 
inclusiveness...


As people first started to get online, and find social-heavy topical 
interest circles, it disproportionately attracted people who were 
diverse in ways that weren't accepted as much in "real life".


For example, in some techie social circles, that we knew of, there were 
quite a lot of people who were eventually open online about being gay 
(when that wasn't OK where they lived), or being transgender (before 
most of society even knew that existed), and it was fine -- whether 
people were there for the topic/socializing alone, or because they felt 
drawn to an Island of Misfit Toys themselves.


Right now, most of the world is running software some of those people 
helped write, when society didn't accept them at the time. And one of 
them, a person who seemed to have a bit of anxiety, and perhaps was 
socializing online because of that, turned out to start a groundbreaking 
technology most of the world is now using.  Another one, who was a very 
nerdy girl who sought out other nerds, has since become a celebrated 
entrepreneur you've probably heard of.  And another woman, who was a 
serious math nerd, who is currently giving tech industry conference 
talks on big things.  And people all over the world, including at least 
one who later turned out to be nobility in their original country, but 
was somewhat restricted due to being female.  (Younger people with early 
online access were often children of university employees or computer 
industry people, or of wealthy classes who could go all-out on the 
child's home computer, mixed in with adult computer nerds.)  And one 
child actor would occasionally drop by one group, as a typical nerdy 
computer kid in real life, before most people could Tweet at 
celebrities' PR personae.  Fortunately, for parochial me, everyone spoke 
English.


There was also not yet things like Facebook presences (perpetuating 
primary/high school looks/popularity contests well into adulthood), so 
we often didn't even know what people looked like, and just took people 
on the merits of what they said.  Which resulted in some funny 
revelations, like the person you visualized like another stereotypical 
computer nerd, who turned out to be very conventionally attractive and 
charismatic (and who, of course, became an executive at a prominent 
dotcom).  Or the exceptionally kind and thoughtful person, who it turned 
out looked like what one might've thought (with one's real-world 
prejudices and stereotypes) was some scruffy metalhead.  (Which makes me 
think contemporary social media would be healthier and more beneficial, 
if people didn't post photos of themselves, compete for "influencer" 
funding, etc.)


Today, now that I'm in my 40s, it turns out that half of the American 
techies I socialize with frequently identify as some flavor of 
conservative -- which I would've found alarming years ago (I identify as 
very liberal/progressive, in the American sense).  One, for example, is 
very smart and thoughtful, seems like a great family person, and seems 
implicitly totally comfortable with gay/trans/whatever, but will 
frequently rant about what he sees as progressive grandstanding in the 
news.  I still don't agree with him on a lot of what's a problem and 
needs to be said in society right now, and what doesn't, but it turns 
out that conservatives overall are not so bad.


In pre-"social media" online, we sometimes made mistakes (including 
inadvertently being very unwelcoming in some ways, including by myself 
sometimes, I'm still embarrassed to recall), and of course there are 
always human conflicts and dramas, but we learned a lot about what 
communities can be, and that a lot of dumb real-world prejudices outside 
our community exist, and don't have to be that way.


--
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/3c08818f-8177-27a8-54d5-3cdab42ff2ab%40neilvandyke.org.

[racket-users] https://github.com/racket/racket2-rfcs/blob/master/prior-art.md

[Stephen De Gabrielle]

FYI

https://github.com/racket/racket2-rfcs/blob/master/prior-art.md

-- 


-- 
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/CAGHj7-LKb%3DbbYw7HEOSpDhkQgj8ePZcyksOJyguBwqeM6Y32jA%40mail.gmail.com.

Re: [racket-users] #lang something // infix, optionally indentation-sensitive experimental Racket syntax

[Stephen De Gabrielle]

On Mon, 22 Jul 2019 at 18:39, Neil Van Dyke  wrote:

> The shell demo is great.  I can't look closely at `#lang something`
> quite yet, and I hope someone will include it in a list of the most
> interesting prior work for everyone interested in new syntax to look at.
>

Done:

https://github.com/racket/racket2-rfcs/blob/master/prior-art.md#lang-something

Kr

S.


> --
> 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/dfc442cb-a7e3-9d86-2016-f72a51b58d18%40neilvandyke.org
> .
>
-- 


-- 
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/CAGHj7-J_fT0QSCNFVZqdcsvBzEd_CHpugchVWCSBOqyk7OV0sg%40mail.gmail.com.

Re: Backing up [was: Re: [racket-users] The case, and a proposal, for elegant syntax in #lang racket2]

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


--
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/42718b82-14f9-df3e-7d5c-5b18a73870b2%40neilvandyke.org.

Re: [racket-users] on reducing barriers in the Racket community

[Brian Adkins]

On Monday, July 22, 2019 at 1:07:21 PM UTC-4, Caleb Allen wrote:
>
> As an additional data point, I can share my very fast introduction into 
> Racket and the community. You asked for experiences where the community may 
> have made people feel unwelcome, but mine is a positive experience. I share 
> it to perhaps give an angle of what *is* right, and the parts of the 
> racket community which helped me go from an "outsider" to feeling welcome 
> and secure. My brief experience with this community has been wonderful, and 
> I want to contribute to making that experience the norm, if it is not 
> already. [...]
>

Thanks for articulating your thoughts so well Caleb.

Although my recent comments have probably focused more on technical 
aspects, the Racket community was *very* high on my priority list when I 
was looking for my next language. I was appreciative of answers I received 
to questions on the mailing list and/or IRC channel, and it was clear that 
top contributors were (and are) willing to take the time to deal with my 
newbie questions, and that, in turn, inspired me to want to get to the 
point where I could give back in a similar fashion (not quite there yet!).

>From *my* perspective, the Racket community has good *and* long track 
record, and I don't expect the current *hiccup* to change that :) And, if 
others have unfortunately had a worse experience, my sense is that we as a 
community are motivated to change that.

-- 
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/11612770-b1be-4fc1-9304-a9125e000ca5%40googlegroups.com.

Re: [racket-users] #lang something // infix, optionally indentation-sensitive experimental Racket syntax

[Neil Van Dyke]

The shell demo is great.  I can't look closely at `#lang something` 
quite yet, and I hope someone will include it in a list of the most 
interesting prior work for everyone interested in new syntax to look at.


--
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/dfc442cb-a7e3-9d86-2016-f72a51b58d18%40neilvandyke.org.

Re: Backing up [was: Re: [racket-users] The case, and a proposal, for elegant syntax in #lang racket2]

[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 :(

-- 
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/78d3b84c-9e96-40f9-bc0c-56fb8befce3e%40googlegroups.com.

Re: [racket-users] on reducing barriers in the Racket community

[Caleb Allen]

As an additional data point, I can share my very fast introduction into
Racket and the community. You asked for experiences where the community may
have made people feel unwelcome, but mine is a positive experience. I share
it to perhaps give an angle of what *is* right, and the parts of the racket
community which helped me go from an "outsider" to feeling welcome and
secure. My brief experience with this community has been wonderful, and I
want to contribute to making that experience the norm, if it is not already.

A few short months ago I came across The Little Schemer as recommended by a
mentor of mine, and in my subsequent Scheme research came across your
Racket Con videos on Pollen. Your enthusiasm made me feel okay about being
enthusiastic myself! I watched a dozen or so Racket Con talks from as many
speakers. Seeing how enthusiastic and dynamic the speakers were showed me
that it was the entire community, not any single person, pushing this
forward with passion and care. This apparent diversity of people and
opinion was in stark contrast to many of the language communities I'd
studied or participated in up to this point, which I'm sure you could guess.

As others have alluded to, the documentation might have intimidated me (as
any documentation for a new language does), and my foray was instead
through video. When I landed on the racket homepage and saw that Racket
Week was just weeks away in my own city of Salt Lake, I knew I'd have to
go, despite my uneasiness. For context, I attended the University of Utah
in parallel with an internship at a startup, but dropped out after two
years to go full time at the startup. In light of that decision I was
nervous about being back on campus among academics I admired, and I
questioned whether I was really qualified to even attend.

Each day of Racket Week put me more at ease, as I found mutual interests
with other attendees and had interesting conversations that continued after
the week was up. During introductions on day one (in the LOP course), I
took note of people I'd like to pester about interesting things, and the
conversations during off-time and meals had me stumbling into some of the
coolest projects, ideas and passions I've ever heard. The week, for me, was
a resounding success, and I hope to be integrating myself further into the
community as the months and years go by.

>From my perspective, the nature of the language itself may have been the
biggest intimidating factor: there is a long history of very, very smart
people who are very passionate about pushing this forward. Nobody enjoys
making a fool of themselves and my biggest worry was asking a stupid
question or being too unfamiliar with tooling. From the technical
perspective, DrRacket did more for me as a gentle (but powerful)
introduction to Racket than anything else I've used with any language. When
I did encounter problems, the documentation and its ease of access from
DrRacket made my previous documentation experience feel like reading a
thesaurus, when I really wanted an encyclopedia. Racket's tooling is in a
league of its own in terms of usability, and it was not a factor in
deterring me.

I'd echo Dexter's sentiment to add some practical, hard examples somewhere,
aimed at users of C like languages. I'm convinced of the power of LOP now
that I've gotten the full context from Matthias during Racket Week and I
will be using it extensively. But documentation of macros and building my
own language was difficult to reason about on my early encounters, when I
was still fighting the urge to slap curly braces somewhere in my code. I
don't know how that gets solved, because Racket's power was both its draw
as well as what intimidated me.

I may have been lucky in being in the right place at the right time, but I
wanted to voice my appreciation for what has been done so far. I heard
about Racket was less than two months ago and now I feel more enthusiastic
than I have since learning TI-Basic on my TI-84 and sharing games with my
friends in high school. This experience wasn't without a good dose of
anxiety, but making friends in the community made all the difference.

Caleb


On Sun, Jul 21, 2019 at 2:46 PM Matthew Butterick  wrote:

> I'm not a member of Racket management. But I spend a lot of time using &
> promoting Racket. Most recently, I taught the Beautiful Racket Workshop as
> part of Racket Week 2019.
>
> I care a lot about Racket — the technology, but especially the human
> community that makes it possible.
>
> I've heard from a few people that events before, during, or after Racket
> Week left them questioning Racket's commitment to making everyone feel
> welcome. And to be honest, it wasn't the first time.
>
> This saddens me. It's not consistent with my own values. It's not what I
> want Racket to stand for. I want everyone to feel welcome, wanted, and
> valued.
>
> In a nearby thread, Matthew Flatt talked about the importance of "reducing
> barriers" in a technical sense. But it 

Re: [racket-users] Re: Gui editable grid/table

[James Platt]

There is also qresults-list, which is from Alex Harsanyi's ActivityLog2 
application.  You can see how it is used in that application.

https://pkgs.racket-lang.org/package/qresults-list
https://github.com/alex-hhh/ActivityLog2

On Jul 22, 2019, at 7:22 AM, Roman Klochkov wrote:

> https://pkgs.racket-lang.org/package/multicolumn
> 
> суббота, 20 июля 2019 г., 8:17:58 UTC+5 пользователь Raoul Schorer написал:
> Hi,
> I am trying to make a gui editable table. Is that possible in racket/gui?
> 
> It seems list-box% is not editable by default. Apparently, one can't stick 
> editors as list-box% choices either.
> 
> Can you please help?
> 
> Thanks!
> Raoul
> 
> 
> 
> 
> 
> -- 
> 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/d827b9f5-7a58-4b77-927f-b1122a8885c7%40googlegroups.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/BA4BCCE1-706A-4018-A08F-BF38EF802E98%40biomantica.com.

[racket-users] Racket2 and Perl6

[David Storrs]

The current process of Racket2 development is something I've been through
before; it is *exactly* what happened when Perl6 was announced.  It might
be instructive for people to dig into that process a bit and see what the
methods and discussions were all about, since it ended up working pretty
well.  Reaching out to Larry Wall and/or Damian Conway is strongly
recommended.

The way it ended up being handled was this:

1) The community was invited to submit RFPs on whatever topics they
wanted.  What came over the transom ranged from the trivial ("Allow $1 and
/1 to mean the same thing in regexen") to the mildly important ("Perl
should stay Perl, by which I mean the following things should remain
constant: x,y,z..."), to the very heavyweight indeed ("continuations should
become first-class values and here's how we do that").

2) Volunteers read the RFPs and collected them into groups.

3) Larry Wall, creator of Perl and its guiding-light-but-not-dictator,
digested each group in turn and then created a document called an
Apocalypse (in the original biblical sense of 'revelation', not the modern
sense of 'disaster' -- Larry is a quirky guy) which laid out a plan for how
those RFPs would or would not make their way into the language.  This
document was designed for language designers and implementers and filled
essentially the same role as the Racket Reference.

4) Damian Conway, one of the most brilliant Perl module creators, read the
Apocalypse and worked with Larry to file off any rough spots.  He then
produced a document called an Exegesis that was designed to explain the
Apocalypse to the general programmer.  If this sounds like the Racket
Guide, it was.

5) The Apocalypse and the Exegesis were released at the same time.

6) There was a lot of discussion and revision, and the final result made it
into the Perl6 Design document, where it was locked and not open for
further discussion.  Larry had enough moral authority and brains that
people would typically anchor on his design, so the discussion was about
refinements and edge cases instead of fundamental details.  His main
contribution after the release was clarification, prevention of
bikeshedding, and responding to critique.  Because there was an anchor
point for the discussion, things typically stayed pretty calm and didn't
wind on for too long.


Note that the Apocalypses were based off of the RFPs; Larry was not
creating something out of whole cloth, he was using his expertise as a
language designer to integrate what the community wanted and put it into a
usable form.  Yes, he sometimes made the decision that a particular RFP
would not be accepted; those decisions were explained and there was usually
very little objection -- again, because Larry had a lot of respect from the
community and also because he always had damn good reasons that he was able
to clearly articulate.


The reasons for the creation of Perl6 were to:

1) Resolve warts in the language
2) Add significant new features
3) Make the language more appealing to the general programmer, since Perl5
was losing market share, based largely on its syntax -- people didn't like
the punctuation characters in variable names.[1]

If this sounds familiar...it should.

The most important part of #3 was the creation of Parrot, a new runtime
that would separate the interpreter from the underlying VM that executed
the compiled bytecode.  The goal was to allow Perl to run on top of the
JVM, the default Perl VM, or any other major VM that the community decided
was worth targeting.


Like I said above, it might be worth it to investigate the Perl6 design
process and see if there are any useful ideas and/or lessons to draw from.



[1] 98% of complaints that I've ever heard about Perl fall into one of two
buckets:

a. "It's so ugly and weird!  It uses all those
parentheses^H^H^H^H^H^H^H^H^H^H^H punctuation symbols!"

b. "I can't understand macros^H^H^H^H^H^H the idea of 'context' so I don't
get why '@foo = my_func()' does something different from '$foo =
my_func()'"

I have very little sympathy for either of these.  Again, they should sound
familiar.

-- 
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/CAE8gKofzGtBVVHUryL21KkzbnrpE9umCU30E11_6oqzo3kHNUA%40mail.gmail.com.

Re: [racket-users] Re: Racket2 possibilities

[Neil Van Dyke]

Maria Gabriela Guimarães wrote on 7/22/19 10:52 AM:
> I experimented with various scheme in browser intrepred via 
JavaScript and compiled to wasm both are not good enough.


Insufficient implementations I suppose, or wasm misses features 
important for a Scheme ...


What Maria said.  WASM (not JS) now seems the place for us to focus, for 
performance.  It's a little early for Schemes in WASM, and I don't know 
whether the best WASM methods for Schemes/Racket have yet been 
attempted, and if they'd have all the support in WASM they might want.


Once WASM is all ready, JS presumably will remain in the standards and 
in some use, but might actually become unpopular.  The browser 
developers have their own favored non-JS languages, and also heavily 
influence Web standards, so they might eventually make it so that JS can 
be all but eliminated.  And then, given that technical possibility, 
there's Web development culture: a hottest framework can become shunned 
within a year or two (and there's also rampant age discrimination, so 
many industry-savvy people truncate their older experience), so, 
half-seriously, I wouldn't be too surprised if JS becomes uncool to even 
admit knowing.


i don't know whether someone has yet dug into making a really performant 
WASM backend for Racket, and I'd guess people might want to wait for any 
interfaces/models from the Chez backend work to be about finalized first.


In the meantime, hopefully someone who needs the same WASM features such 
backend for Racket will want, has eaten or will eat the beetle grubs, in 
time: 
https://www.mail-archive.com/racket-users@googlegroups.com/msg36362.html


A little earlier context on WASM for Racket: 
https://www.mail-archive.com/racket-users@googlegroups.com/msg35803.html


There are pros about WASM, Web standards, influences, etc., and I 
suggest we want to keep cross-platform (not just Web browser, nor 
primarily Web browser) focus, for long-term reasons.  But it would be 
immediately very useful for many of us, if/when Racket gets a good WASM 
backend.  And, given the possible disruption of JS that I speculate 
about above, maybe that will also be an opportunity to bring Racket 
goodness to a lot more people.


--
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/e573db75-573e-f99a-d191-df1e6a944df8%40neilvandyke.org.

Re: [racket-users] Re: Racket2 possibilities

[Paulo Matos]

On 22/07/2019 16:52, Maria Gabriela Guimarães wrote:
> > I experimented with various scheme in browser intrepred via
> JavaScript and compiled to wasm both are not good enough.
>
> Insufficient implementations I suppose, or wasm misses features
> important for a Scheme ...
>
Someone wanting to take this on might gain inspiration from:
https://github.com/google/schism

> Em segunda-feira, 22 de julho de 2019 15:33:59 UTC+1, amz3 escreveu:
>
>
>
> On Monday, July 22, 2019 at 4:26:04 PM UTC+2, Mário Guimarães wrote:
>
>
> > And the JVM in browsers has been thoroughly supplanted by
> Javascript. 
>
> I missed another VM: Racket2 should also target WebAssembly.
>
>
> I experimented with various scheme in browser intrepred via
> JavaScript and compiled to wasm both are not good enough.
>
> -- 
> 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/9b5cdf22-8d78-42d8-86a0-bf5893a26f74%40googlegroups.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/23fd9641-49b5-4784-a705-7c2ffcd9e6fb%40linki.tools.

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] Re: Racket2 possibilities

[Maria Gabriela Guimarães]

> I experimented with various scheme in browser intrepred via JavaScript 
and compiled to wasm both are not good enough. 

Insufficient implementations I suppose, or wasm misses features important 
for a Scheme ...

Em segunda-feira, 22 de julho de 2019 15:33:59 UTC+1, amz3 escreveu:
>
>
>
> On Monday, July 22, 2019 at 4:26:04 PM UTC+2, Mário Guimarães wrote:
>>
>>
>> > And the JVM in browsers has been thoroughly supplanted by Javascript. 
>>
>> I missed another VM: Racket2 should also target WebAssembly.
>>
>
> I experimented with various scheme in browser intrepred via JavaScript and 
> compiled to wasm both are not good enough. 
>

-- 
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/9b5cdf22-8d78-42d8-86a0-bf5893a26f74%40googlegroups.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.

[racket-users] Scribble reinstallation

[Hendrik Boom]

On Thu, Jul 18, 2019 at 12:25:22PM -0600, Matthew Flatt wrote:
> > At Thu, 18 Jul 2019 12:28:53 -0400, Hendrik Boom wrote:
> > > Did some measurements.
> > > 
> > > 800K of text, represented as 80 scribble files each of 10K bytes,
> > > each included using @include-section from one file:
> > >   7 seconds.
> > > 
> > > 800K of text, represented as one scribble file (the concatenation of
> > > the 80 files used above):
> > >   4 minutes and 29 seconds.
> > > 
> > > Not immediately prohibitive, but it's painful to repeatedly make a 
> > > correction in scribble source, recompile, and view the result of the 
> > > change in an interactive session.
> 
> I've pushed a repair that corrects the kind of behavior illustrated
> above, at least for my own example. I think there's a good chance that
> it will correct performance for your specific example. (The repair is
> pushed to the development repo, so it should be available in the next
> round of snapshots in a little under 24 hours from now).
> 
Thank you.

Now I have to figure how to install this on my system.  The Racket and 
Scribble I currently have are installed from the Devuan (in this case 
equivalend to Debian) package.  How to install scribble from I presume 
develoment source so as to relace the Debian Scribble.  Persumably purge 
the package and install Racket and Scribble completely from source?  
Presumably there are instructions online somewhere?  Or is there an 
easier route?

-- 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/20190722144227.7w34q7icmos6cqe2%40topoi.pooq.com.

Re: [racket-users] Re: Racket2 possibilities

[amz3]

On Monday, July 22, 2019 at 4:26:04 PM UTC+2, Mário Guimarães wrote:
>
>
> > And the JVM in browsers has been thoroughly supplanted by Javascript. 
>
> I missed another VM: Racket2 should also target WebAssembly.
>

I experimented with various scheme in browser intrepred via JavaScript and 
compiled to wasm both are not good enough. 

-- 
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/d0d2ba3e-057a-46d4-bfb6-77a915bedd09%40googlegroups.com.

Re: [racket-users] Re: Racket2 possibilities

[Mário Guimarães]

> And the JVM in browsers has been thoroughly supplanted by Javascript. 

I missed another VM: Racket2 should also target WebAssembly.

segunda-feira, 22 de Julho de 2019 às 14:44:06 UTC+1, Hendrik Boom escreveu:
>
> On Mon, Jul 22, 2019 at 02:19:39AM -0700, Maria Gabriela Guimarães wrote: 
> ... 
> > 
> > I have mentioned this one, and will repeat again: 
> > 
> > *Make Racket become Language-Oriented Programming on the JVM, the 
> ErlangVM, 
> > and perhaps other mainstream VMs.* 
>
> And the JVM in browsers has been thoroughly supplanted by Javascript. 
> The designers of Javaascript originally planned to put a Lisp on the 
> browser (possibly even a Scheme?) but were forced to give it a C-like 
> syntax. 
> Is Javascript the kind of Scheme-without-parentheses we're looking for? 
> Perhaps not; it isn't a design-your-own-language system. 
>
> -- hendrik 
>
> > 
> > Failing to target these VMs and you will be in the next 5 years asking 
> > again why Racket 2 is still hardly adopted. 
> > 
> > I can't say more regarding Racket's adoption strategy. 
> > 
> > Thanks 
> > Mário Guimarães 
>

-- 
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/839c8ce2-e7d8-4cfd-ae27-fdea9268eabd%40googlegroups.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.

[racket-users] tail-nesting recursive syntax

[Hendrik Boom]

On Mon, Jul 22, 2019 at 10:46:26AM +0200, Dexter Lagan wrote:
>   I'm not going over why s-expressions are the way to go, mr. Rivest did it
> best in his 1997 MIT doc:
> 
> https://people.csail.mit.edu/rivest/Sexp.txt
> 
>   A parens-less Racket2 would become Crystal. And I don't think we need yet
> another functional parens-less language.

Keep S-expressions, but change their syntax.

Nesting parentheses are like recusion.
Create a notation for tail-nested parenthese, kind of like 
tail-recursion optimisation, turning that kind of nesting 
into something more like iteration.

It's tail-nesting that tends to move indentation far, far to the right 
and creates accumulations of hard-to-count close-parenthesis 
agglomerations.

My proposal is to pick a currently underused character (I picked '/' 30 
years ago but amost anything would do) and use it to replace the 
tail-nesting '(', and remove its corresponding ')'.

Suddenly visual parenthesis-matching becomes an order of magnitude 
easier, without losing any of the expressiveness and conceptual 
significance of S-expressions.

-- hendrik

> We already have Haskell (hard to
> read) and Crystal (weird half-commercial proposition that won't produce
> binaries without major hacks). I say we keep the parens but make them even
> less intrusive.

A notation for tail-nestig accomplishes non-intrusive parens all by 
itself.

> Newlisp may be an ugly hack, but its simplified forms and
> anaphoric vars are very nice to use. For example:
> 
> http://www.newlisp.org/downloads/newlisp_manual.html#if

With tail-nesting notation, there's no need for the iterated if.
And this if-iteration can be freely interspersed with let's.  Also a 
common occurrence.

Tail-nesting notation is completely orthogonal to the rest of the 
language.

-- 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/20190722140957.wcz5oupiuavm4cmk%40topoi.pooq.com.

Re: Backing up [was: Re: [racket-users] The case, and a proposal, for elegant syntax in #lang racket2]

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

-- 
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/87tvbemazp.fsf%40greghendershott.com.

Re: [racket-users] Re: Racket2 possibilities

[Hendrik Boom]

On Mon, Jul 22, 2019 at 02:19:39AM -0700, Maria Gabriela Guimarães wrote:
...
> 
> I have mentioned this one, and will repeat again:
> 
> *Make Racket become Language-Oriented Programming on the JVM, the ErlangVM, 
> and perhaps other mainstream VMs.*

And the JVM in browsers has been thoroughly supplanted by Javascript.
The designers of Javaascript originally planned to put a Lisp on the
browser (possibly even a Scheme?) but were forced to give it a C-like syntax.
Is Javascript the kind of Scheme-without-parentheses we're looking for?
Perhaps not; it isn't a design-your-own-language system.

-- hendrik

> 
> Failing to target these VMs and you will be in the next 5 years asking 
> again why Racket 2 is still hardly adopted.
> 
> I can't say more regarding Racket's adoption strategy.
> 
> Thanks
> Mário Guimarães

-- 
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/20190722134403.hqlxcnz35u2okqmh%40topoi.pooq.com.

[racket-users] Directory-specific installation of packages?

[James Geddes]

Dear All,

For reasons (explained below, possibly foolish reasons) I am trying to do the 
following:

1. Have `raco pkg install` install a package X to a specific directory, 
including, in the same directory, all of the dependencies of X, but excluding 
those dependencies that are already present in the current installation's 
collections; and

2. Have `raco exe myprok.rkt` look in that custom directory for `(require X)`?

I tried the `--scope-dir` option to `raco pkg install` but that installed what 
looks like the entire racket standard library (see below).  

Many thanks,

James



PS. What I'm /really/ trying to do is distribute a little command-line 
programme that I wrote in Racket to my colleagues using the homebrew package 
manager. My programme depends on the gregor library.

Most of my colleagues don't have Racket. Homebrew likes to compile from source, 
so I will need to have homebrew download the dependencies I need for 
compilation. But now, homebrew really doesn't like you to write outside a very 
small set of directories during the installation process, and those don't 
appear to include the standard Racket collections directories.

(I could well have misunderstood this. I don't understand at all how homebrew 
interacts with language-specific package managers like raco, pip, cabal, and so 
on. My sense is that the non-raco ones install dependencies in project-specific 
directories and I suspect homebrew has specific support for Python libraries.)

Anyway, my program depends on the gregor library, so I tried this:

$ raco pkg install --scope-dir tmp gregor-lib

$ ls tmp

2d-lib pict-doc
at-exp-lib pict-lib
base   pict-snip-lib
cext-lib   pkgs.rktd
class-iop-lib  plai-lib
cldr-bcp47 planet-doc
:
[ ~100 rows omitted]
:
net-docweb-server-doc
net-libweb-server-lib
option-contract-libwxme-lib
parser-tools-doc   xrepl
parser-tools-lib   xrepl-doc
pconvert-lib   xrepl-lib
pict   zo-lib






-- 
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/2C6D9102-2F63-4A0E-A033-C7FECC5F9CF8%40gmail.com.

[racket-users] Re: Gui editable grid/table

[Roman Klochkov]

https://pkgs.racket-lang.org/package/multicolumn

суббота, 20 июля 2019 г., 8:17:58 UTC+5 пользователь Raoul Schorer написал:
>
> Hi,
>
> I am trying to make a gui editable table. Is that possible in racket/gui?
>
> It seems list-box% is not editable by default. Apparently, one can't stick 
> editors as list-box% choices either.
>
> Can you please help?
>
> Thanks!
> Raoul
>
>

-- 
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/d827b9f5-7a58-4b77-927f-b1122a8885c7%40googlegroups.com.

[racket-users] i18n / srfi-29

[Roman Klochkov]

Hello!

I'm trying to use srfi/29. As far as I understand, it provide 
declare-bundle! + store-bundle to make a localization and load-bundle! to 
use it.
But I cannot find, how to use raco pkg install to run declare-bundle! + 
store-bundle. Or is there any other way to run post-install command in 
Racket?

P.S. Why DrRacket doesn't use srfi/29?

-- 
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/6085bca0-7c96-47fc-aa92-3927a7d4c690%40googlegroups.com.

[racket-users] Re: Racket2 possibilities

[Mário Guimarães]

I have read through all the posts before mine, and saw no reference to what 
could be the solution to the adoption problem.

I only remember comments regarding how students feel unconfortable about 
s-expressions and all those parenthesis

Making a language popular in my view is to make it attractive to 
professional developers and the industry overal, not to students.

In fact, too much reference to students makes people from industry think 
that the language is for use only in academic settings, and this is very 
unfortunate they think so.

I have mentioned this one, and will repeat again:

*Make Racket become Language-Oriented Programming on the JVM, the ErlangVM, 
and perhaps other mainstream VMs.*

Do this first, then watch, then consider other changes, like the syntax one.

I really don't believe that how beautiful and operational a new syntax 
becomes, will it attract people in the industry who are too much committed 
to these VMs.

Failing to target these VMs and you will be in the next 5 years asking 
again why Racket 2 is still hardly adopted.

I can't say more regarding Racket's adoption strategy.

Thanks
Mário Guimarães


sábado, 20 de Julho de 2019 às 19:49:13 UTC+1, Matthew Flatt escreveu:
>
> 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 

[racket-users] Re: Racket2 possibilities

[Maria Gabriela Guimarães]

I have read through all the posts before mine, and saw no reference to what 
could be the solution to the adoption problem.

I only remember comments regarding how students feel unconfortable about 
s-expressions and all those parenthesis

Making a language popular in my view is to make it attractive to 
professional developers and the industry overal, not to students.

In fact, too much reference to students makes people from industry think 
that the language is for use only in academic settings, and this is very 
unfortunate they think so.

I have mentioned this one, and will repeat again:

*Make Racket become Language-Oriented Programming on the JVM, the ErlangVM, 
and perhaps other mainstream VMs.*

Do this first, then watch, then consider other changes, like the syntax one.

I really don't believe that how beautiful and operational a new syntax 
becomes, will it attract people in the industry who are too much committed 
to these VMs.

Failing to target these VMs and you will be in the next 5 years asking 
again why Racket 2 is still hardly adopted.

I can't say more regarding Racket's adoption strategy.

Thanks
Mário Guimarães

Em sábado, 20 de julho de 2019 19:49:13 UTC+1, Matthew Flatt escreveu:
>
> 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 

Re: [racket-users] on reducing barriers in the Racket community

[Dexter Lagan]

 First I’d like to express my immense gratitude for your contributions to the 
Racket community. Beautiful Racket greatly enhanced my understanding of 
language-oriented programming and macros in general.

TL;DR: Racket is the most inspiring language and ecosystem I have ever used. I 
use it not just because it does the job, but because I’m having an absolute 
blast writing code in it, something that hasn’t happened to me since uhh.. x86 
macro-assembler, or Pascal. All it needs is a simpler, localized, more 
practical intro page for existing programmers, and lots of promotion. Oh and 
maybe more speed, but it’s fast enough for my use.

  Now, the wall of text:

  From my perspective the only barrier of entry to Racket is the documentation: 
it is very clear, detailed and well-written, but to certain of my students they 
can also be quite obscure, especially to those who don’t have comp-sci 
background and those whose first language isn’t English. The best example is 
the few pages about continuations. For quite a while I could not understand 
what they were about from the Racket docs, and it took quite a bit of web 
crawling to find meaningful examples of their use. I also found the pages about 
macros lacking simple examples, and it’s not until Beautiful Racket that I 
finally found very basic uses.

 My opinion doesn’t count for much, but from my experience and the feedback I 
got from my employees and students, the main Racket site and docs is missing a 
very basic presentation of the language. Something really clear, concise, that 
does not use comp-sci or advanced vocabulary. The best example that comes to my 
mind is say, Go’s tour pages - in 20 languages. I understand there is Matthew’s 
Quick Introduction on the main page, but somehow I’m imagining a smaller, 
quicker ‘batteries included’, practical intro, for programmers familiar with 
other languages :

1) how to read/write from/to a file
2) how to display text on the screen
3) how to use conditionals and loops
4) how to write a function
5) how to compile functions into modules

  The hyperpolyglot.org/lisp ultra concise, parallel presentation of languages 
helped me more than once make sense of a new language. If only Racket had 
something similar for say, C, Java, Python and Racket. That way Python and Java 
programmers (perhaps Racket’s main target in the production env) could get a 
very quick sense of how things work.

  Localisation would also go a long way towards bringing Racket to the world. 
I’m currently in France and Racket is completely unknown here, yet sorely 
needed when I see the slow-motion Java disaster going on in every engineering 
school and every company.

Dex

> On Jul 21, 2019, at 10:46 PM, Matthew Butterick  wrote:
> 
> I'm not a member of Racket management. But I spend a lot of time using & 
> promoting Racket. Most recently, I taught the Beautiful Racket Workshop as 
> part of Racket Week 2019. 
> 
> I care a lot about Racket — the technology, but especially the human 
> community that makes it possible.
> 
> I've heard from a few people that events before, during, or after Racket Week 
> left them questioning Racket's commitment to making everyone feel welcome. 
> And to be honest, it wasn't the first time. 
> 
> This saddens me. It's not consistent with my own values. It's not what I want 
> Racket to stand for. I want everyone to feel welcome, wanted, and valued. 
> 
> In a nearby thread, Matthew Flatt talked about the importance of "reducing 
> barriers" in a technical sense. But it matters in a community sense too, of 
> course. 
> 
> If Racket is putting up social barriers — even unwittingly — that are 
> frustrating newcomers (or existing members) then we ought to be able to hear 
> this with an open mind & heart, and make adjustments. This is our duty as 
> empathetic, moral members of a community.
> 
> I'm not sure what I can do to improve this situation. I'm open to 
> suggestions. I can at least offer the following (I would rather risk looking 
> foolish than doing nothing):
> 
> 
> 1) If you've had an experience where the Racket community made you feel less 
> than totally welcomed, I invite you to add it to this thread, or contact me 
> privately. If you want details of your story shared, in some anonymized way, 
> I can do that. 
> 
> I recognize the irony of making this offer on the racket-users mailing list — 
> those who've had a bad experience are likely long gone. But I also know there 
> are people here who, like me, want to help make Racket better, even on rough 
> days.
> 
> 
> 2) Gently, I suggest that we work together to reduce the volatility of these 
> conversations. I know that some feel that these matters are better handled 
> away from the racket-users list. But this is counterproductive: it amounts to 
> saying that we should feel free to harvest the benefits of 
> Racket-the-technology while avoiding obligations to Racket-the-community. As 
> a matter of logic and ethics, I can't see 

Re: [racket-users] Re: Racket2 possibilities

[Dexter Lagan]

  I'm not going over why s-expressions are the way to go, mr. Rivest did it
best in his 1997 MIT doc:

https://people.csail.mit.edu/rivest/Sexp.txt

  A parens-less Racket2 would become Crystal. And I don't think we need yet
another functional parens-less language. We already have Haskell (hard to
read) and Crystal (weird half-commercial proposition that won't produce
binaries without major hacks). I say we keep the parens but make them even
less intrusive. Newlisp may be an ugly hack, but its simplified forms and
anaphoric vars are very nice to use. For example:

http://www.newlisp.org/downloads/newlisp_manual.html#if

Dex


On Mon, Jul 22, 2019 at 5:11 AM Ray Racine  wrote:

> Over the years I have loved Racket ... except for those parens ... if
> only.   I don't know when it happened but one day parens and I made a peace
> treaty, mind melded, became enlightened or just got tired of fighting, but
> right now I can't see a Racket without parens (s-exps). I have, in fact,
> grown rather fond of them.
>
> There is the bottom up approach to grow Racket2 from examples and snippets
> of syntax all to be compared and endlessly debated.
>
> Rhetorical mullings from the top down perspective is interesting.
>
> Assume a Racket2 will not be another Ruby or Python as Racket is a BIG
> language and could not be compressed down to a simplistic Python or simple
> lisp without parens Ruby.  And what is the point of Racket2 being a Ruby or
> Python wanna-be anyway?  Would the world move to a better Python/Ruby?
>
> Assume it will not be some variation of a Swift, Java or C#.
>
> If moving from s-exp to traditional in-fix and f(x,y,z) function
> application makes sense to seek wider adoption, would not moving from
> functional to imperative also make sense? After all, all the popular
> languages are imperative, therefore, to enhance the likelihood of wide
> adoption should Racket2 be imperative as well?
>
> But then wouldn't Racket2 be Algol2 or Ada2 with macros?
>
> If it stays functional and expression based with macros then isn't Racket2
> then Dylan2?
>
> Of the three axioms of Racket2, the f(x,y,z) proscription prohibits some
> of the cleaner syntax out there as used in SML and Haskell.  Is it a hard
> requirement to ensure full macro support can happen?
>
> If Racket2 moves to be even more functional in thrust, drops the f(x,y,z)
> proscription and adopts currying then isn't Racket2 a polished up nextgen
> SML2?
>
> Maybe a nextgen SML2 for semantics and typing but with the lighter Haskell
> syntax (no laziness)?
>
> What will be the magic twist for widespread adoption that Algol, Ada,
> Dylan, SML, Haskell and s-exp Racket, all with quality implementations,
> failed to achieve?
>
> How much of a languages adoption success is just shear dumb luck, the
> right place at the right time independent of the languages overall quality
> and capability? Does Javascript even need to mentioned here?
>
> Should we cover all possible bases and make Racket and its "make
> languages" core a nextgen DotNet and put together a whole suite of
> languages, a Lisp like, an Algo like, a SML like, a Haskell like, a
> Java/Swift like, an Erlang like, ... all interoperable.   If that all of
> that happened tomorrow by magic would the world embrace Racket(2...).
>
>
>
>
>
>
>
>
>
> --
> 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/c8abfd8b-3304-4ed5-9e23-bf2f1d7da8cb%40googlegroups.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/CACUENr%2BPQq8DCuUBcuZOL37QD2ByypNiu0rx3MagvTOY0zxDjg%40mail.gmail.com.