From: Bengt Richter <bokr@bokr.com>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: New review checklist
Date: Sat, 2 Apr 2022 15:38:00 +0200 [thread overview]
Message-ID: <20220402133800.GA2462@LionPure> (raw)
In-Reply-To: <01ff99a0452cb12718938646388302ac372a7416.camel@gmail.com>
Hi Liliana, Maxime, et al,
On +2022-04-01 20:25:37 +0200, Liliana Marie Prikler wrote:
> Hi Maxime,
>
> Am Freitag, dem 01.04.2022 um 19:46 +0200 schrieb Maxime Devos:
> > [...]
> > I know there have been some discussions in the past about whether
> > git-version should be used when a commit is explicitly chosen,
> > whether
> > tags should be used instead of commits, how high a risk there a is that
> > version->commit can become multi-valued, ‘tricking peer review’ ...
> >
> > However, my question isn't about any of that. It is only about the
> > let-binding itself, in situations where the bound variable is only
Here ISTM important to understand exactly what you mean by "let-binding"
so I would really like it if I could type
--8<---------------cut here---------------start------------->8---
info guile let-binding
--8<---------------cut here---------------end--------------->8---
into my command line interpreter, and get right to the details
as I often can for other things, e.g.
--8<---------------cut here---------------start------------->8---
info guile define-macro
--8<---------------cut here---------------end--------------->8---
This suggests to me something like a translation project, except
not bewween local natural languages, but between
expert guile/guix implementer's terminology and detailed explanations
that various level programmers can go into as deeply as they want (following
suggested reading if not included in the info doc itself).
I am also imagining info could be instrumented to emit a minimal email
to a server that could accumulate statistics on no-hit lookups,
and that this could be visible in some tool when someone
feels like contributing to make
--8<---------------cut here---------------start------------->8---
info guile what-does-this-mean
--8<---------------cut here---------------end--------------->8---
produce a result that we can all refer to when we want/need
to say "that's what I am talking about."
After getting past foot-binding and other bindings, wikipedia
got me to [0], which might be a nice read-further hint, but
what did Maxime mean, out of all those possibilities?
[0] https://en.wikipedia.org/wiki/Scope_(computer_science)
To be really precise, if he could point to a formal definition
in some style from [1]
[1] https://en.wikipedia.org/wiki/Denotational_semantics
that could really nail it when such detail was necessary.
Of course,
--8<---------------cut here---------------start------------->8---
info guile define-language
--8<---------------cut here---------------end--------------->8---
leads to wonder-land. But if you just want a quick check
that you have the right concept for something you read,
well, good luck in RL -- in fact I just missed a local
library music event because I was reading guile info docs to
make examples for this post -- i.e. got drawn into reading
about define-language and not watching the time ;-/
I think for best effect, there should be no dependencies to prevent
usage anywhere "info guile" answers usefully at the command line.
Anyone else want to know exactly what Maxime meant by "let-binding" ? :)
> > used in a single place. What is the reason for doing
> >
> > (let ((commit "cabba9e..."))
> > (package
> > (name "foobar")
> > (version "0.1.2")
> > (source (origin ...
> > ;; this is the only use of the 'commit' variable bound
> > in
> > ;; the above 'commit'
> > (commit commit)))
> > ...))
> >
> > when it can be simplified to
> >
> > (packaeg
> > (name "foobar")
> > (version "0.1.2")
> > (source (origin ... (commit "cabba9e..."))))?
> >
> > I mean, we don't do this for, say, 'name', 'version' and 'uri':
> >
> > ;; these three variables are only used in a single location
> > (let ((name "foobar")
> > (version "0.1.2")
> > (uri "https://foo.bar"))
> > (package
> > (name name)
> > (version version)
> > (source (origin (uri uri) (commit <some-reference>) [...]))
> > ...))
> >
> > Why would things be different for 'commit' here? How does putting
> > the value of 'commit' in a let-form reduce surprises?
> The main goal of let-binding commit and revision is to allow for easier
> change. Suppose you need to reference some half-release for some
> obscure reason, then this style makes it easier to switch to what is
> already established praxis.
>
> In general, consider the poor soul who may have to read and maintain
> your code after you get hit by a car because neither busses nor trams
> run in your region.
>
--
Regards,
Bengt Richter
next prev parent reply other threads:[~2022-04-02 13:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-01 4:14 New review checklist Liliana Marie Prikler
2022-04-01 6:30 ` Maxime Devos
2022-04-01 17:03 ` Liliana Marie Prikler
2022-04-01 17:46 ` Maxime Devos
2022-04-01 18:25 ` Liliana Marie Prikler
2022-04-02 13:38 ` Bengt Richter [this message]
2022-04-02 14:45 ` Liliana Marie Prikler
2022-04-01 18:05 ` Tobias Geerinckx-Rice
2022-04-01 6:56 ` tanguy
2022-04-01 8:31 ` Jonathan McHugh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220402133800.GA2462@LionPure \
--to=bokr@bokr.com \
--cc=guix-devel@gnu.org \
--cc=liliana.prikler@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).