Re: [racket-users] Is there an expanded form of the Racket2 purpose declaration?

2019-08-29 Thread Konrad Hinsen
Robby Findler  writes:

> Of course, it is good to make it easy to move to new versions of the
> language, but if there is no real benefit to the transition for the
> programmer (eg they aren't planning to touch that code for the next N
> months anyway as it does its job well) then I think we should let them
> leave it alone and come to it when they need to.

I very much agree with that point of view!

Programmers come in so many varieties these days that it's hard to make
generally valid statements about them. Apple's approach has worked well
for them indeed, but that's in the context of commercial application
development for a dominantly technophile user base. Different contexts
(open source, educational, in-house software, ...) and different user
categories (banks, lawyers, scientists, ...) require different
approaches.

On the other hand, I am not sure that it is possible for a development
environment to stay completely neutral on the issue of mandatory change
and please everyone. But I'd love to be proven wrong about this.

For an in-depth analysis of this question in the specific context of
scientific computing, see

   https://hal.archives-ouvertes.fr/hal-02117588

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/m1k1aw33pg.fsf%40ordinateur-de-catherine--konrad.home.


Re: [racket-users] Is there an expanded form of the Racket2 purpose declaration?

2019-08-28 Thread Benjamin Yeung
On Wed, Aug 28, 2019 at 12:28 PM Jay McCarthy  wrote:
>
> I'll add that I see S-expressions as obviously limited and it would be
> nice to make a more powerful syntactic extension system that does not
> say, "You can have anything you want, provided it is a parenthesis."
>
> So for me, I don't see the syntax mission as having anything to do
> with students or getting people to like me, I see it as a way to go
> beyond the limitations of S-expressions and do something more powerful
> and interesting. I think people will like us more after in as much as
> I think people like awesome things, and I want to make something
> awesome.

I think this point tends to get lost in all the existing material.
It's already in the threads listed in the relevant posts section, but
if people aren't "primed" to look for this particular point in there,
it's easy to miss.  That's one of the takeaways I get when I hear
questions about the Racket2 purpose/goals/etc.  Perhaps it's coming as
part of the leadership team's meeting, but I think it would help
reframe the syntax experiment if this was put forward more explicitly.

Benjamin Yeung

-- 
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/CAL%2BBSUKzFD%2BVFRvYqmUjVKYbWZxKp3NJwcPQahbVuhW1ZH1m2w%40mail.gmail.com.


Re: [racket-users] Is there an expanded form of the Racket2 purpose declaration?

2019-08-28 Thread Robby Findler
On Wed, Aug 28, 2019 at 1:44 PM Breck Yunits  wrote:
>
> > I'm not sure this was clear, but I think the clear goal for backwards 
> > compatibility is that code that used to run continues to run indefinitely. 
> > With no changes. That's certainly what the Racket core developers mean by 
> > "backwards compatible".  In other words "requiring porting" is the opposite 
> > of "backwards compatible", at least in my mind.
>
> I get this, but I think it's a strategic mistake. I think the goal should be 
> to move people forward to the new versions (whenever they come out) as 
> quickly as possible (think Apple and the rapid adoption of new iOS versions, 
> compared to Microsoft). NEVER break people's stuff, but make it dead simple 
> for them to upgrade to the new stuff, by changing their code for them. I 
> think the success of Apple has proved this is the better long-term strategy.
>
> If Racket's truly a Language Oriented Programming language, than parsing it 
> and upgrading it should be dead simple. Otherwise, why would I want to use a 
> language that's difficult to upgrade?

I'm not sure I agree with this position, at least in the strong sense
it is written here.

In my opinion, it is essential that a good programming environment (by
that I mean the language, libraries, community, IDE, the whole ball of
wax) should support what the programmer needs -- that's the primary
goal. Things like making people move forward to new versions are good
for the developers of the language (eg, less to maintain etc) but a
programmer has needs that are often driven by their bottom line and if
the programming language/environment gets in the way of that decision,
programmers will stop using it ... in the worst case as they run out
of income because they're busy satisfying things other than their
bottom line.

Of course, it is good to make it easy to move to new versions of the
language, but if there is no real benefit to the transition for the
programmer (eg they aren't planning to touch that code for the next N
months anyway as it does its job well) then I think we should let them
leave it alone and come to it when they need to.

Robby

-- 
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/CAL3TdOMR%3D4kHDxUkwPyJc%2BeXWrg08DPfQz%2BAYLsh%3DwNTVxz9JQ%40mail.gmail.com.


Re: [racket-users] Is there an expanded form of the Racket2 purpose declaration?

2019-08-28 Thread Breck Yunits
> I'm not sure this was clear, but I think the clear goal for backwards
compatibility is that code that used to run continues to run indefinitely.
With no changes. That's certainly what the Racket core developers mean by
"backwards compatible".  In other words "requiring porting" is the opposite
of "backwards compatible", at least in my mind.

I get this, but I think it's a strategic mistake. I think the goal should
be to move people forward to the new versions (whenever they come out) as
quickly as possible (think Apple and the rapid adoption of new iOS
versions, compared to Microsoft). NEVER break people's stuff, but make it
dead simple for them to upgrade to the new stuff, by changing their code
for them. I think the success of Apple has proved this is the better
long-term strategy.

If Racket's truly a Language Oriented Programming language, than parsing it
and upgrading it should be dead simple. Otherwise, why would I want to use
a language that's difficult to upgrade?







On Wed, Aug 28, 2019 at 8:08 AM Hendrik Boom  wrote:

> On Wed, Aug 28, 2019 at 06:33:02AM -1000, Breck Yunits wrote:
> > I'd recommend investing work to make the problem of porting Racket1 code
> to
> > RacketN painless. Hopefully as simple as one method call.
>
> We already have such a mechanism.
>
> The Racket 1 code is prepended with
>
> #lang racket
>
> whereaas the Racket 2 code is prepended with
>
> #lang racket2
>
> and everything is interoperable.
>
> Simple enough?
>
> -- 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/20190828180751.ynkjzz2w3icf5vdw%40topoi.pooq.com
> .
>

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


Re: [racket-users] Is there an expanded form of the Racket2 purpose declaration?

2019-08-28 Thread Neil Van Dyke




and everything is interoperable.


That it will be interoperable is something that must be committed to, 
unambiguously -- it is not something #lang implementors get for free.


(Based-on-a-true-story example of bad interoperability... Your Racket 
module naturally uses lists, the Racket language is then changed to make 
lists immutable (and let's say it gets a new #lang for that), your old 
module #lang still works, but now you can only use new modules in the 
new #lang with difficulty and bug-prone-ness, and then an old 
third-party package you use is moved to the new #lang, so you are stuck 
on an old version of that or have to modify your code, or give up and 
rework all your code in the new #lang. There are ways that could've been 
avoided, but it didn't come for free, and didn't happen.)


--
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/1fabc200-3815-63f6-0e32-c44991bb48f3%40neilvandyke.org.


Re: [racket-users] Is there an expanded form of the Racket2 purpose declaration?

2019-08-28 Thread Hendrik Boom
On Wed, Aug 28, 2019 at 06:33:02AM -1000, Breck Yunits wrote:
> I'd recommend investing work to make the problem of porting Racket1 code to
> RacketN painless. Hopefully as simple as one method call.

We already have such a mechanism.

The Racket 1 code is prepended with

#lang racket

whereaas the Racket 2 code is prepended with

#lang racket2

and everything is interoperable.

Simple enough?

-- 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/20190828180751.ynkjzz2w3icf5vdw%40topoi.pooq.com.


Re: [racket-users] Is there an expanded form of the Racket2 purpose declaration?

2019-08-28 Thread David Storrs
Thanks, Jay.  I've responded to the RFC.

On Wed, Aug 28, 2019 at 12:28 PM Jay McCarthy 
wrote:

> My thoughts are in the thread you linked to:
>
> https://github.com/racket/racket2-rfcs/issues/105#issuecomment-521446706
> """
> I see Racket2 through the rubric of "We almost never break backwards
> compatible and insist on gradual evolution as the only way to make
> progress; but, now we are willing to make some radical changes: What
> can we do to make Racket drastically better that can't be expressed as
> an evolution?" In other words, I feel like Racket2 is defined as the
> goal, "Whatever makes Racket a lot better" and the design constraint,
> "It's okay to be incompatible."
> """
>
> When it comes specifically to syntax, which is what you seem to be
> asking about by reading the quote, here's a quote from my attempts to
> write this up before:
>
>
> https://github.com/racket/racket2-rfcs/pull/109/files#diff-f609e36bab3cb71c8829f58a5f9b2455R16
> """
> The uniformity of S-expressions limits the amount of information at
> the notational level of reading Racket programs. A small amount of
> extra notation can go a long way with a small number of mores on its
> use. For example, in Racket brackets are used in S-expressions when no
> function or macro application is implied (like in the cases of a
> `cond`); reading Racket programs without this notational affordance is
> more difficult. On the other hand, it is awkward to embed arbitrary
> fragments of code not in S-expression format, such as when quoting a
> program in another language. The only effective option is to embed a
> string. The Racket @-reader is helpful at this, but it is not
> uniformly available and the standard structure of Racket's
> S-expression based languages do not allow macro-specific reading of
> such syntaxes.
> """
>
> I'll add that I see S-expressions as obviously limited and it would be
> nice to make a more powerful syntactic extension system that does not
> say, "You can have anything you want, provided it is a parenthesis."
>
> So for me, I don't see the syntax mission as having anything to do
> with students or getting people to like me, I see it as a way to go
> beyond the limitations of S-expressions and do something more powerful
> and interesting. I think people will like us more after in as much as
> I think people like awesome things, and I want to make something
> awesome.
>
> Jay
>
> --
> Jay McCarthy
> Associate Professor @ CS @ UMass Lowell
> http://jeapostrophe.github.io
> Vincit qui se vincit.
>
> On Wed, Aug 28, 2019 at 1:09 AM David Storrs 
> wrote:
> >
> > The discussion on Racket2 seems to have moved offlist to the RFC list on
> github (https://github.com/racket/racket2-rfcs/issues); are there other
> locations?
> >
> > There is one question that I had back at the beginning of the process
> that I didn't manage to get clarity on, which is the rationale behind the
> whole thing.  I've gone back through some of the email discussion and gone
> through all 4 pages of the issues lists and read everything that seemed
> relevant.  The most apropos thing seems to be this:
> https://github.com/racket/racket2-rfcs/issues/105 but it still doesn't
> really speak to my question.
> >
> > My current understanding is that the rationale for the Racket2 effort
> looks something like this:
> >
> > "We, the core developers, many (all?) of whom are also academics with a
> lot of experience teaching Racket to new programmers, have noticed that
> parentheses and prefix notation are a stumbling block for many students.
> We would like to help the ideas of Racket spread into the larger
> community.  Therefore, we want to produce Racket2, which will have all the
> power of Racket but will get rid of parens and use infix notation, which
> will be more familiar and intuitive to students.  We also see this as a
> great time to improve existing elements of the language based on what we've
> learned since they were added, and potentially add new features."
> >
> > Is this in fact correct?  Is there more specific discussion of it
> somewhere that I've missed?  I don't want to make people retread the issue
> if it's already clearly laid out elsewhere.
> >
> > --
> > 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/CAE8gKodAh%2BdO3v8bx0bmPJYUhtDmVgX2KrxH8N3QwtG43aX%2BYg%40mail.gmail.com
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> 

Re: [racket-users] Is there an expanded form of the Racket2 purpose declaration?

2019-08-28 Thread Jay McCarthy
Exactly. We don't change anything about Racket 1 in a way that makes
any adaption needed. That's why putting a new "#lang" at the top of
new programs is such a big deal, because we can have a new level to
have backwards compatibility with for the NEXT 25 years.

Jay

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

On Wed, Aug 28, 2019 at 12:36 PM Robby Findler
 wrote:
>
> I'm not sure this was clear, but I think the clear goal for backwards
> compatibility is that code that used to run continues to run
> indefinitely. With no changes. That's certainly what the Racket core
> developers mean by "backwards compatible".  In other words "requiring
> porting" is the opposite of "backwards compatible", at least in my
> mind.
>
> Robby
>
> On Wed, Aug 28, 2019 at 11:33 AM Breck Yunits  wrote:
> >
> > I'd recommend investing work to make the problem of porting Racket1 code to 
> > RacketN painless. Hopefully as simple as one method call.
> >
> > If translating Racket1 code to RacketX is made an easy problem, then you 
> > can do what is best for RacketX without worrying about how backwards 
> > compatibility.
> >
> > That would pay dividends in other areas as well, regardless of what 
> > direction Racket2 goes in.
> >
> >
> > On Wed, Aug 28, 2019 at 6:28 AM Jay McCarthy  wrote:
> >>
> >> My thoughts are in the thread you linked to:
> >>
> >> https://github.com/racket/racket2-rfcs/issues/105#issuecomment-521446706
> >> """
> >> I see Racket2 through the rubric of "We almost never break backwards
> >> compatible and insist on gradual evolution as the only way to make
> >> progress; but, now we are willing to make some radical changes: What
> >> can we do to make Racket drastically better that can't be expressed as
> >> an evolution?" In other words, I feel like Racket2 is defined as the
> >> goal, "Whatever makes Racket a lot better" and the design constraint,
> >> "It's okay to be incompatible."
> >> """
> >>
> >> When it comes specifically to syntax, which is what you seem to be
> >> asking about by reading the quote, here's a quote from my attempts to
> >> write this up before:
> >>
> >> https://github.com/racket/racket2-rfcs/pull/109/files#diff-f609e36bab3cb71c8829f58a5f9b2455R16
> >> """
> >> The uniformity of S-expressions limits the amount of information at
> >> the notational level of reading Racket programs. A small amount of
> >> extra notation can go a long way with a small number of mores on its
> >> use. For example, in Racket brackets are used in S-expressions when no
> >> function or macro application is implied (like in the cases of a
> >> `cond`); reading Racket programs without this notational affordance is
> >> more difficult. On the other hand, it is awkward to embed arbitrary
> >> fragments of code not in S-expression format, such as when quoting a
> >> program in another language. The only effective option is to embed a
> >> string. The Racket @-reader is helpful at this, but it is not
> >> uniformly available and the standard structure of Racket's
> >> S-expression based languages do not allow macro-specific reading of
> >> such syntaxes.
> >> """
> >>
> >> I'll add that I see S-expressions as obviously limited and it would be
> >> nice to make a more powerful syntactic extension system that does not
> >> say, "You can have anything you want, provided it is a parenthesis."
> >>
> >> So for me, I don't see the syntax mission as having anything to do
> >> with students or getting people to like me, I see it as a way to go
> >> beyond the limitations of S-expressions and do something more powerful
> >> and interesting. I think people will like us more after in as much as
> >> I think people like awesome things, and I want to make something
> >> awesome.
> >>
> >> Jay
> >>
> >> --
> >> Jay McCarthy
> >> Associate Professor @ CS @ UMass Lowell
> >> http://jeapostrophe.github.io
> >> Vincit qui se vincit.
> >>
> >> On Wed, Aug 28, 2019 at 1:09 AM David Storrs  
> >> wrote:
> >> >
> >> > The discussion on Racket2 seems to have moved offlist to the RFC list on 
> >> > github (https://github.com/racket/racket2-rfcs/issues); are there other 
> >> > locations?
> >> >
> >> > There is one question that I had back at the beginning of the process 
> >> > that I didn't manage to get clarity on, which is the rationale behind 
> >> > the whole thing.  I've gone back through some of the email discussion 
> >> > and gone through all 4 pages of the issues lists and read everything 
> >> > that seemed relevant.  The most apropos thing seems to be this:  
> >> > https://github.com/racket/racket2-rfcs/issues/105 but it still doesn't 
> >> > really speak to my question.
> >> >
> >> > My current understanding is that the rationale for the Racket2 effort 
> >> > looks something like this:
> >> >
> >> > "We, the core developers, many (all?) of whom are also academics with a 
> >> > lot of experience teaching Racket to new programmers, have noticed that 
> >> > 

Re: [racket-users] Is there an expanded form of the Racket2 purpose declaration?

2019-08-28 Thread Robby Findler
I'm not sure this was clear, but I think the clear goal for backwards
compatibility is that code that used to run continues to run
indefinitely. With no changes. That's certainly what the Racket core
developers mean by "backwards compatible".  In other words "requiring
porting" is the opposite of "backwards compatible", at least in my
mind.

Robby

On Wed, Aug 28, 2019 at 11:33 AM Breck Yunits  wrote:
>
> I'd recommend investing work to make the problem of porting Racket1 code to 
> RacketN painless. Hopefully as simple as one method call.
>
> If translating Racket1 code to RacketX is made an easy problem, then you can 
> do what is best for RacketX without worrying about how backwards 
> compatibility.
>
> That would pay dividends in other areas as well, regardless of what direction 
> Racket2 goes in.
>
>
> On Wed, Aug 28, 2019 at 6:28 AM Jay McCarthy  wrote:
>>
>> My thoughts are in the thread you linked to:
>>
>> https://github.com/racket/racket2-rfcs/issues/105#issuecomment-521446706
>> """
>> I see Racket2 through the rubric of "We almost never break backwards
>> compatible and insist on gradual evolution as the only way to make
>> progress; but, now we are willing to make some radical changes: What
>> can we do to make Racket drastically better that can't be expressed as
>> an evolution?" In other words, I feel like Racket2 is defined as the
>> goal, "Whatever makes Racket a lot better" and the design constraint,
>> "It's okay to be incompatible."
>> """
>>
>> When it comes specifically to syntax, which is what you seem to be
>> asking about by reading the quote, here's a quote from my attempts to
>> write this up before:
>>
>> https://github.com/racket/racket2-rfcs/pull/109/files#diff-f609e36bab3cb71c8829f58a5f9b2455R16
>> """
>> The uniformity of S-expressions limits the amount of information at
>> the notational level of reading Racket programs. A small amount of
>> extra notation can go a long way with a small number of mores on its
>> use. For example, in Racket brackets are used in S-expressions when no
>> function or macro application is implied (like in the cases of a
>> `cond`); reading Racket programs without this notational affordance is
>> more difficult. On the other hand, it is awkward to embed arbitrary
>> fragments of code not in S-expression format, such as when quoting a
>> program in another language. The only effective option is to embed a
>> string. The Racket @-reader is helpful at this, but it is not
>> uniformly available and the standard structure of Racket's
>> S-expression based languages do not allow macro-specific reading of
>> such syntaxes.
>> """
>>
>> I'll add that I see S-expressions as obviously limited and it would be
>> nice to make a more powerful syntactic extension system that does not
>> say, "You can have anything you want, provided it is a parenthesis."
>>
>> So for me, I don't see the syntax mission as having anything to do
>> with students or getting people to like me, I see it as a way to go
>> beyond the limitations of S-expressions and do something more powerful
>> and interesting. I think people will like us more after in as much as
>> I think people like awesome things, and I want to make something
>> awesome.
>>
>> Jay
>>
>> --
>> Jay McCarthy
>> Associate Professor @ CS @ UMass Lowell
>> http://jeapostrophe.github.io
>> Vincit qui se vincit.
>>
>> On Wed, Aug 28, 2019 at 1:09 AM David Storrs  wrote:
>> >
>> > The discussion on Racket2 seems to have moved offlist to the RFC list on 
>> > github (https://github.com/racket/racket2-rfcs/issues); are there other 
>> > locations?
>> >
>> > There is one question that I had back at the beginning of the process that 
>> > I didn't manage to get clarity on, which is the rationale behind the whole 
>> > thing.  I've gone back through some of the email discussion and gone 
>> > through all 4 pages of the issues lists and read everything that seemed 
>> > relevant.  The most apropos thing seems to be this:  
>> > https://github.com/racket/racket2-rfcs/issues/105 but it still doesn't 
>> > really speak to my question.
>> >
>> > My current understanding is that the rationale for the Racket2 effort 
>> > looks something like this:
>> >
>> > "We, the core developers, many (all?) of whom are also academics with a 
>> > lot of experience teaching Racket to new programmers, have noticed that 
>> > parentheses and prefix notation are a stumbling block for many students.  
>> > We would like to help the ideas of Racket spread into the larger 
>> > community.  Therefore, we want to produce Racket2, which will have all the 
>> > power of Racket but will get rid of parens and use infix notation, which 
>> > will be more familiar and intuitive to students.  We also see this as a 
>> > great time to improve existing elements of the language based on what 
>> > we've learned since they were added, and potentially add new features."
>> >
>> > Is this in fact correct?  Is there more specific discussion of it 
>> > somewhere 

Re: [racket-users] Is there an expanded form of the Racket2 purpose declaration?

2019-08-28 Thread Breck Yunits
I'd recommend investing work to make the problem of porting Racket1 code to
RacketN painless. Hopefully as simple as one method call.

If translating Racket1 code to RacketX is made an easy problem, then you
can do what is best for RacketX without worrying about how backwards
compatibility.

That would pay dividends in other areas as well, regardless of what
direction Racket2 goes in.


On Wed, Aug 28, 2019 at 6:28 AM Jay McCarthy  wrote:

> My thoughts are in the thread you linked to:
>
> https://github.com/racket/racket2-rfcs/issues/105#issuecomment-521446706
> """
> I see Racket2 through the rubric of "We almost never break backwards
> compatible and insist on gradual evolution as the only way to make
> progress; but, now we are willing to make some radical changes: What
> can we do to make Racket drastically better that can't be expressed as
> an evolution?" In other words, I feel like Racket2 is defined as the
> goal, "Whatever makes Racket a lot better" and the design constraint,
> "It's okay to be incompatible."
> """
>
> When it comes specifically to syntax, which is what you seem to be
> asking about by reading the quote, here's a quote from my attempts to
> write this up before:
>
>
> https://github.com/racket/racket2-rfcs/pull/109/files#diff-f609e36bab3cb71c8829f58a5f9b2455R16
> """
> The uniformity of S-expressions limits the amount of information at
> the notational level of reading Racket programs. A small amount of
> extra notation can go a long way with a small number of mores on its
> use. For example, in Racket brackets are used in S-expressions when no
> function or macro application is implied (like in the cases of a
> `cond`); reading Racket programs without this notational affordance is
> more difficult. On the other hand, it is awkward to embed arbitrary
> fragments of code not in S-expression format, such as when quoting a
> program in another language. The only effective option is to embed a
> string. The Racket @-reader is helpful at this, but it is not
> uniformly available and the standard structure of Racket's
> S-expression based languages do not allow macro-specific reading of
> such syntaxes.
> """
>
> I'll add that I see S-expressions as obviously limited and it would be
> nice to make a more powerful syntactic extension system that does not
> say, "You can have anything you want, provided it is a parenthesis."
>
> So for me, I don't see the syntax mission as having anything to do
> with students or getting people to like me, I see it as a way to go
> beyond the limitations of S-expressions and do something more powerful
> and interesting. I think people will like us more after in as much as
> I think people like awesome things, and I want to make something
> awesome.
>
> Jay
>
> --
> Jay McCarthy
> Associate Professor @ CS @ UMass Lowell
> http://jeapostrophe.github.io
> Vincit qui se vincit.
>
> On Wed, Aug 28, 2019 at 1:09 AM David Storrs 
> wrote:
> >
> > The discussion on Racket2 seems to have moved offlist to the RFC list on
> github (https://github.com/racket/racket2-rfcs/issues); are there other
> locations?
> >
> > There is one question that I had back at the beginning of the process
> that I didn't manage to get clarity on, which is the rationale behind the
> whole thing.  I've gone back through some of the email discussion and gone
> through all 4 pages of the issues lists and read everything that seemed
> relevant.  The most apropos thing seems to be this:
> https://github.com/racket/racket2-rfcs/issues/105 but it still doesn't
> really speak to my question.
> >
> > My current understanding is that the rationale for the Racket2 effort
> looks something like this:
> >
> > "We, the core developers, many (all?) of whom are also academics with a
> lot of experience teaching Racket to new programmers, have noticed that
> parentheses and prefix notation are a stumbling block for many students.
> We would like to help the ideas of Racket spread into the larger
> community.  Therefore, we want to produce Racket2, which will have all the
> power of Racket but will get rid of parens and use infix notation, which
> will be more familiar and intuitive to students.  We also see this as a
> great time to improve existing elements of the language based on what we've
> learned since they were added, and potentially add new features."
> >
> > Is this in fact correct?  Is there more specific discussion of it
> somewhere that I've missed?  I don't want to make people retread the issue
> if it's already clearly laid out elsewhere.
> >
> > --
> > 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/CAE8gKodAh%2BdO3v8bx0bmPJYUhtDmVgX2KrxH8N3QwtG43aX%2BYg%40mail.gmail.com
> .
>
> --
> You received this message because 

Re: [racket-users] Is there an expanded form of the Racket2 purpose declaration?

2019-08-28 Thread Jay McCarthy
My thoughts are in the thread you linked to:

https://github.com/racket/racket2-rfcs/issues/105#issuecomment-521446706
"""
I see Racket2 through the rubric of "We almost never break backwards
compatible and insist on gradual evolution as the only way to make
progress; but, now we are willing to make some radical changes: What
can we do to make Racket drastically better that can't be expressed as
an evolution?" In other words, I feel like Racket2 is defined as the
goal, "Whatever makes Racket a lot better" and the design constraint,
"It's okay to be incompatible."
"""

When it comes specifically to syntax, which is what you seem to be
asking about by reading the quote, here's a quote from my attempts to
write this up before:

https://github.com/racket/racket2-rfcs/pull/109/files#diff-f609e36bab3cb71c8829f58a5f9b2455R16
"""
The uniformity of S-expressions limits the amount of information at
the notational level of reading Racket programs. A small amount of
extra notation can go a long way with a small number of mores on its
use. For example, in Racket brackets are used in S-expressions when no
function or macro application is implied (like in the cases of a
`cond`); reading Racket programs without this notational affordance is
more difficult. On the other hand, it is awkward to embed arbitrary
fragments of code not in S-expression format, such as when quoting a
program in another language. The only effective option is to embed a
string. The Racket @-reader is helpful at this, but it is not
uniformly available and the standard structure of Racket's
S-expression based languages do not allow macro-specific reading of
such syntaxes.
"""

I'll add that I see S-expressions as obviously limited and it would be
nice to make a more powerful syntactic extension system that does not
say, "You can have anything you want, provided it is a parenthesis."

So for me, I don't see the syntax mission as having anything to do
with students or getting people to like me, I see it as a way to go
beyond the limitations of S-expressions and do something more powerful
and interesting. I think people will like us more after in as much as
I think people like awesome things, and I want to make something
awesome.

Jay

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

On Wed, Aug 28, 2019 at 1:09 AM David Storrs  wrote:
>
> The discussion on Racket2 seems to have moved offlist to the RFC list on 
> github (https://github.com/racket/racket2-rfcs/issues); are there other 
> locations?
>
> There is one question that I had back at the beginning of the process that I 
> didn't manage to get clarity on, which is the rationale behind the whole 
> thing.  I've gone back through some of the email discussion and gone through 
> all 4 pages of the issues lists and read everything that seemed relevant.  
> The most apropos thing seems to be this:  
> https://github.com/racket/racket2-rfcs/issues/105 but it still doesn't really 
> speak to my question.
>
> My current understanding is that the rationale for the Racket2 effort looks 
> something like this:
>
> "We, the core developers, many (all?) of whom are also academics with a lot 
> of experience teaching Racket to new programmers, have noticed that 
> parentheses and prefix notation are a stumbling block for many students.  We 
> would like to help the ideas of Racket spread into the larger community.  
> Therefore, we want to produce Racket2, which will have all the power of 
> Racket but will get rid of parens and use infix notation, which will be more 
> familiar and intuitive to students.  We also see this as a great time to 
> improve existing elements of the language based on what we've learned since 
> they were added, and potentially add new features."
>
> Is this in fact correct?  Is there more specific discussion of it somewhere 
> that I've missed?  I don't want to make people retread the issue if it's 
> already clearly laid out elsewhere.
>
> --
> 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/CAE8gKodAh%2BdO3v8bx0bmPJYUhtDmVgX2KrxH8N3QwtG43aX%2BYg%40mail.gmail.com.

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