[racket-users] Racket Week 2019 was amazing!

[Brian Adkins]

A sincere "thank you" to everyone who was involved in creating Racket Week 
2019 as well as to the other participants who helped make the week an 
amazing experience!

I had high expectations, and they were all exceeded - by far. I'll be 
returning home tomorrow with fond memories of my time here in Utah, some 
new Racket friends and a ton of information to work through and internalize 
over the next few weeks & months. I can't wait to start applying what I 
learned here in my Racket code, and to hopefully give back to the Racket 
community in the form of some useful packages.

Thanks,
Brian

P.S. please don't take away my parens ;)

-- 
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/a70ab50c-28df-472c-9c5c-3bc6d8ade8ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Shriram Krishnamurthi]

Another Racketeer here who's been in the community since day 0.

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

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

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

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

Shriram

-- 
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/e14413c8-9b79-45f9-8fd7-194070354cc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Shriram Krishnamurthi]

P4P is also very much "current", as far as I'm concerned. (In fact, I'm 
quite likely about to use it in a new setting.) Pyret is a parallel branch 
effort. 

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

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

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

Shriram

On Monday, July 15, 2019 at 2:34:31 PM UTC-4, Neil Van Dyke wrote:
>
> Wesley Kerfoot wrote on 7/15/19 2:28 PM: 
> > Has anyone considered http://shriram.github.io/p4p/ as an alternative? 
>
> This might represent Shriram's current thinking (and is what I was 
> alluding to before): https://www.pyret.org/ 
>
> I'll wait for the official community process to commence, before I get 
> deep in discussion. 
>
>

-- 
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/4af85482-fd61-4173-a878-e61b02ab8776%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] [ANN] Reducers, a better way to fold

[Jack Firth]

I've recently added another library to Rebellion, this one for reducers 
. A *reducer* is a 
way to combine a series of values:


> (require rebellion/streaming/reducer)
> (reduce into-sum 1 2 3 4 5)
15


You can reduce any sequence using `reduce-all`:


> (reduce-all into-product (in-range 1 20))
121645100408832000


You can make a reducer from any fold:


> (define into-reversed-list (make-fold-reducer (lambda (lst v) (cons v 
lst)) '()))
> (reduce-all into-reversed-list (in-range 1 10)
'(9 8 7 6 5 4 3 2 1)


You can use `for/reducer` and `for*/reducer` to fold over any `for`-loop 
using a reducer:


> (for/reducer into-reversed-list
   ([n (in-range 2 20)]
#:when (prime? n))
n)
'(19 17 13 11 7 5 3 2)


And you can implement your own `for/...` macros using a reducer:


> (define-syntaxes (for/reversed-list for*/reversed-list)
(make-reducer-based-for-comprehensions #'into-reversed-list))
> (for/reversed-list ([n (in-range 2 20)]
  #:when (prime? n))
n)
'(19 17 13 11 7 5 3 2)


Folds are only the most basic type of reducer: not all reducers are as 
simple as a plain fold. Reducers can use hidden mutable state to make 
reduction performant, and reducers can short-circuit and return a result 
without iterating through the entire sequence. See the 
rebellion/streaming/reducer 
 documentation for 
more details, as well as instructions on how to make your own reducers. To 
use, install Rebellion with `raco pkg install rebellion` and import the 
reducers library with `(require rebellion/streaming/reducer)`.

This library is currently in an *experimental alpha* state. I might break 
your code. Warn me before seriously depending on this, *especially* if you 
won't be using it in an open-source package in the package catalog (where 
the package build server can alert me if I break you).

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/7dbbaa2a-2e6e-4253-9ae4-e2e1ef9a90b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: why scribble may be slow

[Hendrik Boom]

On Mon, Jul 15, 2019 at 05:22:35PM -0700, Jack Firth wrote:
> I believe the reason Scribble is slow on your file has to do with 
> algorithms and logic in Scribble that have poor performance characteristics 
> on large files, and nothing at all to do with the fact that Scribble is 
> implemented in Racket. With a reproducible performance benchmark for 
> running Scribble on large files, I'm sure a dedicated Scribble expert could 
> do a lot to optimize the internals of Scribble and fix the performance 
> problems you're experiencing. That said, I'm no Scribble expert.

Large files? Or large documents made of many small files?  If the latter I can 
probably manage if there's an @include mechanism.

-- hendrik

> 
> On Monday, July 15, 2019 at 6:06:51 PM UTC-6, Hendrik Boom wrote:
> >
> > On Mon, Jul 15, 2019 at 05:38:17PM -0400, Hendrik Boom wrote: 
> > > I'm thinking of trying Scribble again now that I have a new computer. 
> > > I found it unacceptably slow years ago when I tried it on a 80,000 word 
> > novel. 
> > > I now, however, have a modern machine and it may be fast enough. 
> >
> > A theory why scribble is slow: 
> >
> > I looked at the scribble installed on my computer (which runs Devuan, a 
> > Debian derivative) and discovered that it's all Racket source code. 
> >
> > So my guess is that Racket is interpreting Scribble, and the the already 
> > interpreted Scribble is interpreting the scribble input. 
> >
> > Stacking interpreters is usually a recipe for sloth. 
> >
> > So ... is this likely the reason? 
> >
> > Processing an 800,000 character text file without any at signs (so that I 
> > don't invoke any fancy scribble features) took six minutes on a modern 
> > laptop 
> > with 16 gigabytes of RAM. 
> >
> > Hand-coded C processed the same file faster than I can blink my eye.  Both 
> > systems produced usable HTML.  (but the hand-coded C is limited as to what 
> > it 
> > will do. It won't handle tables of category-theoretic diagrams, for 
> > example, 
> > and maybe Scribble can someday manage to do all this) 
> >
> > If this is the reason for scribble being slow, what can be done about it? 
> > Can it, for example, be compiled to something more like machine code? 
> >  (I'm 
> > using a 64-bit intel processor.) 
> >
> > -- 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/73523467-14eb-472c-b5c1-ea736a22e320%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20190716011242.amzacpoljvkaq4ue%40topoi.pooq.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: why scribble may be slow

[Jack Firth]

I believe the reason Scribble is slow on your file has to do with 
algorithms and logic in Scribble that have poor performance characteristics 
on large files, and nothing at all to do with the fact that Scribble is 
implemented in Racket. With a reproducible performance benchmark for 
running Scribble on large files, I'm sure a dedicated Scribble expert could 
do a lot to optimize the internals of Scribble and fix the performance 
problems you're experiencing. That said, I'm no Scribble expert.

On Monday, July 15, 2019 at 6:06:51 PM UTC-6, Hendrik Boom wrote:
>
> On Mon, Jul 15, 2019 at 05:38:17PM -0400, Hendrik Boom wrote: 
> > I'm thinking of trying Scribble again now that I have a new computer. 
> > I found it unacceptably slow years ago when I tried it on a 80,000 word 
> novel. 
> > I now, however, have a modern machine and it may be fast enough. 
>
> A theory why scribble is slow: 
>
> I looked at the scribble installed on my computer (which runs Devuan, a 
> Debian derivative) and discovered that it's all Racket source code. 
>
> So my guess is that Racket is interpreting Scribble, and the the already 
> interpreted Scribble is interpreting the scribble input. 
>
> Stacking interpreters is usually a recipe for sloth. 
>
> So ... is this likely the reason? 
>
> Processing an 800,000 character text file without any at signs (so that I 
> don't invoke any fancy scribble features) took six minutes on a modern 
> laptop 
> with 16 gigabytes of RAM. 
>
> Hand-coded C processed the same file faster than I can blink my eye.  Both 
> systems produced usable HTML.  (but the hand-coded C is limited as to what 
> it 
> will do. It won't handle tables of category-theoretic diagrams, for 
> example, 
> and maybe Scribble can someday manage to do all this) 
>
> If this is the reason for scribble being slow, what can be done about it? 
> Can it, for example, be compiled to something more like machine code? 
>  (I'm 
> using a 64-bit intel processor.) 
>
> -- 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/73523467-14eb-472c-b5c1-ea736a22e320%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] why scribble may be slow

[Hendrik Boom]

On Mon, Jul 15, 2019 at 05:38:17PM -0400, Hendrik Boom wrote:
> I'm thinking of trying Scribble again now that I have a new computer.
> I found it unacceptably slow years ago when I tried it on a 80,000 word novel.
> I now, however, have a modern machine and it may be fast enough.

A theory why scribble is slow:

I looked at the scribble installed on my computer (which runs Devuan, a 
Debian derivative) and discovered that it's all Racket source code.

So my guess is that Racket is interpreting Scribble, and the the already 
interpreted Scribble is interpreting the scribble input.

Stacking interpreters is usually a recipe for sloth.

So ... is this likely the reason?

Processing an 800,000 character text file without any at signs (so that I 
don't invoke any fancy scribble features) took six minutes on a modern laptop 
with 16 gigabytes of RAM.

Hand-coded C processed the same file faster than I can blink my eye.  Both 
systems produced usable HTML.  (but the hand-coded C is limited as to what it 
will do. It won't handle tables of category-theoretic diagrams, for example, 
and maybe Scribble can someday manage to do all this)

If this is the reason for scribble being slow, what can be done about it?
Can it, for example, be compiled to something more like machine code?  (I'm 
using a 64-bit intel processor.)

-- 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/20190716000646.lcdckfcd7i6rk4f3%40topoi.pooq.com.
For more options, visit https://groups.google.com/d/optout.

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

[Maciek Godek]

W dniu niedziela, 14 lipca 2019 19:44:30 UTC+2 użytkownik cwebber napisał:
>
> [...]
>  - Nonetheless, assumptions that various math operators should be infix 
>is understandable because that's what people see today. 
>

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

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

I believe that, rather than

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

it would be better to write something like:

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

or

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

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

-- 
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/a22f254b-8fc6-437d-9bf2-1b56cd271508%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] using scribble for everything from category theory to poetry

[Hendrik Boom]

I'm thinking of trying Scribble again now that I have a new computer.
I found it unacceptably slow years ago when I tried it on a 80,000 word novel.
I now, however, have a modern machine and it may be fast enough.

I have a few questions before I convert *everything* I'm doing to scribble.  
Each of these questions are relevant to a particular planned use.  The more of 
them have positive answers, the more projects I'll be able to 
scribblify.

(1) How does scribble handle mathematical notation?  Presumably there's a hack 
for when I'm generating TeX, but is there anything reasonable when generating 
HTML?  Mathjax is somewhat tolerable, but mathML would be nice.

(2) How can I produce category-theoretical diagrams, such as the one on top of 
page 29 in section 3.7 in the pdf file 
https://www.logicmatters.net/resources/pdfs/GentleIntro.pdf
Oh yes, category theorists also use different shapes of arrow 
heads and tails just to challenge us computer people.

(3) Are there practical ways of including images whose source code might be 
jpegs ot pngs?

(4) How can I include other scribble files into a main scribble file *without* 
making it a separate section?  The tutorial 
https://docs.racket-lang.org/scribble/getting-started.html
mentions include-section, but I'm looking for something like just C's 
#include.

(5) How can I make text conditional on the presence or absence of a 
command-line parameter of the value of a global variable?

(6) How do I achieve precise, line-by-line control of indentation for poetry?

-- 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/20190715213817.ijeovk5hs5vifgs4%40topoi.pooq.com.
For more options, visit https://groups.google.com/d/optout.

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

[Hendrik Boom]

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

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

-- hendrik

-- 
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/20190715210333.k5indts2wovi5hec%40topoi.pooq.com.
For more options, visit https://groups.google.com/d/optout.

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

[Sam Tobin-Hochstadt]

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

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

Sam

On Mon, Jul 15, 2019, 12:19 PM Matthias Felleisen 
wrote:

>
>
> > On Jul 14, 2019, at 1:44 PM, someone wrote:
> >
> > - I am indeed very for growth in the community, though my main interest
> >   in growth is in seeing a wider diversity of participants than just
> >   raw numbers.  Obviously other peoples' mileage may vary.
>
>
> This is politics and politics has no business whatsoever on this mailing
> list. I believe there are things such as Facebook, Instagram and other
> Web-chambers where political opinions are welcome and echoes will always
> confirm your opinions.
>
> ;; - - -
>
> Our policy has always been that everyone, absolutely everyone, is welcome
> on this technical list to discuss technical issues. We don’t exclude
> anyone. And everyone gets treated the same and gets productive responses if
> possible. In particular, politics stays off this list; it’s divisive enough
> in the rest of the world.
>
> Thank you — Matthias
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/B7391FF7-FDE7-42A5-921D-BA9B78B463C9%40felleisen.org
> .
> For more options, visit https://groups.google.com/d/optout.
>


On Mon, Jul 15, 2019, 12:19 PM Matthias Felleisen 
wrote:

>
>
> > On Jul 14, 2019, at 1:44 PM, someone wrote:
> >
> > - I am indeed very for growth in the community, though my main interest
> >   in growth is in seeing a wider diversity of participants than just
> >   raw numbers.  Obviously other peoples' mileage may vary.
>
>
> This is politics and politics has no business whatsoever on this mailing
> list. I believe there are things such as Facebook, Instagram and other
> Web-chambers where political opinions are welcome and echoes will always
> confirm your opinions.
>
> ;; - - -
>
> Our policy has always been that everyone, absolutely everyone, is welcome
> on this technical list to discuss technical issues. We don’t exclude
> anyone. And everyone gets treated the same and gets productive responses if
> possible. In particular, politics stays off this list; it’s divisive enough
> in the rest of the world.
>
> Thank you — Matthias
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/B7391FF7-FDE7-42A5-921D-BA9B78B463C9%40felleisen.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAK%3DHD%2Bb67tTV8a5Dmj5r5uZs2-BfgP7fvj3-aHZXSNCekBt_SA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Conservancy policy vs. Racket policy

[Matthew Butterick]

[forked from "The case, and a proposal, for elegant syntax in #lang racket2"]

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



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

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

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


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

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

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

[1] https://youtu.be/xSjk2PdQm5k?t=17682
[2] https://sfconservancy.org/projects/apply/ConservancyFSATemplate.pdf 


-- 
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/D8CA91DC-6680-42B0-AECB-93755604C25A%40mbtype.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Racket News - Issue 12

[Paulo Matos]

Another issue has landed at your doorstep. Sit down, grab a cup of
coffee and enjoy!

https://racket-news.com/2019/07/racket-news-issue-12.html

Paulo Matos

-- 
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/75aaca1a-2a3c-9c67-e81b-cd044f1bef1d%40linki.tools.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Building "#lang dungeon"

[Neil Van Dyke]

If you want to solve problems like how to handle user conceptual models 
of permissions, consider putting "UX" aside for a moment.


UX gets confused by conflicts of interest, which the earlier disciplines 
of HCI and human factors engineering did not much have.


HCI comes from a human factors tradition of goal alignment with the 
human -- everyone wanting the user to be more effective at their tasks 
(whether it's operating a Macintosh, or a fighter jet).


UX is influenced more by the traditions of graphic design (especially 
for marketing brochures and the like), and in practice is usually 
burdened by motivations to manipulate the user to serve the interests of 
someone other than the user, even aggressively against the interests of 
the user.


Consider the GUI design for a smartphone/tablet -- do you want its 
visual cues, notifications, and other affordances to be for effective 
use of the device (HCI), or do you want to combat users' ability to 
perceptually filter-out ads, use notifications to aggressively keep the 
user engaged with addictive low-value "content", us more-blatant "dark 
patterns" to discourage users from selecting options that are likely the 
user's intent and in user's best interest, while looking slick (UX).


So, as an engineer/scientist/designer/educator of goodwill, consider the 
exercise of trying to think like an HCI person, and being suspicious of 
anything labeled UX.


--
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/cd9c307d-96b7-2eb8-5cd7-3d10b75f7e0a%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Building "#lang dungeon"

[Konrad Hinsen]

Hi Christopherm

> Of course I don't expect someone to launch solitaire from the REPL, and
> indeed there are UX considerations once we move from the REPL to actual

I wasn't thinking so much of UX issues, but of the differences in the
level of abstraction that different people need. The capabilities that
you would pass to a low-level file handling library may well make no
sense to the end user who is barely aware that his solitaire game
uses files to store scores or whatever else.

Android permissions are a good illustration. They are too coarse-grained
for meaningful protection (e.g. access to the whole filesystem or no
files at all), and at the same time too technical for most users who
don't know (nor want to know) how and where data is stored.

Konrad.

-- 
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/m18sszcf3a.fsf%40khs-macbook.home.
For more options, visit https://groups.google.com/d/optout.

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

[David Storrs]

On Mon, Jul 15, 2019, 11:55 AM Matthias Felleisen 
wrote:

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


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


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

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAE8gKococNvRv4R-MSjkcdZVs2eRLc7xEEfTa_oHvYh5RqLdmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Neil Van Dyke]

Wesley Kerfoot wrote on 7/15/19 2:28 PM:

Has anyone considered http://shriram.github.io/p4p/ as an alternative?


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


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


--
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/173ee913-ebb9-6f48-f758-d58f60938dea%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

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

[Wesley Kerfoot]

Has anyone considered http://shriram.github.io/p4p/ as an alternative?

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

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

-- 
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/578e8f07-1d7d-4674-a76d-4b71a6e90090%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Neil Van Dyke]

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


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


--
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/518ef92e-045d-b152-5c92-5fc79268213e%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

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

[Wesley Kerfoot]

Has anyone considered http://shriram.github.io/p4p/ as an alternative?

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

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

On Sunday, July 14, 2019 at 1:44:30 PM UTC-4, cwebber wrote:
>
> The context of this email is the proposal by Matthew Flatt that we move 
> to an easier-to-accept surface syntax for #lang racket2. 
>
> Matthew Flatt has heard more than enough from me of concern about this 
> proposal.  But I should indicate that I'm highly sympathetic to the 
> goal.  I would like to lay out the following observations: 
>
>  - The challenge with s-expressions is largely in anxiety with something 
>that looks extremely alien.  I suspect there's more fear from 
>instructors than students in encountering a lisp syntax; my 
>experience is that introducing someone who doesn't know differently 
>to a parenthetical syntax isn't scary for them, and they tend to like 
>it.  But people who have *started out* with experience in a non-lispy 
>language tend to find it scary. 
>
>  - Nonetheless, assumptions that various math operators should be infix 
>is understandable because that's what people see today. 
>
>  - I am indeed very for growth in the community, though my main interest 
>in growth is in seeing a wider diversity of participants than just 
>raw numbers.  Obviously other peoples' mileage may vary. 
>
>  - We are at serious risk in this pivot of losing some key things: 
>
>- Many communities I have been in that have undertaken such a large 
>  pivot to increase popularity expend enormous energy in the move to 
>  the new thing, and in that process, the project actually collapses. 
>  What I'm trying to say is that a pivot is a gamble; we should 
>  calculate our odds carefully.  (Indeed, the first thing I thought 
>  when I heard that this might happen was, did I make a mistake in 
>  shifting my work to Racket?  It is unlikely I would have come to 
>  Racket if there wasn't an equivalent amount of elegance.) 
>
>- I'm not sure if I could have understood Racket Week with a syntax 
>  that didn't have the elegance of s-expressions.  This is not to say 
>  that *no* syntax can have that level of elegance where things can 
>  be so clear, however. 
>
> IIRC Matthew's proposal for "#lang racket2" was something like the 
> following: 
>
>  a) function(args ...) should work. 
>  b) infix is necessary for math, such as 3 + 4 
>  c) parentheses should be possible for grouping 
>
> The weird thing about the last one being that this is already kind of 
> true in s-expressions, but by ~default this also results in application. 
>
> Let me add one more suggested design goal: 
>
>  - the new syntax should must not be significantly less elegant than 
>s-expressions. 
>
> Is there a way to achieve this?  I actually think the best path forward 
> is to have a surface syntax that actually maps completely to 
> s-expressions, which is in fact universal that it can work with *any* 
> s-expression syntax. 
>
> I would suggest starting with Wisp as the basis for examining this: 
>
>   https://dustycloud.org/blog/wisp-lisp-alternative/ 
>   https://srfi.schemers.org/srfi-119/srfi-119.html 
>
> Sweet-expressions may also be an alternative to explore.  However, I 
> think Wisp is a more elegant base; it can transform *any* wisp code into 
> s-exp code.  Not discussed in my blogpost about Wisp is that it also 
> supports infix via {3 + 4}.  So ok, now we have that.  And we can still 
> group: 
>
>   {3 + {8 + 4}} 
>
> So that's points b) and c), but we don't have a) yet.  Could we add it? 
>
> I think we can extend wisp with one thing and get everything we want: if 
> you have func(arg1 arg2 arg3) where the parenthesis comes *immediately* 
> after the symbol, that is rewritten to (func arg1 arg2 arg3).  I will 
> call this version ~Wisp. 
>
> With all this, observe the following code rewritten from Scheme to ~Wisp: 
>
>   (define (rgb-maker mk) 
> (lambda (sz) 
>   (vc-append (colorize (mk sz) "red") 
>  (colorize (mk sz) "green") 
>  (colorize (mk sz) "blue" 
>
>   define rgb-maker(mk) 
> lambda(sz) 
>   vc-append(colorize(mk(sz) "red") 
> colorize(mk(sz) "green") 
> colorize(mk(sz) "blue")) 
>
> Here is another chunk of code, taken from HTdP2: 
>
>   (and (or (= (string-length "hello world") 
>   (string->number "11")) 
>(string=? "hello world" "good morning")) 
>(>= (+ (string-length "hello world") 60) 80)) 
>
> To: 
>
>   and(or({string-length("hello world") = string->number("11")} 
>  

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

[David Storrs]

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

On Mon, Jul 15, 2019, 11:54 AM David Storrs  wrote:

> In the language of web forums: +1 Insightful to Jack Firth's comments.
>
>
> Back on topic:
> The question that is most important to me is: Once #lang racket2 is
> designed and produced and out in the world, will #lang racket still be
> actively supported? If not, will there be tooling available to convert
> source files back and forth between racket and racket2, and will there be a
> commitment to keeping that tooling up to date? I have no problem treating
> racket2 as an object format that I can decompile when I want to work on
> someone else's code, or compile to when I want to publish my own.
>
> Clear communication: The following is my personal feeling and emotional
> reaction. I understand that the core Racket team has no reason to be
> influenced by it, and I am offering it merely as a data point:
>
> If the scenarios I asked about aren't on the table, I
>  feel like I might as well start evaluating other Lisp variants now. If I
> wanted to work in something that looked like Python or C and had the
> cognitive load of Python or C then I would work in Python or C. It would
> make me much more employable.
>
>
> On Mon, Jul 15, 2019, 11:06 AM Jack Firth  wrote:
>
>> Matthias, I ask that you please not respond to discussion about the
>> diversity of the Racket community by saying it's a political topic and
>> politics have no place here. That statement alone is political and makes
>> many people feel unwelcome, including me.
>>
>> On the topic of a new syntax: I am strongly in favor. I think it will
>> remove barriers to entry that have deterred many potential Racketeers. And
>> if there's one community I trust to put care and thoughtfulness into a
>> surface syntax design, it's the Racket community.
>>
>> On Monday, July 15, 2019 at 10:19:16 AM UTC-6, Matthias Felleisen wrote:
>>>
>>>
>>>
>>> > On Jul 14, 2019, at 1:44 PM, someone wrote:
>>> >
>>> > - I am indeed very for growth in the community, though my main
>>> interest
>>> >   in growth is in seeing a wider diversity of participants than just
>>> >   raw numbers.  Obviously other peoples' mileage may vary.
>>>
>>>
>>> This is politics and politics has no business whatsoever on this mailing
>>> list. I believe there are things such as Facebook, Instagram and other
>>> Web-chambers where political opinions are welcome and echoes will always
>>> confirm your opinions.
>>>
>>> ;; - - -
>>>
>>> Our policy has always been that everyone, absolutely everyone, is
>>> welcome on this technical list to discuss technical issues. We don’t
>>> exclude anyone. And everyone gets treated the same and gets productive
>>> responses if possible. In particular, politics stays off this list; it’s
>>> divisive enough in the rest of the world.
>>>
>>> Thank you — Matthias
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/racket-users/a63d9bdb-4d5d-49e8-9451-d6524ac24752%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAE8gKockkOG_DLz7MbXH-78sTBW8cyxVAqUKNWX3RngiGbc6Ag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Matthias Felleisen]

Jack, 

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

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

— Matthias







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

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/87B3D875-42D4-4951-B08D-96BF28468EF8%40felleisen.org.
For more options, visit https://groups.google.com/d/optout.

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

[Christopher Lemmer Webber]

Jack Firth writes:

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

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

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

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

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

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

 - Chris

-- 
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/87muhfqj2o.fsf%40dustycloud.org.
For more options, visit https://groups.google.com/d/optout.

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

[David Storrs]

In the language of web forums: +1 Insightful to Jack Firth's comments.


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

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

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


On Mon, Jul 15, 2019, 11:06 AM Jack Firth  wrote:

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

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAE8gKodbcdb%3DKH5n_rEd0sRnadzxUvHS%2BvtUvRSm60Q%2Bo8D7LQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jack Firth]

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

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

On Monday, July 15, 2019 at 10:19:16 AM UTC-6, Matthias Felleisen wrote:
>
>
>
> > On Jul 14, 2019, at 1:44 PM, someone wrote: 
> > 
> > - I am indeed very for growth in the community, though my main interest 
> >   in growth is in seeing a wider diversity of participants than just 
> >   raw numbers.  Obviously other peoples' mileage may vary. 
>
>
> This is politics and politics has no business whatsoever on this mailing 
> list. I believe there are things such as Facebook, Instagram and other 
> Web-chambers where political opinions are welcome and echoes will always 
> confirm your opinions. 
>
> ;; - - - 
>
> Our policy has always been that everyone, absolutely everyone, is welcome 
> on this technical list to discuss technical issues. We don’t exclude 
> anyone. And everyone gets treated the same and gets productive responses if 
> possible. In particular, politics stays off this list; it’s divisive enough 
> in the rest of the world. 
>
> Thank you — Matthias 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/a63d9bdb-4d5d-49e8-9451-d6524ac24752%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Matthias Felleisen]

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


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

;; - - - 

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

Thank you — Matthias

-- 
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/B7391FF7-FDE7-42A5-921D-BA9B78B463C9%40felleisen.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] DrRacket back button

[Robby Findler]

No, not currently; you have to cycle through the binding identifiers (next
binding occurrence).

Robby

On Mon, Jul 15, 2019 at 5:10 PM Luke Whittlesey 
wrote:

> In DrRacket I like being able to right click on an identifier and `Jump to
> Binding Occurance". Is there a way to "jump back" to where you jumped from?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CA%2Bce6i007%3D-jkv%2BwUfkoJg-5YaJsXGgHn6jDUp%2BfPKHL3iK_Ww%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOO-PvHnZn%2BP0ZA33GWGtE%2BHCEx%3DWUBeLhV60OmEfPg-Wg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] DrRacket back button

[Luke Whittlesey]

In DrRacket I like being able to right click on an identifier and `Jump to
Binding Occurance". Is there a way to "jump back" to where you jumped from?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CA%2Bce6i007%3D-jkv%2BwUfkoJg-5YaJsXGgHn6jDUp%2BfPKHL3iK_Ww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Racket2 and syntax

[gfb]

On Monday, July 15, 2019 at 9:52:43 AM UTC-4, cwebber wrote:
>
> Maciek Godek writes: 
>
> > Maybe the direction similar to where "I think we should be heading" is 
> > somewhere between Mathematica notebooks and Smalltalk's object 
> environments. 
>
> I had similar-ish thoughts while watching the excellent Fructure talk at 
> this year's RacketCon: maybe intro courses would be more willing to pick 
> up Racket and not be scared of its syntax if the default educational 
> language was more like Scratch.  One nice thing about Fructure is that 
> it didn't present any parentheses, but I suspect that the way that it 
> presented grouping meant that if you eventually switched from that mode 
> of writing code over to textual parenthetical notification, it would 
> feel like a fairly natural shift. 
>

I've put a package tightlight on the server that “tightens” the 
highlighting in DrRacket:

Pointing out that it's essentially Scratch's syntax has been helpful in 
many discussions,
 as has using it with faint blue parentheses reminiscent of the subtle 
lined paper lines
 that many are used to not noticing consciously.

There's a View menu item to turn off the outlines, change whether the 
outline boxes
 are horizontally and/or vertically inset, or revert to standard DrRacket.

The package was a hack for a colleague who was teaching our course for 
non-majors
 in 2012, and we still use it. The implementation is a hack because some 
method needing
 to be overriden was private or final, so every method that used it was 
copied to intercept 
 that use. Also, I can't resist exploring coding approaches so all the 
copied code was
 rewritten in various ways.

-- 
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/e8624fd3-fc40-4437-8948-cddd65e6c7c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Racket2 and syntax

[Raoul Schorer]

I'm far out of my depth, but...

Doesn't REBOL syntax fit all criteria given in the RacketCon talk? That's a 
genuine question. Reading about it, I was under the impression that it was 
basically lisp with alternate syntax.

-- 
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/b52ae6b7-29a3-422f-bd64-b78f64814d26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] CFP: 4th Workshop on Meta-Programming Techniques and Reflection (Meta'19), Co-located with SPLASH 2019

[Ryan Culpepper]

   Call for Papers

  4th Workshop on Meta-Programming Techniques and Reflection (Meta’19)

 Co-located with SPLASH 2019
October 20, 2019, Athens, Greece

   https://2019.splashcon.org/track/meta-2019
  Follow us on twitter @MetaAtSPLASH



The Meta’19 workshop aims to bring together researchers working
on metaprogramming and reflection, as well as users building
applications, language extensions and/or software tools using
them.

The challenges which metaprogramming faces are manifold. They
start with formal reasoning about reflective programs, continue
with performance and tooling, and reach into the empirical field
to understand how metaprogramming is used and how it affects
software maintainability.

While industry accepted metaprogramming on a wide scale with
Ruby, Scala, JavaScript, R and others, there is still a long road
ahead to bring the same level of convenience, tooling, and
understanding as for direct programming styles.

Contributions to the workshop are welcome on a wide range of
topics related to the design, implementation, and application of
metaprogramming techniques, as well as empirical studies and
formal methods for such systems and languages.

### Topics of Interest

The workshop is a venue for all approaches that embrace
metaprogramming, from static to dynamic techniques:

- reflection, meta-level architectures, staging, open language
  runtimes applications to middleware, frameworks, and DSLs
- optimization techniques
- contract systems, or typing of reflective programs
- reflection and metaobject protocols to enable tooling
- case studies and evaluation of such techniques, e.g., to build
  applications, language extensions, or tools
- empirical evaluation of metaprogramming solutions
- security in reflective systems and capability-based designs
- meta-level architectures and reflective middleware for modern
  runtime platforms (e.g. IoT, cyber-physical systems,
  mobile/cloud/grid computing, etc)
- surveys, conceptualization, taxonomization, and formalization
  of existing approaches

### Workshop Format and Submissions

This workshop welcomes the presentation of new ideas and emerging
problems as well as mature work as part of a mini-conference
format.  Furthermore, we plan interactive brainstorming and
demonstration sessions between the formal presentations to enable
an active exchange of ideas.

Papers submitted by the first deadline will be considered for
publication in the ACM DL, if not requested otherwise by the
authors. Thus, they will be part of SPLASH workshop proceedings.

For all papers, use of the SIGPLAN acmart style is mandatory:

  http://www.sigplan.org/Resources/Author/

Please use the provided double-column templates for Latex or Word.

  technical paper: max. 8 pages, excluding references
  position and work-in-progress paper: 1-4 pages, excluding references
  technology demos or a posters: 1-page abstract

Demos, posters, position and work-in-progress papers can be
submitted on a second, later deadline to discuss the latest
results and current work, but will not be considered for
publication in the ACM DL.

For the submission, please use the submission system at:

  https://meta19.hotcrp.com/


### Important Dates

26 Jul 2019  - Abstract Submission
 2 Aug 2019  - Paper Submission (considered for ACM DL)
23 Aug 2019  - Notification
28 Aug 2019  - Demo, position or work-in-progress paper submission
20 Sep 2019  - Demo, position or work-in-progress paper notification

### Steering Committee

Elisa Gonzalez Boix, Vrije Universiteit Brussel
Stefan Marr, University of Kent

### Organizing Committee

Guido Chari, Czech Technical University
Christophe Scholliers, Ghent University

### Program Committee

Nada Amin, University of Cambridge, UK
Edwin Brady, University of St Andrews, UK
Andrei Chis, Feenk, Switzerland
David Thrane Christiansen, Galois, Portland, Oregon, USA
Tom Van Cutsem, Bell Labs, Belgium
Ryan Culpepper, Czech Technical University, Prague, Czechia
Jennifer Hacket, University of Nottingham, UK
Robert Hirschfield, Hasso Plattner Institute, Germany
James Noble, Victoria University Wellington, New Zealand
Bruno C. d. S. Oliveira, The University of Hong Kong
Cyrus Omar, University of Chicago, USA
Guillermo Polito, Inria Lille, France
Eric Tanter, Universidad de Chile, Chile

### Contact Information

For further inquiries, do not hesitate to contact the organizers
via meta-at-splash19 AT googlegroups.com

http://2019.splashcon.org/track/meta-2019

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

Re: [racket-users] Building "#lang dungeon"

[Christopher Lemmer Webber]

Konrad Hinsen writes:

> Hi Chris,
>

Hi Konrad,

> While I understand the general goal you are aiming at, it isn't quite
> clear to me who you are trying to protect against who. There's a wide
> spectrum of people involved, ranging from language designers via library
> developers and application developers to end users. Who is going to
> define your capabilities? Who is supposed to be protected by them?  And
> who is the potential villain whose evil doings need to be checked for?
>
> Your example doesn't help much with this, as playing a game of solitaire
> from the Racket REPL is not a relevant real-life scenario. The typical
> solitaire player is an end-user who double-clicks an application and
> wouldn't understand the implications of granting access to a single
> window.

Of course I don't expect someone to launch solitaire from the REPL, and
indeed there are UX considerations once we move from the REPL to actual
program launch.  There *are* paradigms for that that have been
developed, and intuitive behaviors such as drag and drop compose nicely
with a capability discipline.

However, I am talking to language people about how we give authority to
parts of our programs, so something that works at the REPL can help us
think more at this level of abstraction, aside from the other ones :)

-- 
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/87o91vqu4u.fsf%40dustycloud.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Racket2 and syntax

[Christopher Lemmer Webber]

Maciek Godek writes:

> Maybe the direction similar to where "I think we should be heading" is 
> somewhere between Mathematica notebooks and Smalltalk's object environments.

I had similar-ish thoughts while watching the excellent Fructure talk at
this year's RacketCon: maybe intro courses would be more willing to pick
up Racket and not be scared of its syntax if the default educational
language was more like Scratch.  One nice thing about Fructure is that
it didn't present any parentheses, but I suspect that the way that it
presented grouping meant that if you eventually switched from that mode
of writing code over to textual parenthetical notification, it would
feel like a fairly natural shift.

-- 
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/87pnmbquah.fsf%40dustycloud.org.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Elegant tail nesting

[Hendrik Boom]

The one problem I have with s-expression syntax is deep indentation with 
tail-nesting. 

In one lisp-like language I solved this by letting

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

abbreviate

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

With indentation this gives

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

instead of

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

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

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

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

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

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

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

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

-- hendrik

-- 
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/20190715134928.umkug7yxonf73hgd%40topoi.pooq.com.
For more options, visit https://groups.google.com/d/optout.

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

[Hendrik Boom]

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

Pascals postfix ^ for this right.

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

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

-- hendrik

-- 
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/20190715133501.wdno5lvddmfavftg%40topoi.pooq.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jack Rosenthal]

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

*p++

;)

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

Computers were a mistake.
-- Ethan Hunter

-- 
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/20190715131005.GA4615%40rosenth.al.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [racket-users] Racket2 and syntax

['Alan Forrester' via Racket Users]

On Mon, 15 Jul 2019 at 03:30, Matthew Flatt  wrote:
>
> tl;dr DON'T PANIC
>
> At RacketCon today, after summarizing the state of work on Racket CS, I
> recommended that we next explore the possibly of changing to an
> infix-oriented syntax in "Racket2".

Infix notation introduces a lot of complexity in writing and reading
code. You have try to remember what operators are infix, and all their
precedence rules, or you just wrap lots of expressions in parentheses
to avoid precedence rule problems. If you introduce infix you're not
reducing the number of parentheses, you're just ensuring that people
have to sprinkle parens around more arbitrarily than they do now in
the hope that their program will work as intended.

Alan

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CA%2BBEJK%3Du%2BofbiOCd3Ga4t-eWKvtJY66RQk2S3D%2B3PdhQkMEvmw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Hendrik Boom]

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

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

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

-- hendrik

-- 
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/20190715124720.ce5kho5xtf6czsfv%40topoi.pooq.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jack Rosenthal]

I think you make valid points, I just wanted to provide an alternate
opinion...

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

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

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

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

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

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

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

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

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

-- 
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/2019071510.GA4069%40rosenth.al.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [racket-users] Re: Racket2 and syntax

[Neil Van Dyke]

I look forward to the syntax discussion, within whatever process is 
determined.


(BTW, I've said similar to what Gabriel do, as recently as last 
week [1], but I'm open to rethinking syntax.  Especially if it might 
mean we can entice Shriram to resume working more directly on Racket. :)


[1] https://news.ycombinator.com/item?id=20376377

--
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/09ee9ca5-5ff8-ac21-5849-69f94652c5b0%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Racket2 and syntax

[Maciek Godek]

I hope you don't mind me adding my two cents to the discussion.
I believe that people who use Lisp tend to see the advantage of its syntax 
for meta-programming.

As Richard Gabriel and Guy Steele wrote in "The Evolution of Lisp",

Algol-style syntax makes programs look less like the data structures used 
to represent them. In a culture where the ability to manipulate 
representations of programs is a central paradigm, a notation that 
distances the appearance of a program from the appearance of its 
representation as data is not likely to be warmly received (and this was, 
and is, one of the principal objections to the inclusion of loop in Common 
Lisp).

On the other hand, precisely because Lisp makes it easy to play with 
program representations, it is always easy for the novice to experiment 
with alternative notations. Therefore we expect future generations of Lisp 
programmers to continue to reinvent Algol-style syntax for Lisp, over and 
over and over again, and we are equally confident that they will continue, 
after an initial period of infatuation, to reject it. (Perhaps this process 
should be regarded as a rite of passage for Lisp hackers.)


Personally, I had a lot of objections when SRFI-105 and SRFI-110 were 
ratified. I thought that it's going to be more harmful than helpful, as it 
would only increase the entropy of the Lisp code base.

I still don't think that syntax is the problem. I think that we should be 
able to switch between different representations of "the same thing", but 
if we want this to be possible, we need to surpass the idea of syntax (or 
the idea that programs need to be text that is parsed).

Maybe the direction similar to where "I think we should be heading" is 
somewhere between Mathematica notebooks and Smalltalk's object environments.

I wrote a bit more about it here (I intended to present that during 
Racketfest in March, but unfortunately I ran out of time)

https://www.quora.com/Can-you-create-a-better-syntax-of-Lisp/answer/Panicz-Godek


-- 
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/2080dcd1-a36b-4cd5-93c7-e692ea877509%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Building "#lang dungeon"

[Konrad Hinsen]

Hi Chris,

While I understand the general goal you are aiming at, it isn't quite
clear to me who you are trying to protect against who. There's a wide
spectrum of people involved, ranging from language designers via library
developers and application developers to end users. Who is going to
define your capabilities? Who is supposed to be protected by them?  And
who is the potential villain whose evil doings need to be checked for?

Your example doesn't help much with this, as playing a game of solitaire
from the Racket REPL is not a relevant real-life scenario. The typical
solitaire player is an end-user who double-clicks an application and
wouldn't understand the implications of granting access to a single
window. Technical measures to establishing trust work only between
technology experts. So perhaps you aim at protecting application
developers against abusive libraries? In that case, I'd expect the main
challenge to be the design of a sufficiently flexible yet manageable
capability system that doesn't add tons of additional complexity to
software.

Konrad.

-- 
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/m1blxvsp4m.fsf%40ordinateur-de-catherine--konrad.home.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: recursion schemes

[江泽民]

Actully racket pattern matching syntax has already supported recursion 
scheme(catamorphism):

(define (eval-expr e)
  (match e
[`(+ ,(app eval-expr e0) ,(app eval-expr e1))
 (+ e0 e1)]
[`(- ,(app eval-expr e0) ,(app eval-expr e1))
 (- e0 e1)]
[(? number?) e]
))


在 2019年7月15日星期一 UTC+8上午11:21:14，Raoul Schorer写道：
>
> Hi,
>
> I recently became interested in recursion schemes, and I noticed that 
> almost all implementations are in typed languages. I understand the 
> advantage of having an implementation using recursion at the type level, 
> but why is it that there are so few material in untyped languages?
>
> For instance, would a recursion schemes racket lib be useful or is there 
> something I am missing? I noticed that there is no such lib, currently.
>
> 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/875f6c82-ab63-48b9-9b89-92fb5330d110%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.