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

[Greg Hendershott]

Thank you for replying.

I didn't mean to suggest I thought these things were already happening.
I don't.

And I'm sorry my attempt to express gratitude by saying you had every
right to decree it, sounded like I thought you actually would do it that
way. I don't.

I (mis?)understood that working groups would be to hash out technical
details -- not to set the basic direction and goals for the whole
project. I've seen that latter kind of discussion can be difficult even
in a small group. So I would understand *if* you decided to do that part
in private. OTOH if you decided to try it in public, that's great, too.

Whatever way the discussion would take place, I was suggesting some
questions to discuss. That's what I was trying to say even if I didn't
write as clearly as I hoped.

-- 
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/8736j5chez.fsf%40greghendershott.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] datatypes

[Alex Knauth]

> On Jul 17, 2019, at 12:16 AM, Kevin Forchione  wrote:
> 
> Hi guys,
> Is there any function in Racket that will return a symbol representation of a 
> value’s datatype? We can interrogate them with predicates, but it occurs to 
> me that this information must be carried in the object’s syntax somewhere… 
> otherwise the syntax->datum wouldn’t work. Of course I may be overlooking 
> something :) 

I'm not sure what you mean by "carried in the object's syntax" or why 
syntax->datum is relevant. Could you clarify with a concrete example?

Anyway putting aside the syntax part and only looking at values, the `describe` 
[1] package, in particular the `variant` [2] function might be helpful to you 
or not depending on what you mean by "datatype".

> (require describe)
> (variant 5)
'fixnum-integer
> (variant (expt 2 65))
'bignum-integer
> (variant 3.0)
'inexact-number
> (variant 'auu)
'symbol
> (variant "oee")
'string
> (variant (list 1 2 3))
'pair
> (variant (list))
'empty-list
> (variant (vector 1 2 3))
'vector
> (variant (λ (x) x))
'procedure

  [1]: https://docs.racket-lang.org/describe/index.html
  [2]: 
https://docs.racket-lang.org/describe/index.html#%28def._%28%28lib._describe%2Fmain..rkt%29._variant%29%29

> Kevin

-- 
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/F748A593-C3DA-42CE-935F-FD2100022C66%40knauth.org.
For more options, visit https://groups.google.com/d/optout.

[racket-users] datatypes

[Kevin Forchione]

Hi guys,
Is there any function in Racket that will return a symbol representation of a 
value’s datatype? We can interrogate them with predicates, but it occurs to me 
that this information must be carried in the object’s syntax somewhere… 
otherwise the syntax->datum wouldn’t work. Of course I may be overlooking 
something :) 

Kevin

-- 
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/F70A7132-EBCC-48C9-84CB-43571402F543%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Christopher Lemmer Webber]

Matthew Flatt writes:

> The idea that the Racket project leadership is discussing this is
> entirely plausible, of course, given the way things have operated in
> the past. Let me emphasize again, however, that you should take Aaron
> Turon's keynote as evidence that we do not want to do things the same
> way this time.
>
>
>> So if Matthew wanted to decree that he's been working on this a
>> quarter century and just wants to change surface syntax, next
>
> Just in case anyone has forgotten, since the live stream was recorded,
> I can quote myself verbatim:
>
>  I am not standing here today saying this this is the direction we
>  should go. I want to get the idea out there and start a conversation
>  about what we should do.
>
>
> Apologies for answering your message very sparsely, but it's because I
> think your message part of a discussion that we should organize in a
> different way. Of course, I'm not stopping anyone from posting, anyway.
>
> I regret that I did not understand the importance of setting up a good
> forum for discussion before even offering the idea. Live and learn.

Hi Matthew,

Thanks for your response.  FWIW I really appreciated Aaron Turon's
keynote and I think it did give good indication that leadership hopes
to involve the community in the process.

In a way, Racket is also uniquely positioned to be able to experiment
here.  The #lang aspect of Racket means we can take a "try it before
we buy it" approach, or rather, before we go all in on buying it.  I
have been thinking the last few days that this even gives us
flexibility that whatever syntax is decided on could start out as a
"merely surface syntax" approach before moving to "core idioms": we
could try as a community to put that language's syntax on most of the
introductory documents and etc and teach courses with it for a period
before deciding to switch any key semantics, even if any were to
change.

I can't think of any other language environment that has the
opportunity for that level of experimentation, and that seems like a
feature to me.

That said, I do think that all of Greg's comments are useful food for
thought. :)

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

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

[Hendrik Boom]

On Tue, Jul 16, 2019 at 10:08:05PM -0400, Greg Hendershott wrote:
> p.p.p.s or whatever level of "p" I'm on:
> 
> The core team including Matthew have put decades of work into Racket.
> The effort and dedication is amazing. So if Matthew wanted to decree
> that he's been working on this a quarter century and just wants to
> change surface syntax, next, dammit? I would have no possible
> counter-argument or complaint.

Especially no complaint if #lang racket remains the language we use now.
We already have another popular surface syntax for racket: Scribble.
No conflict!

-- hendrik

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

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

[Matthew Flatt]

At Tue, 16 Jul 2019 21:55:03 -0400, Greg Hendershott wrote:
> The stated purpose of this change was to increase Racket's popularity.

The purpose I personally stated was to remove an obstacle to Racket
ideas. It's perhaps fair to characterize that as "increase Racket's
popularity", but I'd like to have my specific characterization here for
anyone who might care to draw a distinction.

> Of course, if the PLT team wants to discuss and decide, privately,
> that's their prerogative. In that case I wish they'd share some of the
> choices considered and rationale. This would help folks understand who
> Racket is intended for, going forward.

If any part of the Racket project leadership is discussing this, they
aren't including me, and I wouldn't participate at this point. We are,
however, currently discussing a proposal for a process for community
discussion about what we should do.

The idea that the Racket project leadership is discussing this is
entirely plausible, of course, given the way things have operated in
the past. Let me emphasize again, however, that you should take Aaron
Turon's keynote as evidence that we do not want to do things the same
way this time.


> So if Matthew wanted to decree that he's been working on this a
> quarter century and just wants to change surface syntax, next

Just in case anyone has forgotten, since the live stream was recorded,
I can quote myself verbatim:

 I am not standing here today saying this this is the direction we
 should go. I want to get the idea out there and start a conversation
 about what we should do.


Apologies for answering your message very sparsely, but it's because I
think your message part of a discussion that we should organize in a
different way. Of course, I'm not stopping anyone from posting, anyway.

I regret that I did not understand the importance of setting up a good
forum for discussion before even offering the idea. Live and learn.


Matthew


-- 
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/5d2e8a8e.1c69fb81.930d6.f075SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
For more options, visit https://groups.google.com/d/optout.

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

[Greg Hendershott]

p.p.p.s or whatever level of "p" I'm on:

The core team including Matthew have put decades of work into Racket.
The effort and dedication is amazing. So if Matthew wanted to decree
that he's been working on this a quarter century and just wants to
change surface syntax, next, dammit? I would have no possible
counter-argument or complaint. Really. I am incredibly grateful for
everything I've been able to learn and do with Racket.

At the same time, this seems like a juncture where Racket has an
opportunity to say who it is for, mostly. That is often a difficult
discussion because you can't be all things to everyone. And people can
feel some anxiety or irritation about change that they may or may not
want. I think the best thing to be done is go ahead and articulate who
Racket is for, people can digest and do whatever they need to do, and
things will eventually sort out fine.

-- 
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/874l3lct16.fsf%40greghendershott.com.
For more options, visit https://groups.google.com/d/optout.

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

[Greg Hendershott]

The stated purpose of this change was to increase Racket's popularity.

Someone asked, if Racket were already more popular, would this proposal
be made? The answer was, probably not.

It seems we're jumping over some questions:

1. More popular, among who?

   [About "research language": Is it primarily popularity in "academia",
   e.g. see more Racket in classrooms, in papers, and on conference
   slides. Or in "industry"? Of course both is nice, but if we ever must
   choose one as a priority, which one?]

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

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

4. Which are most likely to succeed? Which are most likely to backfire?

   [Backfire? See e.g. New Coke. Or Lotus 1-2-3 vs. Excel. Also, I have
some experience trying to make software products more popular.
Sometimes successfully. Sometimes not. It's difficult. Most things
you try, don't help. Some hurt. It is pretty typical for e.g.
salespeople to complain, "How can we sell more if we don't add
certain exact features the competition has?". This is the way of
salespeople. ;) Often the features are added, at great effort, and
it turns out not to help at all. Sometimes, it actually alienates
existing customers, who chose you for the distinctive feature the
salespeople wanted killed. No more customers, just worse
word-of-mouth.]

4. Do we have some sense of how to rank them on effort and risk?

5. Given all that, what should we do?


I think it would be a mistake to skip this discussion.

Of course, if the PLT team wants to discuss and decide, privately,
that's their prerogative. In that case I wish they'd share some of the
choices considered and rationale. This would help folks understand who
Racket is intended for, going forward.


-

p.s. I am NOT saying the following is what the decision should be. It is
only AN example. I don't even know if it would be my first choice --
because having the discussion is the whole point of figuring that out.
Having said that:

Let's say we wanted to aim (next, for now) for roughly "Clojure" level
of popularity. There are multiple companies using it, jobs, etc. It's
not nearly as popular as Java or Python, which is both good and bad.
Anyway, Clojure is relatively popular, "in spite of" sexprs, at least
partly because it runs on the JVM and JavaScript. As the Racket-on-Chez
effort concludes, and we wonder, what next, maybe a next step would be
to work on other backends, which IIRC was one of the stated benefits of
doing R-on-C.

Again, I'm not saying this is necessarily my preference or "vote". I'm
saying it's an example of a plan that flows from the previous plan.
People can understand why, immediately. It builds on top of Racket's
existing identity and "fan base", and keeps a distinctive feature.


p.p.s. The syntax proposal also seems to muddy the LoP and DSL messsage.
Maybe it's not strictly a contradiction. But it's a little confusing:
"LoP is great! You can choose the best way to express each part of each
program. Now, only some parts of some programs do a lot of math, for
which infix is nice. So guess what? We're going to urge everyone to
switch the default/public/core language to infix syntax. Just please
update documentation and books and tutorials and blog posts and gists
and Stack Exchange and"  So if this proposal indeed goes forward,
there probably needs to be some explainer or FAQ for this.

-- 
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/875zo1ctmw.fsf%40greghendershott.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

[Alexis King]

> On Jul 16, 2019, at 15:32, rocketnia  wrote:
> 
> I find it worrying that racket2 would be kicked off with infix syntax 
> (something which I think of as an unnecessary sticking point in the way of 
> prospective macro writers and language designers, and hence a move *toward* 
> elitism *as opposed to* welcoming everyone)


I think this fear is natural and understandable, but I want to take a moment 
and urge everyone to think bigger than that, even if we as programmers are 
often trained not to. Do not think “because we are moving to a syntax for which 
macros are harder to express, the language we create will have an inferior or 
more difficult to use macro system.” If we were setting out to responsibly 
engineer a new language on a deadline, that thought would be right on the 
money… but we’re not doing that. Racket is a research language, from an 
ever-growing community full of very smart people who have produced lots of 
quite significant research results. They have taken problems that used to seem 
untenable and made them perfectly achievable (and indeed, often achieved!).

So instead of thinking about all the ways Matthew’s proposed syntax is a 
compromise that necessarily comes with certain downsides, think of it as a 
challenge: how do we take all the lovely things we’ve come to enjoy and take 
for granted in #lang racket and do them in a language with a less regular 
syntactic structure? How do we make writing great macros as easy in #lang 
racket2 as it already is in #lang racket? That means figuring out both what the 
primitives are and what the DSLs look like—syntax/parse did not naturally 
follow from hygiene and syntax objects, as much as it sometimes feels that way. 
I am not saying it is easy, and I’m not saying it’s even guaranteed to 
eventually succeed: perhaps we will fail. But I don’t think we have any reason 
to suspect we will just yet.

It can’t start by being everything we want it to be, of course; things take 
time. I just think that thinking about things as such a stark dichotomy is 
disingenuous and self-defeating. Obviously, we should not aim to become more 
elitist, on any axes, so let’s aim not to be. This is time for pie-in-the-sky 
brainstorming, not risk management. Having existing research to build on helps, 
but even that isn’t required. So although I know firsthand how hard it can be 
as an software engineer to think about what we want without worrying about how 
we can build it, let’s be aspirational and exploratory for a bit.

Alexis

P.S. If your qualm with moving from s-expressions is one of aesthetics, not 
ease or ability, I admit I can’t argue with you there. But I don’t imagine 
those kinds of discussions are likely to go anywhere productive, anyway—see 
Wadler’s law.

-- 
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/B0910168-AB4F-43B7-A690-B01281CC8E59%40gmail.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

[Stephen De Gabrielle]

Thanks for reminding me of
https://github.com/racket/racket/wiki/Racket2

As it is mostly quite old, I’ve updated it with a link back to the RFC’s
repository.

Kind regards
Stephen
PS see you in London on Friday ;)

On Tue, 16 Jul 2019 at 19:46, Gustavo Massaccesi  wrote:

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

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

[rocketnia]

On Tuesday, July 16, 2019 at 11:46:16 AM UTC-7, gustavo wrote:
>
> I always imagined racket2 as racket with a few minor backward incompatible 
> changes, for example make `length` generic, drop `struct`, remove 
> guarantees about freshness of results. I.E. Most of 
> https://github.com/racket/racket/wiki/Racket2
>

Yeah, I second this. At one point I was looking forward to "racket2" 
because I'd like the language to remove struct subtyping. which is 
essentially a backwards-incompatible change to conventional notions of how 
first-class values in the Racket runtime work, something that would affect 
nearly all #langs. I've figured out techniques to work around this in what 
I'm doing (basically by using struct-like things that aren't quite 
structs), so I'm not very opinionated about it anymore, but this is the 
primary example of what I expected racket2 to be about. Many of the things 
on that page are similar, involving technical changes that more or less 
can't be achieved without backwards incompatibility.

As much as I find it worrying that racket2 would be kicked off with infix 
syntax (something which I think of as an unnecessary sticking point in the 
way of prospective macro writers and language designers, and hence a move 
*toward* elitism *as opposed to* welcoming everyone), I find it 
underwhelming that the next breath is "don't worry, we won't change #lang 
racket," since that dashes many of the reasons to hope for a racket2 in the 
first place.

- Nia

-- 
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/e569d802-cd9c-4e92-9762-3cd7d1c10286%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

[Gustavo Massaccesi]

I always imagined racket2 as racket with a few minor backward incompatible
changes, for example make `length` generic, drop `struct`, remove
guarantees about freshness of results. I.E. Most of
https://github.com/racket/racket/wiki/Racket2  I also don't like that
`syntax-property` is used to get and to set the properties but I doubt it's
a common opinion.

Perhaps I'm overestimating the changes, but this looks like a new language.
Why not use another name?

Also, it would be nice to have a rough timeline. 5 years?

Gustavo



On Sun, Jul 14, 2019 at 2:44 PM Christopher Lemmer Webber <
cweb...@dustycloud.org> wrote:

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

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

[Konrad Hinsen]

David Storrs  writes:

> The list is named racket-users, so the question of "who do we want as
> Racket users?" seems pretty on-point to me. Still, I get how it might not
> interest everyone. Maybe just mute this thread?

It's not so much this thread as future threads that are likely to
arrive, judging from what has happened in many other places.

The name of the list was chosen aeons ago in different circumstances,
so I don't think it should be the basis for defining the list's purpose
today. The question is rather whether we want to combine or separate
community introspection and community purpose. I am for separating.

Konrad.

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

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

[Ben Greenman]

More answers:

On 7/15/19, Hendrik Boom  wrote:
> (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.

For TeX, I tell Scribble exactly what characters to put in the document.
The same idea might work for mathML.

https://docs.racket-lang.org/scribble-abbrevs/index.html#(def._((lib._scribble-abbrevs%2Flatex..rkt)._~24))

The scribble-math package might be a better choice:
https://docs.racket-lang.org/scribble-math/index.html

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

You probably don't want to use Racket/Scribble for this, but here's a
pict / ppict
version of the diagram. (I don't know how to change the arrowheads.)

https://gist.github.com/bennn/1523efe1e6759c67c6f16118aa6543d5

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

Yes, @image{file.png}

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

https://groups.google.com/d/msg/racket-users/1cMufGgwtf0/-zTwzAKZAgAJ

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

Text can depend on an if-statement:

@(if (f x) @elem{this} @elem{that})


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

One way is to use @verbatim{} or @codeblock{}

But you can also play with linebreaks and hspace:
https://gist.github.com/bennn/b936b6caf8534b1a11b1bfa7de4e245c

-- 
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/CAFUu9R5vqgy%2BwPAcmBL0GekfTYUj3fpgUQaTiUQXp8rrPOaT0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Problem with `copy` method of image-snip%

[Kshitij Sachan]

Update:

I've narrowed down the problem to the `copy` method of the snip. When I 
delete the copy method, I can see the snip perfectly, but it can't be 
resized (because no copy method implemented).

I removed the GL component, so now I'm only attempting to extend the 
image-snip% class to resize a custom bitmap I load in (in my case just a 
plain red circle I drew). When I highlight over the snip with my cursor, I 
can see the bitmap below and it is resizing as well on a click (using 
`set-bitmap`). However, if I don't highlight over the snip it appears plain 
white.

Another observations that may or may not help is:
Calling (send s get-bitmap) always returns the bitmap of the same size, 
even if I've pressed on the snip several times to resize it.

Here's the simplified code:
(require racket/gui
 racket/gui/base)

;; bitmap stuff
(define bits (make-bitmap 250 250))
(define bits-dc (new bitmap-dc% [bitmap bits]))
(send bits-dc set-brush "red" 'solid)
(send bits-dc set-pen "black" 3 'solid)
(send bits-dc draw-ellipse 1 1 248 248)

(define snip (make-object image-snip% bits))

;; snip stuff
(define scroll-snip%
  (class image-snip%
(init bit-init)
(define snip-bitmap bit-init)
(inherit/super get-admin set-flags set-bitmap)
(init-field [w 100] [h 100])

(super-make-object snip-bitmap)
(set-flags (list 'handles-events))

(define/override (get-extent dc x y width height descent space lspace 
rspace)
  (define (maybe-set-box! b v) (when b (set-box! b v)))
  (maybe-set-box! width w)
  (maybe-set-box! height h)
  (maybe-set-box! descent 1.0)
  (maybe-set-box! space 1.0)
  (maybe-set-box! lspace 1.0)
  (maybe-set-box! rspace 1.0))

(define/override (on-char dc x y editorx editory event)
  (cond
[(equal? (send event get-key-code) 'down)
 (define admin (get-admin))
 (set! w (+ w 20))
 (set! h (+ h 20))

 ;; brush/pen/draw ellipse
 (define new-bits (make-object bitmap% w h))
 (send bits-dc set-bitmap new-bits)
 (send bits-dc draw-ellipse x y (- w 2) (- h 2))
 (set! snip-bitmap new-bits)
 
 (when admin
   (send admin resized this #t))]
[(equal? (send event get-key-code) 'up)
 (define admin (get-admin))
 (set! w (- w 20))
 (set! h (- h 20))

 ;; brush/pen/draw ellipse
 (define new-bits (make-object bitmap% w h))
 (send bits-dc set-bitmap new-bits)
 (send bits-dc draw-ellipse x y (- w 2) (- h 2))
 (super set-bitmap new-bits)
 
 (when admin
   (send admin resized this #t))]
[(equal? (send event get-key-code) 'escape)
 (define admin (get-admin))
 (set! w 150)
 (set! h 150)

 ;; brush/pen/draw ellipse
 (define new-bits (make-object bitmap% w h))
 (send bits-dc set-bitmap new-bits)
 (send bits-dc draw-ellipse x y (- w 2) (- h 2))
 (super set-bitmap new-bits)
 
 (when admin
   (send admin resized this #t))]))

(define/override (on-event dc x y editorx editory event)
  (cond
[(send event button-down?)
 (define admin (get-admin))
 (set! w (+ w 20))
 (set! h (+ h 20))

 ;; brush/pen/draw ellipse
 (define new-bits (make-object bitmap% w h))
 (send bits-dc set-bitmap new-bits)
 (send bits-dc draw-ellipse x y (- w 2) (- h 2))
 (super set-bitmap new-bits)
 
 (when admin
   (send admin resized this #t))]))

(define/override (draw dc x y left top right bottom dx dy draw-caret)
  ;; brush/pen/draw ellipse
  ;(define new-bits (make-object bitmap% w h))
  ;(send bits-dc set-bitmap new-bits)
  ;(send bits-dc draw-ellipse x y (- w 2) (- h 2))
  ;(set! snip-bitmap new-bits)
  (super draw dc x y left top right bottom dx dy draw-caret))

(define/override (copy)
  (make-object scroll-snip% snip-bitmap))
))

(define s (make-object scroll-snip% bits))
s

I believe there must be a problem with the default implementation of the 
`copy` method, but I don't know enough to parse what's going on there. Here 
is the Racket source code implementation of an 
image-snip% 
https://github.com/racket/snip/blob/1a0ef3670ebb13e8738d838db167c3abdbf3df28/snip-lib/racket/snip/private/snip.rkt#L888.

On Friday, July 12, 2019 at 1:19:39 PM UTC-4, Kshitij Sachan wrote:
>
> I've been trying to render an OpenGL context using a gl-bitmap and then 
> displaying that in a snip (to enable user input). I extended the image snip 
> class and overrode the basic methods to draw, get-extent, etc. 
>
> When I try to display my snip, I see nothing, but when I highlight over 
> the snip with my cursor I can see the shape underneath! It's clearly 
> rendering, and I can render the gl-bitmap by itself fine when it is not 
> connected to a snip. What could possibly be making my s

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

[Evelyn]

On Monday, July 15, 2019 at 3:38:22 PM UTC-6, Hendrik Boom wrote:
>
> (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. 
>
 
You might use https://tikzcd.yichuanshen.de/ as suggested by  
https://tex.stackexchange.com/questions/468894/diagrams-in-category-theory 
for the diagrams.

Evelyn Mitchell 

-- 
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/0adb781b-9fc7-47b8-8cbe-22d48b40e727%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[tbrooke]

Matthew Butterick may be able to jump in here and answer better than I can 
but you might want to look at Pollen https://docs.racket-lang.org/pollen/ and 
language that he built on top of Scribble for publishing both on the webs 
and in print

I am not sure about the speed since Pollen relies on Scribble but I do know 
that some large projects have been created with Pollen


On Monday, July 15, 2019 at 5:38:22 PM UTC-4, 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. 
>
> 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/0d37a842-6880-4367-958c-e6a5e6789587%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

[David Storrs]

On Tue, Jul 16, 2019, 5:31 AM Konrad Hinsen 
wrote:

> Sam,
>
> > Matthias, I disagree with this. First, we all believe that the Racket
> > community is one of the most important parts of Racket. Given that,
> > how to make it the community we want it to be, and how to welcome as
> > many new people to our community as possible, are fundamental to what
> > we discuss on this list.
>
> I can see the utility of a forum to discuss these questions, but does it
> have to be this list?
>
> My experience is that community introspection can easily invade on-line
> discussions to the point of drowning everything else, and driving away
> people who are more interested in the stated goal of the community than
> in its management and policies.
>
> Konrad.
>

The list is named racket-users, so the question of "who do we want as
Racket users?" seems pretty on-point to me. Still, I get how it might not
interest everyone. Maybe just mute this thread?

>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/c6319b95-b166-e29b-9d0d-2f1f2a3bd774%40fastmail.net
> .
> 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/CAE8gKodJjUfYb7udt9DWkydDVFfYHo%3D-CFFyaFOSuegF9oJAdA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Impromptu racket meetup in London Friday, 19 July at 12pm-3pm

[Laurent]

Good idea. I might come between 12pm and 1pm.

On Fri, Jul 12, 2019 at 8:36 PM zeRusski  wrote:

> argh, wish you'd go with after work hours or the weekend. Sorry, won't be
> able to make it.
>
> On Friday, 12 July 2019 09:20:58 UTC-6, Stephen De Gabrielle wrote:
>>
>> Hi,
>>
>> Next Friday, 19 July at 12pm-3pm there will be an impromptu Racket meetup
>> at the cafe at the British Library 'The Last Word'.
>> https://goo.gl/maps/M62e4b9JK7c1oaA69
>>
>> No agenda. All welcome. Spread the word!
>>
>> I'll be drinking tea, eating cake(I hope), and will be easily identified
>> as a the man with racket logo on his laptop. Updates on this thread.
>>
>> Stephen
>>
>> --
> 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/08648123-28e8-46ff-9bf8-20f0cb11d1dd%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/CABNTSaETaLbbQ9_6jns8%2Byn5hcSheWQqhxYObtr2cb4zV6MzYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket Week 2019 was amazing!

[Markus Pfeiffer]

I second that.

Even having done the school for a second time in as many years I still
learned a lot and thoroughly enjoyed my week in Salt Lake City immensely!

On Tue, Jul 16, 2019 at 4:44 AM Brian Adkins  wrote:

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

-- 
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/CAKj9DOGbVyQEZaLQvOUc1e4eN-ZFqPY_EDPTsQ-2y%3DDoWZHWng%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

[Konrad Hinsen]

Sam,

Matthias, I disagree with this. First, we all believe that the Racket 
community is one of the most important parts of Racket. Given that, 
how to make it the community we want it to be, and how to welcome as 
many new people to our community as possible, are fundamental to what 
we discuss on this list.


I can see the utility of a forum to discuss these questions, but does it 
have to be this list?


My experience is that community introspection can easily invade on-line 
discussions to the point of drowning everything else, and driving away 
people who are more interested in the stated goal of the community than 
in its management and policies.


Konrad.

--
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/c6319b95-b166-e29b-9d0d-2f1f2a3bd774%40fastmail.net.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket2 and syntax

[Thomas Burdick]

I thought I'd add my two cents here, as someone who's been using a mixed-syntax 
Lisp[*] daily for 15 years now. I've been working with electrical engineers, 
who aren't programmers, but obviously have a strong technical background.

Traditional algebraic notation for math (what Matthew noted as  + ) 
is a huge help. +-*/ and < <= == != >= > are all widely used and appreciated. = 
to mean set! was a bad idea. Programmers like it, but I've seen endless 
mistakes where someone meant it as equal.

It's helpful to have the functional version of these operators, too. I've seen 
people use especially add( expr expr expr ), where the sub-expressions were 
complex enough that you'd run into confusion about precedence when trying to 
add them together. add and times for + and * seem to be particularly helpful.

No one ever uses {} instead of begin. table[idx] is popular for numeric indexes 
(both forms are evaluated). As is table->name for symbolic indexes (only table 
is evaluated).

We have parentheses for disambiguation (ie, (a+b)*c vs a+(b*c)), but not 
arbitrary amounts of them. So ((a+b)) is going to complain that some number is 
not a function. I've almost never seen an over-parenthesized expression, and 
when I did, the engineer immediately understood what had gone wrong.

There are a few ways functions can be called: fn(arg arg arg), fn(arg,arg,arg), 
or (fn arg arg arg). People mostly use the first, and never or almost never use 
the second. The classic Lisp syntax is mostly used for syntax forms, where the 
puttuing the function name before the paren leads to a pileup of parens. Let is 
a good example:

  (let ((a 1) (b 2))
...)

Noone writes

  leta 1) (b 2))
...)

Instead you'll see either the Lisp style, or

  let( (a b)
   a=1
   b=2
   ...)

Another example is foreach, which is like a more limited version of Racket's 
for:

  foreach( elt lst
println(elt)
  )

But with multiple lists, people will revert to the Lisp style:

  (foreach (a b) lstA lstB
printf("a is %L, b is %L\n" a b)
  )

This mixed-mode with some Lisp-style function calls, and some C-style ones 
works out pretty well. Some of our syntax forms were adapted to work well with 
C-style, but if you get too many close parens, you'll start to see horrors like 
this:

 ) ; let
) ; if
   ) ; let
  ) ; define

Paren-matching in the editor doesn't seem to help dissuade them.

Those are the relevant bits of experience that I can think of. At a personal 
level, you get used to the syntax pretty quickly, and it doesn't make it feel 
less like a Lisp.

In the meantime, I no longer try to teach engineers classic text-based 
programming, unless they're independantly motivated. Instead, we built a visual 
programming system in which people who never would have touched a two-list 
foreach are happily building very complex programs, and even use the each2 
iterator. They happily write individual expressions textually (of the x+sin(y) 
sort, or string formatting or similar). I don't have the impression that an 
even better textual syntax would have made things much more accessible for 
assembling larger programs. But this is only glancingly relevant to Racket.

Cheers,
Thomas

[*] SKILL, which is a proprietary Lisp used in microelectronic CAD in Cadence 
Design Systems products. It has a weird history, with a Franz Lisp derived 
dialect, and a Scheme derived dialect. They both coexist in the image, and both 
use the same reader.

> Le 15 juillet 2019 à 04:29, Matthew Flatt  a écrit :
> 
> 
> 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".
> 
> You can find the recording here:
> 
>  https://www.youtube.com/watch?v=dnz6y5U0tFs
> 
> Start at 32:27 for the part about what Racket2 could be.
> 
> I'll produce a text version of the rationale soon. For now, I'd like to
> offer a few clarifications:
> 
>  * There is no specific proposal for a new syntax, yet. Our next step
>will be creating a process to explore a possible new syntax.
> 
>  * The talk does include some initial constraints that might guide the
>choice of a syntax. Even that meta level (i.e., the set of
>constraints) remains subject to a community process.
> 
>  * `#lang racket` is not going away and will always have its current
>parenthesis-oriented syntax. In the same way that Racket still
>supports `#lang scheme` and `#lang mzscheme` and even `(module
> mzscheme )` and even top-level programs, the Racket
>compiler and runtime system will always support `#lang racket`
>programs. We believe that Racket's `#lang`-based ecosystem makes it
>uniquely positioned for trying new language variants while
>preserving and building on our past investments.
> 
>  * Any new syntax must specifically preserve Racket-style
>language-oriented programming, which means everything from defining
>