Re: Discoverability at the REPL level

["Ludovic Courtès" <ludo@gnu.org>]

Hi!

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Sun, 15 Nov 2020 14:02:04 +0100
> zimoun <zimon.toutoune@gmail.com> wrote:
>
>> In an ideal world, the first ’,a’ could provide hint for the module to
>> ’,use’
>
> There is no "the" module.  Any number of modules could have your searched-for
> symbol--and the procedures so found could do completely unrelated things.  One
> of the points of using modules in the first place is in order to group together
> related things (and in order not to have unrelated things together).

Yup.

> What would be nice is for the module names to be easy to understand so you know
> which module to import.  That's currently not great.  For example I have no
> idea when something goes into (guix packages) vs (gnu packages).

There’s a rationale: (guix …) is for Guix-the-tool (the mechanisms)
whereas (gnu …) is for the distribution.  Thus,
‘specification->package’, which browses (gnu packages …), is in (gnu
packages).

Module names are chosen to reflect the architecture of the code, so it
can be opaque to a newcomer.  I’m sure we can improve but there’s
necessarily that limitation.

> Also, it would be nice and easy to implement to actually have the Guile REPL
> search for all possible loadable modules that contain some symbol if it
> encounters an unknown symbol, and print those, too (Guix often already does
> that anyway!).
>
> It should be easy to add such a thing to the guile repl.  In addition to
> ",describe" and ",apropos" there would be ",search" which would loop through
> all modules, find the specified symbol and then print the docstrings of each
> of those, including the module to use for each.
>
> But since these modules can contain code that runs at module import time,
> that's maybe also not what you want to actually happen (it would execute
> code of random modules that are in the search path).
> Then again, guile has declarative modules, too.  If those don't do that,
> maybe just search in those.
>
> Also, maybe you don't want Guile to actually IMPORT things into your namespace
> when you do ",search".  You just want guile to list them.  That would be the
> only complication.

Yeah the unbound-variable hint, for example, currently looks at
already-loaded modules.  Triggering extra loads could have undesirable
side effects: I/O storm, increased memory usage, unwanted code executed,
etc.

Likewise, bindings, docstrings, etc. are all things that exist in a live
Guile system.  So searching them normally involves loading all the code,
which is unreasonable.

Now, .go files are ELF these days, and they contain docstrings and a
symbol table.  So one could implement a module search that parses ELF
files, browses docstrings and symbols, thus without ever running code.
Andy, if you read this, what are your thoughts?

Thanks,
Ludo’.