In fact, as a user, I was just trying to bring some topics that are
practical issues and that we could piggyback with the breaking changes
to make a major release.
I'm not sure reorganizing the core and making it smaller justifies a
major release. I understand some changes caused by the
On Tue, Aug 19, 2014 at 10:20:56AM +0200, Felix Winkelmann wrote:
I understand your concerns, but doing all the planned changes piece by
piece will be a massive maintenance effort and the compatibility hacks
required to have something halfway working during the transition will
be even more. I
I would think that support for Chicken 2 3 should be dropped after a
Chicken 5 branch is made.
Yes, that sounds reasonable.
I had also implicitly assumed that the modularisation changes would help
bring full R7RS support to core.
I think it is R7RS support will be in an egg for the time
To avoid doing this again soon, I think the other change you suggested
should definitely be included: the reworking of internal libraries by
splitting them up. Perhaps you already assumed this would be included,
I don't think I have seen this mentioned yet so I wanted to put it out
there.
On Tue, Aug 19, 2014 at 05:21:06PM +0200, Felix Winkelmann wrote:
I would think that support for Chicken 2 3 should be dropped after a
Chicken 5 branch is made.
Yes, that sounds reasonable.
I didn't know we still supported CHICKEN 2 and 3. In what way is that
done? AFAIK the
On Tue, Aug 19, 2014 at 05:21:06PM +0200, Felix Winkelmann wrote:
Mostly cleaning up. Shrinking the core system will make maintenance
easier, and reduces the need to follow our usual patch-review process.
I fully agree that the patch review process would be untenable for
the kind of massive
Peter Bex scripsit:
Note that this does _not_ imply we should implement things that we
don't already have, just move the things we do have under the names
defined by R7RS. If we have something that's close to R7RS but not
identical, we may decide to tweak it to match R7RS. Except for
On Tue, Aug 19, 2014 at 01:19:35PM -0400, John Cowan wrote:
Peter Bex scripsit:
Note that this does _not_ imply we should implement things that we
don't already have, just move the things we do have under the names
defined by R7RS. If we have something that's close to R7RS but not
I didn't know we still supported CHICKEN 2 and 3. In what way is that
done? AFAIK the server-side component for chicken-setup is no longer
active. Is it?
I wouldn't know myself, to be honest.
felix
___
Chicken-hackers mailing list
From: Peter Bex peter@xs4all.nl
Subject: Re: [Chicken-hackers] CR #1142 and upcoming changes
Date: Tue, 19 Aug 2014 18:23:22 +0200
On Tue, Aug 19, 2014 at 05:21:06PM +0200, Felix Winkelmann wrote:
Mostly cleaning up. Shrinking the core system will make maintenance
easier, and reduces the
The way parameters and threads work right now is perfect for CHICKEN,
and there are various libraries that make use of this (most notably
Spiffy, which relies on it heavily).
It's also the only behaviour that makes sense, IMHO.
felix
___
Felix Winkelmann scripsit:
It is written:
I'm glad to see you are treating R7RS-small as scripture!
If an implementation supports multiple threads, then parameterize
must not change the associated values of any parameters in any thread
other than the current thread and threads created
Felix Winkelmann scripsit:
It's also the only behaviour that makes sense, IMHO.
Well, I think doing parameters in Chicken style but with only immutable
parameters is also a reasonable choice. Currently, no Scheme I know of
makes that choice. You can always portably emulate multiple parameters
The Chicken wiki still has an index of Chicken 3 eggs, although I do think
chicken-setup is no longer operational.
Perhaps now would be a good time to clean the wiki of vestigial references
to 2 3.
I also like the idea of adopting the r7rs library names.
-Ivan
On Wed, Aug 20, 2014 at 1:13
14 matches
Mail list logo
