On Sat, Oct 31, 2015 at 03:46:38PM +1300, Evan Hanson wrote: > On 2015-10-30 8:18, Evan Hanson wrote: > > Yeah, I very nearly omitted the -main-module option, too. It's pretty > > silly and I'd be happy to see it go. > > Attached is a patch doing this. I've also pushed these commits to the > "chicken-5-named-module-option" branch.
Thanks, I've merged this into chicken-5. > On 2015-10-30 8:18, Evan Hanson wrote: > > On 2015-10-29 20:06, Peter Bex wrote: > > > This is a bit of a niche option, isn't it? I don't really see the use > > > of it: nothing gets exported anyway, so why should the name of the > > > module matter? Besides, wrapping something in a module isn't really > > > that useful, except maybe to catch errors. > > > > I'd also like to switch the default behaviour to export everything, but > > haven't gotten to testing that out yet. That way it's still useful as a > > "program wrapper" (since you won't be using those exports anyway), but > > also useful when compiling many different files together. > > OK, so I think there are two valid options here and I'm not sure which > is better. > > 1. Make the flag export everything as I suggested before. This works > fine, it's easy to understand, but it's slightly less flexible than > option 2: > > 2. Keep the flag's behaviour as it is, exporting nothing, and let > users (export ...) any identifiers they want to be exported when > the file is compiled as a module. (This works well since export > forms occurring outside of a module are simply ignored.) > > I think I'm partial to #2. That way, the flag still works as a program > linter of sorts, but it's also generally useful as a way to control > compilation in multi-file projects. > > Thoughts? I also prefer 2. This also allows for inlining when you're only using the option to wrap things in a module for linting purposes. Besides, exporting absolutely everything is rarely a good idea anyway. Cheers, Peter
signature.asc
Description: Digital signature
_______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers