Re: [Chicken-hackers] [C5] `extension' components & non-modules
On 2017-05-31 12:19, felix.winkelm...@bevuta.com wrote:
> Ok, how about a new .egg extension property named "(modules NAME1 ...)"?
> Defaulting to one module (the extension name). Keeping the list empty
> ("(modules)") specifies an extension without modules.
I like this idea, flexible but with a sane default.
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [C5] `extension' components & non-modules
Hello, On Wed, 31 May 2017 11:34:19 +0200 felix.winkelm...@bevuta.com wrote: >> Should extension components specified in .egg files be required to be >> modules? >> >> If I understand correctly, that's the case at the moment, as the build >> script will try to compile .import.scm files supposedly emited for files >> specified as extensions (they might not exist if the files don't declare >> a module). >> >> Should we allow non-modules to be specified as extension components? >> >> What about files that declare multiple modules? > > All good questions. I'm for making this as simple as possible. The overhead > for having a module for each extension shouldn't be too much and there > appears to me (at least at this stage) no disxadvantage of requiring an > extension to be a module. Is there a particular use-case that would make > the current approach problematic? I sometimes resort to the case of "moduleless" extensions when I need to load code in runtime, and want the loaded files to be able to use symbols from the loader (e.g., configuration files with Scheme code). All the best. Mario -- http://parenteses.org/mario ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [C5] `extension' components & non-modules
Hello,
On Wed, 31 May 2017 12:19:07 +0200 felix.winkelm...@bevuta.com wrote:
> Ok, how about a new .egg extension property named "(modules NAME1 ...)"?
> Defaulting to one module (the extension name). Keeping the list empty
> ("(modules)") specifies an extension without modules.
Sounds very good.
All the best.
Mario
--
http://parenteses.org/mario
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [C5] `extension' components & non-modules
On Wed, May 31, 2017 at 12:19:07PM +0200, felix.winkelm...@bevuta.com wrote:
> > > The multi-module case is indeed not covered. There is an note on the
> > > wiki regarding functors that emit 2 import libs (used in some places),
> > > this has to be handled automatically (compile + install .import.so
> > > and _.import.so, if the latter one exists). Another option would
> > > be
> > > to add .egg properties specifying the output modules.
> >
> > If I recall correctly, the s48-modules egg also generates two modules per
> > package declaration: one that's "internal" with a leading underscore and
> > one that's the actual module for public consumption.
>
> Right, that's what I meant.
Note that this is something else than the functor internal modules!
The functor ones are _.import.so, while s48 generates
_.import.so
because it has a different function (it's a base module from which several
derived modules can export subsets, via define-structures).
> > So there's some precedence of having a single source file that exports
> > multiple modules. I think it's worth supporting.
>
> Ok, how about a new .egg extension property named "(modules NAME1 ...)"?
> Defaulting to one module (the extension name). Keeping the list empty
> ("(modules)") specifies an extension without modules.
Sounds good!
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] [C5] `extension' components & non-modules
> > The multi-module case is indeed not covered. There is an note on the
> > wiki regarding functors that emit 2 import libs (used in some places),
> > this has to be handled automatically (compile + install .import.so
> > and _.import.so, if the latter one exists). Another option would be
> > to add .egg properties specifying the output modules.
>
> If I recall correctly, the s48-modules egg also generates two modules per
> package declaration: one that's "internal" with a leading underscore and
> one that's the actual module for public consumption.
Right, that's what I meant.
> So there's some precedence of having a single source file that exports
> multiple modules. I think it's worth supporting.
Ok, how about a new .egg extension property named "(modules NAME1 ...)"?
Defaulting to one module (the extension name). Keeping the list empty
("(modules)") specifies an extension without modules.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [C5] `extension' components & non-modules
On Wed, May 31, 2017 at 11:34:19AM +0200, felix.winkelm...@bevuta.com wrote: > All good questions. I'm for making this as simple as possible. The overhead > for having a module for each extension shouldn't be too much and there > appears to me (at least at this stage) no disxadvantage of requiring an > extension to be a module. Is there a particular use-case that would make > the current approach problematic? > > The multi-module case is indeed not covered. There is an note on the > wiki regarding functors that emit 2 import libs (used in some places), > this has to be handled automatically (compile + install .import.so > and _.import.so, if the latter one exists). Another option would be > to add .egg properties specifying the output modules. If I recall correctly, the s48-modules egg also generates two modules per package declaration: one that's "internal" with a leading underscore and one that's the actual module for public consumption. And of course CHICKEN itself also does this in several files. So there's some precedence of having a single source file that exports multiple modules. I think it's worth supporting. 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] [C5] `extension' components & non-modules
> Should extension components specified in .egg files be required to be > modules? > > If I understand correctly, that's the case at the moment, as the build > script will try to compile .import.scm files supposedly emited for files > specified as extensions (they might not exist if the files don't declare > a module). > > Should we allow non-modules to be specified as extension components? > > What about files that declare multiple modules? All good questions. I'm for making this as simple as possible. The overhead for having a module for each extension shouldn't be too much and there appears to me (at least at this stage) no disxadvantage of requiring an extension to be a module. Is there a particular use-case that would make the current approach problematic? The multi-module case is indeed not covered. There is an note on the wiki regarding functors that emit 2 import libs (used in some places), this has to be handled automatically (compile + install .import.so and _.import.so, if the latter one exists). Another option would be to add .egg properties specifying the output modules. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
