From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id DDVsFlApsV9KRgAA0tVLHw (envelope-from ) for ; Sun, 15 Nov 2020 13:12:48 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id mOygEVApsV8wCgAAbx9fmQ (envelope-from ) for ; Sun, 15 Nov 2020 13:12:48 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 002FB9405D2 for ; Sun, 15 Nov 2020 13:12:47 +0000 (UTC) Received: from localhost ([::1]:47290 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1keHpm-00004u-M1 for larch@yhetil.org; Sun, 15 Nov 2020 08:12:46 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42362) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1keHpb-0008WP-GS for guix-devel@gnu.org; Sun, 15 Nov 2020 08:12:35 -0500 Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]:43054) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1keHpY-0006TU-3A for guix-devel@gnu.org; Sun, 15 Nov 2020 08:12:35 -0500 Received: by mail-wr1-x436.google.com with SMTP id s8so15713844wrw.10 for ; Sun, 15 Nov 2020 05:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=eiPM9NehD5i6OLiAkxruDSZ3OBUJHpgLesar/e7ijkE=; b=M+DeEe0qLJ6uVAu2hjl1+cxJ4dVV+KFFTS7YJ/tPOMs+e+Ov6eOkp4Nuyj+3rvZ63w WqKmmlUk7+RTYScM4Uksc4it1PdsRQehtg8jWZ2CCk0mKvhvQFSa5XIW3Ik4YnQdnFh5 aGntBfNi3QGBkNAZTYsrdQINlZqvwozz04Q7IgvOVQOxIBpLVEZvNPh5v/LriKXI9pyQ f8OkuOM2iubYzpjUM02P4RgI/rnbgEQfx9+XVpwBdwZ80MEjjtGXGkOiZvrfMME58lab RJnZgshnmE2I8B/AvNoA10tgcGXQsgS0eWDgUxRZgyIV8JnLbRWhdks0Gcl4ODLEIjVb qY+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=eiPM9NehD5i6OLiAkxruDSZ3OBUJHpgLesar/e7ijkE=; b=VLSDjV7FBnS+4AhzMcx6ot3C/Iha/C6M8JloyOWRdHCsrZqXe6g3VTUTghQ3H1YnlR hmFcFyanGkZK2+zDrqARRtNlkYceqwce8VhDGCJJ2IlyFIqWOrA/obmmOtx9vNRGIMQQ Hg2I0KiADUmsAzURmWfiN1xKy47B7Z7gJbXX1naZ1xYvybuaIKQHFeMZPC6guB1m9XEh JrmSohHqB7P4rR9py6XbB6PPnOHmdD0TXczRJhkGwp1rAsE1Q1xNecm3mqWNSLcXyU3L kCprTgu38DpPayNS8Uq2Z2J6ZW6KUWOV8LwJH4rgox9LpXvlBzgUhIEfA6mOxUaOU9Gr X1HA== X-Gm-Message-State: AOAM530u0Z7XQ+FSt/h4VFFY147bJN+DvdNQLnGfET30/FUfjiu7Fv5r vSzIVR99pv40IMXJJLLc9vz2gV7hR88F4w== X-Google-Smtp-Source: ABdhPJxyLXH8g4MLdZzFxcxgDNI0U2EKFCEdQ/eU0Wc3LAuw+aXH9N/j5+Gp59OWgsQT0gHlSfUsLA== X-Received: by 2002:adf:f005:: with SMTP id j5mr14106471wro.417.1605445949122; Sun, 15 Nov 2020 05:12:29 -0800 (PST) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id a17sm19882052wra.61.2020.11.15.05.12.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Nov 2020 05:12:28 -0800 (PST) From: zimoun To: Guix Devel Subject: Discoverability at the REPL level Date: Sun, 15 Nov 2020 14:02:04 +0100 Message-ID: <86d00evkmr.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::436; envelope-from=zimon.toutoune@gmail.com; helo=mail-wr1-x436.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=M+DeEe0q; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -1.71 X-TUID: 0GBnknRYSdMx Dear, Preparing the online Guix Days, maybe this discussion is worth. It echoes first with the talks =E2=80=9CGuix compared to Nix=E2=80=9D then wit= h the recent discussion about Emacs-Guix [1]. The topic is discoverability at the REPL level. Well, I have a proposal draft =C2=AB=E2=80=9Cguix repl=E2=80=9D and beyond= =C2=BB that I never sent, where the ideas was to discuss =E2=80=99~/.guile=E2=80=99 and how to = extend Guix ending with these questions: 1. Does Guix want a system of aliases? For example, let the script =E2=80=9C~/.config/guix/scripts/foo.scm=E2=80=9C and then =E2=80=98guix fo= o=E2=80=99. 2. How could the API be more discoverable? 3. Is the experimental =E2=80=98guix repl --gui=E2=80=99 reasonable? The #1 popup=E2=80=99ed 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.fsf@gmail.com/ 3: http://issues.guix.gnu.org/issue/38529#60 4: https://yhetil.org/guix-devel/CAF-xJgsynM3KSzuM__f9dSPUC0epJ2QKdFwDftiLh= TTuMfaTxw@mail.gmail.com 5: https://yhetil.org/guix-devel/87woitz1xx.fsf@gnu.org/ -------------------- Start of forwarded message -------------------- From: zimoun Cc: guix-days@gnu.org Date: Fri, 13 Nov 2020 19:20:21 +0100 Hi Ludo, On Mon, 09 Nov 2020 at 22:55, Ludovic Court=C3=A8s wrote: > Yeah I was also unsure; my idea was to give possible directions I had in > mind (hence the plural: =E2=80=9Cthe ways forward=E2=80=9D), with the und= erstanding that > it=E2=80=99s nothing but a personal choice. At =C2=ABapero=C2=BB 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 # 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 =E2=80=99,a=E2=80=99 could provide hint for th= e module to =E2=80=99,use=E2=80=99 and the =E2=80=99,d=E2=80=99 should provide both sig= nature and docstring. Since the naming is more or less regular =E2=80=99,a package bag=E2=80=99 should = list all the functions containing (name or docstring) the both terms so it becomes easy to find which module provide =E2=80=99package->bag=E2=80=99. Instead = on relying to ag+Ivy. ;-) Well, just sharing random ideas that popped up watching [1]. :-) 1: Cheers, simon -------------------- End of forwarded message -------------------- -------------------- Start of forwarded message -------------------- From: Ludovic Court=C3=A8s Cc: guix-days@gnu.org Date: Sun, 15 Nov 2020 12:25:29 +0100 Hi, zimoun skribis: > At =C2=ABapero=C2=BB break today, I have just watched [1] (speed 1.5) abo= ut 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 =E2=80=98guix search=E2=80=99 and =E2=80=98guix system search= =E2=80=99, 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=E2=80=A6 we have Guile modules when it comes to structuring code. :-) What we=E2=80=99re 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=E2=80=99t have yet is parameterized packages, but that motivate= s 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 # > 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 =E2=80=99,a=E2=80=99 could provide hint for = the module to > =E2=80=99,use=E2=80=99 and the =E2=80=99,d=E2=80=99 should provide both s= ignature and docstring. Since > the naming is more or less regular =E2=80=99,a package bag=E2=80=99 shoul= d list all the > functions containing (name or docstring) the both terms so it becomes > easy to find which module provide =E2=80=99package->bag=E2=80=99. Instea= d on relying to > ag+Ivy. ;-) Yes, but you=E2=80=99re 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=E2=80=99. -------------------- End of forwarded message --------------------