Re: [Chicken-hackers] [PATCH] Moving some things from library.scm and eval.scm to internal.scm
On 2017-06-05 12:11, Peter Bex wrote: > On Mon, Jun 05, 2017 at 05:53:32PM +1200, Evan Hanson wrote: > > On 2017-06-04 13:53, Peter Bex wrote: > > > Regarding time specifically, there are not many stand-alone programs > > > that will use this macro, I think. It's more a thing for benchmarks > > > and such, so I'm not even sure it must be part of library. It probably > > > was in there because the macro was in the "chicken" module. There's a > > > lot of stuff that's much less optional than "time" (as in, used by day > > > to day programs) that lives in other units like file.scm. > > > > True. I do think the support code for `time` would be good to move, if > > we can sort out the dependency issues. > > What exactly are the dependency issues you're concerned about? AFAIK > there's a simple rule: if you use the "time" macro, you'll need to > include internal.scm into your program. That's pretty straightforward, > IMHO. Besides, you also need to know that you need to include, say, > extras.scm when using "randomize" from (chicken random). > > The only difference here is that it's the _expansion_ that requires the > unit rather than the direct call. Is that the issue? Basically, yes. In this case the compiler won't take care of loading the internal unit for you, so you're left with an unmet dependency unless you know to load that unit explicitly, or happen to do so incidentally. Currently, things are in a good state because: you can't use `time` until you import "chicken", importing "chicken" loads the library unit, the library unit provides the support procedures needed by `time`, and everything's groovy. By moving the support procedures out of library this fails to be the case, so from my point of view it's a regression. Additionally, this is a problem that won't even be caught at compile time. You'll just end up with an unbound value in the expansion of `time`, resulting in with segfaults and the like. > Maybe we can fix the situation by adding something to the manual to > indicate which units map to which modules. This would solve this > problem more generally, including the "randomize" example I gave above. Yeah, I do think we should include that information in the manual. We can put it in a little note in the corner of each module page or something, similarly to how rubydoc.info has a "Defined in: foo.rb" section. However, if we end up putting macro support code in a different unit than that loaded by the module exporting the macro itself, do we note the runtime or compile-time unit? Both? I really think it's simpler to just keep these things together for now, until we can add some smarts to the compiler. > We still haven't decided on which module "time" should go into, so maybe > that's part of the problem (it's missing completely from c-l-r). True... Apparently I put it where it is, though I don't remember doing that so I probably just did what seemed right at the time (heh). It's not at all similar to the other procedures in that module, but it is clearly time-related. Are there any other benchmarking-related things that could make a happy family together? Doesn't really look like it, but maybe that's not a problem... Put it in extras? Eggify it? Leave it where it is? Any other hackers have thoughts about this? 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] Moving some things from library.scm and eval.scm to internal.scm
On Mon, Jun 05, 2017 at 05:53:32PM +1200, Evan Hanson wrote: > Hey Peter, > > On 2017-06-04 13:53, Peter Bex wrote: > > Regarding time specifically, there are not many stand-alone programs > > that will use this macro, I think. It's more a thing for benchmarks > > and such, so I'm not even sure it must be part of library. It probably > > was in there because the macro was in the "chicken" module. There's a > > lot of stuff that's much less optional than "time" (as in, used by day > > to day programs) that lives in other units like file.scm. > > True. I do think the support code for `time` would be good to move, if > we can sort out the dependency issues. What exactly are the dependency issues you're concerned about? AFAIK there's a simple rule: if you use the "time" macro, you'll need to include internal.scm into your program. That's pretty straightforward, IMHO. Besides, you also need to know that you need to include, say, extras.scm when using "randomize" from (chicken random). The only difference here is that it's the _expansion_ that requires the unit rather than the direct call. Is that the issue? Maybe we can fix the situation by adding something to the manual to indicate which units map to which modules. This would solve this problem more generally, including the "randomize" example I gave above. We still haven't decided on which module "time" should go into, so maybe that's part of the problem (it's missing completely from c-l-r). > It's also probably possible to > make the compiler generate code to load units as they're required by > macro expansions, but that's sure to have other implications so I'm not > super keen to go there right now. I agree that would be nice but is a bit too complex right now. Maybe we'll take a look at this for 5.1 or 5.2. 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] Moving some things from library.scm and eval.scm to internal.scm
Hey Peter, On 2017-06-04 13:53, Peter Bex wrote: > Regarding time specifically, there are not many stand-alone programs > that will use this macro, I think. It's more a thing for benchmarks > and such, so I'm not even sure it must be part of library. It probably > was in there because the macro was in the "chicken" module. There's a > lot of stuff that's much less optional than "time" (as in, used by day > to day programs) that lives in other units like file.scm. True. I do think the support code for `time` would be good to move, if we can sort out the dependency issues. It's also probably possible to make the compiler generate code to load units as they're required by macro expansions, but that's sure to have other implications so I'm not super keen to go there right now. > > All that said, I'm definitely in favour of dropping the optional > > arguments in mini-srfi-1.scm and using that file's procedures in > > csi.scm, and I'd be happy to apply those bits on their own right away. > > Please do. We can argue about where to put the support stuff later :) Great, done. 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] Moving some things from library.scm and eval.scm to internal.scm
> I think we should strive to make library the first, and potentially the > only, unit that the user needs to care about when distributing compiled > C or compiling programs with "-explicit-use". These changes move things > further away from that ideal by making programs that use the `time` > macro (and probably `syntax-rules`, though I haven't looked at that > quite as closely) depend not just on library but also on internal, and > without adding anything to make sure the internal unit will actually be > loaded as necessary. An example program that will no longer work is the > following: > > ;; compile with `csc -x example.scm` > (import chicken) > (time (print 1)) > > Even without the "-x", it's only due to the fact that the eval unit is > loaded by default that this program runs at all, since that unit depends > on internal. +1 It is extremely handy to be able to ship just a few C files for distributing a file. I used this approach for some language implementations built on top of the CHICKEN runtime. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Moving some things from library.scm and eval.scm to internal.scm
On Sun, Jun 04, 2017 at 11:20:06PM +1200, Evan Hanson wrote: > I'm concerned about the way these introduce an implicit dependency from > the library unit to the internal unit. > > I think we should strive to make library the first, and potentially the > only, unit that the user needs to care about when distributing compiled > C or compiling programs with "-explicit-use". I see what you mean. > So, what is the intended purpose of these changes? If it's to shrink > library.scm, I think there are probably other things in that file that > could moved more easily and that wouldn't have this problem, but if it's > just nicer organisation of CHICKEN's source code for our own sake then > I'd rather not make these particular changes. It was to shrink library.scm, but also to move an internal procedure that's rarely used (!), like the runtime support for the "time" macro elsewhere. By moving it to "internal", it clearly signals to users that they should not rely on the procedure directly. The idea would be to have all the stuff that's not supposed to be used into "internal". Regarding time specifically, there are not many stand-alone programs that will use this macro, I think. It's more a thing for benchmarks and such, so I'm not even sure it must be part of library. It probably was in there because the macro was in the "chicken" module. There's a lot of stuff that's much less optional than "time" (as in, used by day to day programs) that lives in other units like file.scm. > All that said, I'm definitely in favour of dropping the optional > arguments in mini-srfi-1.scm and using that file's procedures in > csi.scm, and I'd be happy to apply those bits on their own right away. Please do. We can argue about where to put the support stuff later :) 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] Moving some things from library.scm and eval.scm to internal.scm
Hi Peter, Sorry for the delay, I should have responded earlier. On 2017-06-03 15:07, Peter Bex wrote: > On Wed, May 03, 2017 at 08:29:12AM +0200, Peter Bex wrote: > > On Mon, May 01, 2017 at 06:02:51PM +1200, Evan Hanson wrote: > > > Hi folks, > > > > > > Just wanted to mention that I've already applied the first of these > > > patches; that one is clearly a nice change and definitely where those > > > procedures belong, good call. > > > > Is there a problem with the other ones, or have you just not had time > > to properly review them? > > Anyone have some time to look at the remaining two patches of this > post? It's been sitting here without comments for a month. I'm concerned about the way these introduce an implicit dependency from the library unit to the internal unit. I think we should strive to make library the first, and potentially the only, unit that the user needs to care about when distributing compiled C or compiling programs with "-explicit-use". These changes move things further away from that ideal by making programs that use the `time` macro (and probably `syntax-rules`, though I haven't looked at that quite as closely) depend not just on library but also on internal, and without adding anything to make sure the internal unit will actually be loaded as necessary. An example program that will no longer work is the following: ;; compile with `csc -x example.scm` (import chicken) (time (print 1)) Even without the "-x", it's only due to the fact that the eval unit is loaded by default that this program runs at all, since that unit depends on internal. So, what is the intended purpose of these changes? If it's to shrink library.scm, I think there are probably other things in that file that could moved more easily and that wouldn't have this problem, but if it's just nicer organisation of CHICKEN's source code for our own sake then I'd rather not make these particular changes. All that said, I'm definitely in favour of dropping the optional arguments in mini-srfi-1.scm and using that file's procedures in csi.scm, and I'd be happy to apply those bits on their own right away. 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] Moving some things from library.scm and eval.scm to internal.scm
On Wed, May 03, 2017 at 08:29:12AM +0200, Peter Bex wrote: > On Mon, May 01, 2017 at 06:02:51PM +1200, Evan Hanson wrote: > > Hi folks, > > > > Just wanted to mention that I've already applied the first of these > > patches; that one is clearly a nice change and definitely where those > > procedures belong, good call. > > Is there a problem with the other ones, or have you just not had time > to properly review them? Anyone have some time to look at the remaining two patches of this post? It's been sitting here without comments for a month. 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] Moving some things from library.scm and eval.scm to internal.scm
On Mon, May 01, 2017 at 06:02:51PM +1200, Evan Hanson wrote: > Hi folks, > > Just wanted to mention that I've already applied the first of these > patches; that one is clearly a nice change and definitely where those > procedures belong, good call. Is there a problem with the other ones, or have you just not had time to properly review them? Cheers, Peter signature.asc Description: Digital signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
