[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Discoverability at the REPL level
From: |
Ludovic Courtès |
Subject: |
Re: Discoverability at the REPL level |
Date: |
Mon, 16 Nov 2020 12:46:02 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
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’.