Re: [Chicken-hackers] CR #1142 and upcoming changes
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 core reorganization may break code, but I'm looking at major releases from a user standpoint. What immediate benefit do those changes bring for users? Maybe R7RS support? Are those changes worth the breakage? Please, note that I'm not against those changes. Not at all, absolutely. I'm totally for them. I just wonder if they justify a major release and and all the burden to maintain another major version. I mentioned Unicode and bignums because, in my opinion, they are quite important for practical applications, and the support CHICKEN provides for them at the moment is not very appealing. Since you mentioned a new major release, why not making them part of it? Of course the obvious, realistic and straight-to-the-point answers are lack of manpower and lack of consensus on those topics, I know. 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 also hate forcing users into upgrading - I always detested this in other software and would like to spare those that need a working system, for whatever reason. I also don't see a reason _not_ to consider adding the features you talk about, but it shouldn't be the main driving force. If we can provide support for this, fine! But someone has to implement it (of course) So I think: let's just see how well we get along. We should definitely look into what would be required for bignum/unicode support, if someone is willing to evaluate this. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 also hate forcing users into upgrading - I always detested this in other software and would like to spare those that need a working system, for whatever reason. 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. I also don't see a reason _not_ to consider adding the features you talk about, but it shouldn't be the main driving force. If we can provide support for this, fine! But someone has to implement it (of course) So I think: let's just see how well we get along. We should definitely look into what would be required for bignum/unicode support, if someone is willing to evaluate this. No problem @ bignums. I don't know much about unicode, so that should probably be looked at by someone else. A simple thing we could include would be to reject all strings that have invalid UTF-8 encoding, like Postgres does that. I always really appreciated this feature of Postgres: it ensures that you don't get invalid data in your system, and prevents pollution and getting in character set hell, like happens all the time in MySQL: https://www.bluebox.net/insight/blog-article/getting-out-of-mysql-character-set-hell Adding rejection of non-UTF-8 strings would make the transition to a full Unicode system less painful (and perhaps make it possible to do it in a non-breaking way). I'm not sure how difficult this would be, though: all string mutation procedures should have a check that they won't create invalid strings by setting characters (bytes). Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 being. Once we figure out the remaining issues, this should be usable in a rather seamless way. Is this not the case? What are the goals for a Chicken 5 release? Mostly cleaning up. Shrinking the core system will make maintenance easier, and reduces the need to follow our usual patch-review process. It also allows to use alternatives to cast-in-concrete APIs (like srfi-18) in an easier way. A smaller core system makes it also easier to use it on embedded systems, in particular on systems that don't need loads of external libraries. Restructuring the libraries is required to make things easier for users, especially newcomers. The current library structure is mostly arbitrary. This is not a problem for long-time users, but where what procedure can be found is currently very unintuitive - one just has to know about it, or use tools like chicken-doc all the time. Finally, using more modules in core catches many errors related to wrong naming, or unintended cross-references between library units. Oh, and should we ever want to have a fully transparent import that always does The Right Thing, then a cleaned up and more modularized core will be essential to that. We really need to address the cruft that has accumulated over more than a decade... felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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. Yes, that was implied. No problem @ bignums. I don't know much about unicode, so that should probably be looked at by someone else. A simple thing we could include would be to reject all strings that have invalid UTF-8 encoding, like Postgres does that. I always really appreciated this feature of Postgres: it ensures that you don't get invalid data in your system, and prevents pollution and getting in character set hell, like happens all the time in MySQL: https://www.bluebox.net/insight/blog-article/getting-out-of-mysql-character-set-hell Adding rejection of non-UTF-8 strings would make the transition to a full Unicode system less painful (and perhaps make it possible to do it in a non-breaking way). I'm not sure how difficult this would be, though: all string mutation procedures should have a check that they won't create invalid strings by setting characters (bytes). Sounds like a good first step, even though I personally would prefer UCS-4 strings (constant lookup + modification and so on). But that seems to be unpopular, AFAICT... felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 server-side component for chicken-setup is no longer active. Is it? 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 being. Once we figure out the remaining issues, this should be usable in a rather seamless way. Works for me. I do think, however, that we should take a good look at the r7rs library names, and probably adopt them wholesale, for the parts that we implement. This would make CHICKEN easier to use for people using multiple Schemes, and for newbies coming from other Schemes. It would also ease our burden at figuring out good names: half of the stuff will suddenly *have* a good name. 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 R7RS-style parameters ;) Finally, using more modules in core catches many errors related to wrong naming, or unintended cross-references between library units. Oh, and should we ever want to have a fully transparent import that always does The Right Thing, then a cleaned up and more modularized core will be essential to that. We really need to address the cruft that has accumulated over more than a decade... proper cleanups are very dangerous. However, if done right, they can make life better. Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 large-scale overhaul we're planning on, but I also am a little afraid we'll lose the benefits it brings. I liked the fact that we spread knowledge through the patch review process: I really think we have started to make some progress towards getting more people up to speed about various parts of core. At least, I know more about the GC and the expander, and Evan knows more about the scrutinizer. If we completely change everything without going through the list that means we might get lots of new bugs (which we will anyway, I don't make any illusions about that, but it will be less bad if we have someone review the stuff), and nobody but the person who wrote the code will know how it works. Finally, by reviewing, we'll get useful feedback on alternative approaches to a particular problem (and typical bikesheds, of course. But in this process, we have the freedom to ignore anyone who doesn't submit patches). Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 R7RS-style parameters ;) +1, but what's wrong with R7RS parameters? They are entirely compatible with Chicken parameters AFAICT; the ability to mutate a parameter isn't present in R7RS, but R7RS documents that the effect of (p x) where p is a parameter is implementation-defined. The reason WG1 did that is so as not to have to worry about whether mutation in a parent thread, either before or after a child thread is created or started, affects the parameter value in the child, and per contra whether mutation in the child affects the parent. Different Schemes behave differently in these respects, as SRFI 39 documents. In Chicken, child threads capture the current value in the parent when they are created, and after that the parameters in the threads are independent. Leaving mutation explicitly implementation-dependent avoids having to resolve this issue in portable code. proper cleanups are very dangerous. However, if done right, they can make life better. Emphatic +1. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org And they pack their lyrics till they're so damn dense You could put 'em in your yard and you could use 'em for a fence. --Alan Chapman, Everybody Wants to Be Sondheim ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 identical, we may decide to tweak it to match R7RS. Except for R7RS-style parameters ;) +1, but what's wrong with R7RS parameters? They are entirely compatible with Chicken parameters AFAICT; the ability to mutate a parameter isn't present in R7RS, but R7RS documents that the effect of (p x) where p is a parameter is implementation-defined. As I understood Felix's comments at the time, R7RS parameterize behaves differently with threads. However, after re-reading the relevant section it appears that CHICKEN's parameterize is indeed perfectly compatible with R7RS. Maybe Felix can explain the nuances I missed again. It's unfortunate that R7RS mentioned threads here at all: it doesn't say anything about threads *anywhere* else, in the whole document. It should've left this undefined: threads are out of scope for the document. In Chicken, child threads capture the current value in the parent when they are created, and after that the parameters in the threads are independent. Leaving mutation explicitly implementation-dependent avoids having to resolve this issue in portable code. 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). Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 need to follow our usual patch-review process. I fully agree that the patch review process would be untenable for the kind of massive large-scale overhaul we're planning on, but I also am a little afraid we'll lose the benefits it brings. I'm not saying the changes for CHICKEN-5 should not be reviewed - I was talking about stuff that will be removed from the code (the/some srfi units, for example). Everything happening to the core system still needs the review process. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 inside body. It's the last part that I got wrong: I incorrectly assumed it may _not_ influence the values in threads created inside body. That assumption was incorrect, yes. `Parameterize` obviously affects parameter values in the current thread (or it would be useless), and may affect values in child threads created within the body. We don't spell out that it must not do so after the thread is created: exceptions are hard enough without exceptions to exceptions. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org But the next day there came no dawn, and the Grey Company passed on into the darkness of the Storm of Mordor and were lost to mortal sight; but the Dead followed them. --The Passing of the Grey Company ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 by parameterizing a mutable box, if you don't care about threads. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org If I have seen farther than others, it is because I was standing on the shoulders of giants. --Isaac Newton ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 AM, Peter Bex peter@xs4all.nl wrote: 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? Works for me. I do think, however, that we should take a good look at the r7rs library names, and probably adopt them wholesale, for the parts that we implement. This would make CHICKEN easier to use for people using multiple Schemes, and for newbies coming from other Schemes. It would also ease our burden at figuring out good names: half of the stuff will suddenly *have* a good name. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
