Dear,
Preparing the online Guix Days, maybe this discussion is worth. It
echoes first with the talks “Guix compared to Nix” then with the recent
discussion about Emacs-Guix [1].
The topic is discoverability at the REPL level.
Well, I have a proposal draft «“guix repl” and beyond» that I never
sent, where the ideas was to discuss ’~/.guile’ and how to extend Guix
ending with these questions:
1. Does Guix want a system of aliases? For example, let the script
“~/.config/guix/scripts/foo.scm“ and then ‘guix foo’.
2. How could the API be more discoverable?
3. Is the experimental ‘guix repl --gui’ reasonable?
The #1 popup’ed up in #38529 [2,3] and it is not related to
discoverablity but not orthogonal either.
The #3 means open Guile-Studio or any other front-end and echoes the
recent discussion about GUI front-end [4].
Therefore, here materials about the point #2. :-)
(The attentive reader is waiting for parametrized package PoC :-) and a
first discussion and arguments are this long thread [5].)
Feed back and ideas welcome. Especially about:
There are probably several ways to address it, including the
unbound-variable hints and documentation.
All the best,
simon
1: https://yhetil.org/guix-devel/87tuttci4z.fsf...@gnu.org
2: https://yhetil.org/guix-bugs/87y2jie1aj....@gmail.com/
3: http://issues.guix.gnu.org/issue/38529#60
4:
https://yhetil.org/guix-devel/caf-xjgsynm3kszum__f9dspuc0epj2qkdfwdftilhttumfa...@mail.gmail.com
5: https://yhetil.org/guix-devel/87woitz1xx....@gnu.org/
-------------------- Start of forwarded message --------------------
From: zimoun <zimon.touto...@gmail.com>
Cc: guix-d...@gnu.org
Date: Fri, 13 Nov 2020 19:20:21 +0100
Hi Ludo,
On Mon, 09 Nov 2020 at 22:55, Ludovic Courtès <l...@gnu.org> wrote:
> Yeah I was also unsure; my idea was to give possible directions I had in
> mind (hence the plural: “the ways forward”), with the understanding that
> it’s nothing but a personal choice.
At «apero» break today, I have just watched [1] (speed 1.5) about Nix
modules (I do not know if it makes sense in the Guix context, anyway).
>From my opinion, one interesting point is discoverability.
Guile is still a bit mysterious to me but a lot of tooling could be done
in this area. For example, I am directly grepping in the Guix sources
to find the function names or which module provides which function, etc.
When you come from Python or Haskell (to name the few I know), the
experience is poor. Even if Emacs+Geiser+Completion helps.
For a concrete example of annoyance,
--8<---------------cut here---------------start------------->8---
$ guix repl
scheme@(guix-user)> ,a fold-packages
scheme@(guix-user)> ,use(gnu packages)
scheme@(guix-user)> ,a fold-packages
(gnu packages): fold-packages #<procedure fold-packages (proc init #:optional
modules #:key select?)>
scheme@(guix-user)> ,d fold-packages
Call (PROC PACKAGE RESULT) for each available package defined in one of
MODULES that matches SELECT?, using INIT as the initial value of RESULT. It
is guaranteed to never traverse the same package twice.
--8<---------------cut here---------------end--------------->8---
So I have to know beforehand the module to import (and I personally do
not know how to list all the functions that the module exports) then use
,apropos and ,describe to know the signature and if it is what I want.
In an ideal world, the first ’,a’ could provide hint for the module to
’,use’ and the ’,d’ should provide both signature and docstring. Since
the naming is more or less regular ’,a package bag’ should list all the
functions containing (name or docstring) the both terms so it becomes
easy to find which module provide ’package->bag’. Instead on relying to
ag+Ivy. ;-)
Well, just sharing random ideas that popped up watching [1]. :-)
1: <https://youtu.be/7sQa04olUA0?t=5183>
Cheers,
simon
-------------------- End of forwarded message --------------------
-------------------- Start of forwarded message --------------------
From: Ludovic Courtès <l...@gnu.org>
Cc: guix-d...@gnu.org
Date: Sun, 15 Nov 2020 12:25:29 +0100
Hi,
zimoun <zimon.touto...@gmail.com> skribis:
> At «apero» break today, I have just watched [1] (speed 1.5) about Nix
> modules (I do not know if it makes sense in the Guix context, anyway).
> From my opinion, one interesting point is discoverability.
I think some of the criticism that applies to Nix does not apply to
Guix: we have ‘guix search’ and ‘guix system search’, we have package
transformation options (which achieve some of what people want to do
with Nixpkgs overlays), source code location shows up in search results,
etc.
Representing packages as functions is Nixpkgs is the root of
non-discoverability. Conversely, packages, service types, etc. are
top-level declarations.
And… we have Guile modules when it comes to structuring code. :-)
What we’re seeing here is an example of a DSL that grows and grows until
it includes all the features that general-purpose languages have.
What we don’t have yet is parameterized packages, but that motivates me
to come up with a PoC.
> Guile is still a bit mysterious to me but a lot of tooling could be done
> in this area. For example, I am directly grepping in the Guix sources
> to find the function names or which module provides which function, etc.
> When you come from Python or Haskell (to name the few I know), the
> experience is poor. Even if Emacs+Geiser+Completion helps.
>
> For a concrete example of annoyance,
>
> $ guix repl
> scheme@(guix-user)> ,a fold-packages
> scheme@(guix-user)> ,use(gnu packages)
> scheme@(guix-user)> ,a fold-packages
> (gnu packages): fold-packages #<procedure fold-packages (proc init #:optional
> modules #:key select?)>
> scheme@(guix-user)> ,d fold-packages
> Call (PROC PACKAGE RESULT) for each available package defined in one of
> MODULES that matches SELECT?, using INIT as the initial value of RESULT. It
> is guaranteed to never traverse the same package twice.
>
> So I have to know beforehand the module to import (and I personally do
> not know how to list all the functions that the module exports) then use
> ,apropos and ,describe to know the signature and if it is what I want.
>
> In an ideal world, the first ’,a’ could provide hint for the module to
> ’,use’ and the ’,d’ should provide both signature and docstring. Since
> the naming is more or less regular ’,a package bag’ should list all the
> functions containing (name or docstring) the both terms so it becomes
> easy to find which module provide ’package->bag’. Instead on relying to
> ag+Ivy. ;-)
Yes, but you’re talking about API discovery here, which is different
from discoverability for package options from the CLI.
There are probably several ways to address it, including the
unbound-variable hints and documentation.
Perhaps worth discussing on guix-devel! (You can share this message if
you want.)
Ludo’.
-------------------- End of forwarded message --------------------
