Re: [Chicken-hackers] [PATCH] Turn chicken.condition into a module, with syntax exports!
On 2017-05-19 11:20, Peter Bex wrote: > I actually prefer using that hack of "internal" modules. Modules are a > standard approach that users will already be familiar with, which means > the barrier to entry should be slightly lower. And, also important, with > modules you get an error when you try to refer to a procedure that isn't > exported. So, if we remove a procedure for example, we will immediately > know when we forgot to remove a call site. H, this is true. I'm just a bit concerned about making things overly complicated within core. And, it isn't nice to make users deal with extra files just because it makes our own lives more convenient (for example when distributing a program as C files, where they now have to worry about an internal.c as well as runtime.c, library.c, and so on). But maybe it won't be a problem if we're considerate about it. > Besides, AFAIK non-exported module identifiers will be hidden by the > compiler, so we'd have to add another hack to prevent that. Actually, explicitly-namespaced identifiers, like qualified symbols, are not hidden, so that's no problem. Cheers, Evan signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Turn chicken.condition into a module, with syntax exports!
On Fri, May 19, 2017 at 01:10:03PM +1200, Evan Hanson wrote: > I think before we strip many more qualified symbols we should come up > with an idea of how to handle their replacements. With that "escape > hatch" change, we can now do basically whatever we want, and we can even > (for example) get rid of the "internal" module (always a bit of a hack, > and one that I'd like to see go away...), in favor of direct assignments > to whatever namespace we decide to use. I actually prefer using that hack of "internal" modules. Modules are a standard approach that users will already be familiar with, which means the barrier to entry should be slightly lower. And, also important, with modules you get an error when you try to refer to a procedure that isn't exported. So, if we remove a procedure for example, we will immediately know when we forgot to remove a call site. Besides, AFAIK non-exported module identifiers will be hidden by the compiler, so we'd have to add another hack to prevent that. > On 2017-05-07 21:47, Peter Bex wrote: > > PS: before you run "make check", you'll need to install and recompile > > with the new compiler (or just go through a chicken-boot process), > > there are some issues with the static linking tests otherwise. > > It was actually possible to compile this with the 5.0.0pre1 snapshot > directly, sans boot-chicken. I think any static linking test failures > you saw are probably related to #1366 and not the version used to > bootstrap. Oh right, I forgot about that one. Cheers, Peter signature.asc Description: Digital signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Turn chicken.condition into a module, with syntax exports!
Hi Peter, On 2017-05-07 21:45, Peter Bex wrote: > The core-library-reorganization page has "(chicken condition)" under > "undecided", but I think it's fine the way it is. The attached patches > add this module. These have been applied. Excellent work, it looks like these were tricky changes. > This time around, I minimised the number of ##sys# prefix removals, > to avoid complicating things too much. It's better to do that in > another pass; this changeset is complicated enough as it is. Thanks. This wasn't as tough to review as I'd expected, and that certainly helped. Thank you also for explaining the workarounds for bootstrapping. I think before we strip many more qualified symbols we should come up with an idea of how to handle their replacements. With that "escape hatch" change, we can now do basically whatever we want, and we can even (for example) get rid of the "internal" module (always a bit of a hack, and one that I'd like to see go away...), in favor of direct assignments to whatever namespace we decide to use. On 2017-05-07 21:47, Peter Bex wrote: > PS: before you run "make check", you'll need to install and recompile > with the new compiler (or just go through a chicken-boot process), > there are some issues with the static linking tests otherwise. It was actually possible to compile this with the 5.0.0pre1 snapshot directly, sans boot-chicken. I think any static linking test failures you saw are probably related to #1366 and not the version used to bootstrap. Cheers, Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Turn chicken.condition into a module, with syntax exports!
On Sun, May 07, 2017 at 09:45:07PM +0200, Peter Bex wrote: > Hi all, > > The core-library-reorganization page has "(chicken condition)" under > "undecided", but I think it's fine the way it is. The attached patches > add this module. PS: before you run "make check", you'll need to install and recompile with the new compiler (or just go through a chicken-boot process), there are some issues with the static linking tests otherwise. Cheers, Peter signature.asc Description: Digital signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
