Re: [racket-users] Is there an expanded form of the Racket2 purpose declaration?
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?
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?
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?
> 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?
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?
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?
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?
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?
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?
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?
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.
[racket-users] Is there an expanded form of the Racket2 purpose declaration?
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.
