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
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
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
> >
> 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
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
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
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
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
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
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
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
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
12 matches
Mail list logo
