> The obvious reason would be a failure to compile with -j or -J. It's > probably surprising to newbies that it's not enough to write (module foo > ...) in a file "foo.scm" and then say "(use foo)" at the REPL; you have > to compile "foo.scm" with -J at the very least.
That's true. The "obvious" solution (to load the .so and "import" the module bindings) is only obvious to those who understand the underlying implementation. > >> >> * libchicken contains a number of entry-points, one for each library >> unit that comes with the core system. The registry must already have >> entries for these. Users might want to have to use a similar >> physical structure of their code, so we will have to provide means >> to add "default" registry entries, I think (I'm not completely >> sure right now - the resolution of the entry-points happens >> automatically by the linker, but we have to make later "import"s >> aware of this.) > > IMO this should be a special case for libchicken. I see no reason why > ordinary users should bundle multiple modules into a single .so file. It must be possible, though. There must at least be some low-level operation available. > >> * Currently "(declare (unit ...))" calls the entry-point, >> _initializing_ the compilation unit. Later "import"s will just >> incorporate the bindings. Do we want to initialize the compilation >> unit on the first "import"? If yes, we need to separate the notions >> of declaring an externally available entry-point and calling it, the >> latter being done (we hope) transparently by "import". > > Well, that is what `use` already does, no? "use" only does that the first time a dynamically loadable extension is loaded. Static entry-points (declared via "(declare (unit ...))") are called at the start of the toplevel code of the current compilation unit, before everything else (specifically, it produces a "##core#callunit" special form, inserted before the actual user code. felix _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
