search

mighty-gerbils / gerbil

Gerbil Scheme
https://cons.io
GNU Lesser General Public License v2.1
1.14k stars 112 forks source link

Check that we re-export everything that Gambit provides #1092

Closed fare closed 2 months ago

fare commented 7 months ago

... or explicity mark symbols for non-reexport, as appropriate.

This way, when Gambit changes its set of provided identifiers, we will know and take action.

fare commented 7 months ago

e.g. I just used ##vector-set that we should definitely export somewhere (probably in :gerbil/gambit if not in <core>).

chiefnoah commented 7 months ago

proper-list? isn't exported, I had to use ##proper-list?

fare commented 7 months ago

@chiefnoah Do you want to assign this issue to yourself? Should be a nice and easy way to slip into deeper maintainership.

chiefnoah commented 7 months ago

Sure, I'd like some direction on how we want to approach this though :slightly_smiling_face:

fare commented 7 months ago

I would like a test in src/gerbil/test that would (1) collect a list of symbols from gambit, (2) collect a list of symbols from a set of modules, filtered by whether they are bound to a direct gambit symbol, (3) append a list of "do not export" symbols, (4) compute the difference.

fare commented 7 months ago

Note that in this case, vector-set is available without ## in gsi (in upstream gambit) and in gxi, but not from gxc. We should focus on the symbols available without ## first.

chiefnoah commented 6 months ago

Ok, I think I have some infrastructure to do this set up, what modules should we be looking at?

fare commented 6 months ago

I suppose all the modules loaded when your gerbil process is started—visible somehow by introspection, I presume—or else by looking at the source for what the runtime, prelude, expander and compiler define. Presumably only the runtime and prelude import things from Gambit.

fare commented 6 months ago

^ @vyzo can you advise on whether there is introspection available for what modules exist? Maybe through the __*modules* variable defined in runtime/eval.ss ?

And if not, what we should be looking at beside the (module ...) forms in prelude/core.ss

vyzo commented 6 months ago

It does not mark exports in any way, and honestly this should not be a runtime check at all!

I think the right way yo do it is to have a tool (part of the future linter perhaps) that reads and expands gerbil core/gambit, finds the runtime symbols and pethaps uses appropos or gambit's global variable table.

Note that the runtime modules are slated for some refactoring in the near future.

vyzo commented 2 months ago

this is done now, all symbols from gambit.sld are part of the runtime exports.