From: Mark H Weaver <mhw@netris.org>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>, guix-devel@gnu.org
Subject: Re: On raw strings in <origin> commit field
Date: Sun, 02 Jan 2022 07:25:13 -0500 [thread overview]
Message-ID: <87v8z2b9yz.fsf@netris.org> (raw)
In-Reply-To: <b3bfa7b57b527d78aeb21dee6123c617a90fc13d.camel@gmail.com>
Hi Liliana,
Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> Am Samstag, dem 01.01.2022 um 15:19 -0500 schrieb Mark H Weaver:
>> Hi Liliana,
>>
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>>
>> > Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver:
>> > > I disagree with the last line above. What makes you think that
>> > > I'm presupposing that the tag does change?
>> > >
>> > > There's a difference between "presupposing that the tag does
>> > > change" and "not assuming that the tag will not change". Do you
>> > > see the difference?
>> > I'm pretty sure ¬assume(¬X) = assume(¬¬X) in this concept.
> To correct my own typo here, I meant context, not concept.
>
>> No, that's certainly false. On the left-hand side of that equation
>> there is an absence of any assumptions, and on the right-hand side
>> there is the assumption that ¬¬X is true.
>>
>> Perhaps something is getting lost in translation between our
>> languages.
Repeating myself: our difficulties understanding each other on this
point might be due a translation issue. Earlier, you wrote:
> And here I disagree. This reasoning presupposes that we have to ensure
> that the package still points to the same commit if the tag changes,
> which itself presupposes that the tag does change.
and I replied (quoted above) "I disagree with the last line above".
However, I'll note that a single-word substitution would eliminate my
objection. If you substitute "might change" or "could change" in place
of "does change" in the text above above, then I would more-or-less
agree with what you wrote.
In English, the phrases "could change" and "might change" indicate a
/possibility/ of change. In other words, they indicate an absence of
knowledge about whether change will occur.
On the other hand, "does change" suggests to my ears (as a native
English speaker) that change is /known to occur/. In other words, if
you say "X does change" and then X is observed to remain constant over
some suitably long time interval, that would call into question the
veracity of your words.
To give an example from the Scheme programming language, if you showed
me the following code template:
(let ((LST '(1 2 3)))
<body>)
I would say "LST could change". I would *not* say "LST does change".
With this in mind, here are your words again:
> And here I disagree. This reasoning presupposes that we have to ensure
> that the package still points to the same commit if the tag changes,
> which itself presupposes that the tag does change.
In the last line, you're telling me that my reasoning "presupposes that
the tag does change", which to my ears suggests that you think I'm
assuming that _every_ tag will be mutated sooner or later.
If, instead, the last line above read: "which itself presupposes that
the tag *could* change", that essentially means that I'm preparing for
the /possibility/ of change, which is true.
What do you think?
Regards,
Mark
--
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about <https://stallmansupport.org>.
next prev parent reply other threads:[~2022-01-02 12:27 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-28 20:55 On raw strings in <origin> commit field Liliana Marie Prikler
2021-12-29 8:39 ` zimoun
2021-12-29 20:25 ` Liliana Marie Prikler
2021-12-30 12:43 ` zimoun
2021-12-31 0:02 ` Liliana Marie Prikler
2021-12-31 1:23 ` zimoun
2021-12-31 3:27 ` Liliana Marie Prikler
2021-12-31 9:31 ` Ricardo Wurmus
2021-12-31 11:07 ` Liliana Marie Prikler
2021-12-31 12:31 ` Ricardo Wurmus
2021-12-31 13:18 ` Liliana Marie Prikler
2021-12-31 13:15 ` zimoun
2021-12-31 15:19 ` Liliana Marie Prikler
2021-12-31 17:21 ` zimoun
2021-12-31 20:52 ` Liliana Marie Prikler
2021-12-31 23:36 ` Mark H Weaver
2022-01-01 1:33 ` Liliana Marie Prikler
2022-01-01 5:00 ` Mark H Weaver
2022-01-01 10:33 ` Liliana Marie Prikler
2022-01-01 20:37 ` Mark H Weaver
2022-01-01 22:55 ` Liliana Marie Prikler
2022-01-02 22:57 ` Mark H Weaver
2022-01-03 21:25 ` Liliana Marie Prikler
2022-01-03 23:14 ` Mark H Weaver
2022-01-04 19:55 ` Liliana Marie Prikler
2022-01-04 23:42 ` Mark H Weaver
2022-01-05 9:28 ` Mark H Weaver
2022-01-05 20:43 ` Liliana Marie Prikler
2022-01-06 10:38 ` Mark H Weaver
2022-01-06 11:25 ` Liliana Marie Prikler
2022-01-02 19:30 ` zimoun
2022-01-02 21:35 ` Liliana Marie Prikler
2022-01-03 9:22 ` zimoun
2022-01-03 18:13 ` Liliana Marie Prikler
2022-01-03 19:07 ` zimoun
2022-01-03 20:19 ` Liliana Marie Prikler
2022-01-03 23:00 ` zimoun
2022-01-04 5:23 ` Liliana Marie Prikler
2022-01-04 8:51 ` zimoun
2022-01-04 13:15 ` zimoun
2022-01-04 19:45 ` Liliana Marie Prikler
2022-01-04 19:53 ` zimoun
2021-12-31 23:56 ` Mark H Weaver
2022-01-01 0:15 ` Liliana Marie Prikler
2021-12-30 1:13 ` Mark H Weaver
2021-12-30 12:56 ` zimoun
2021-12-31 3:15 ` Liliana Marie Prikler
2021-12-31 7:57 ` Taylan Kammer
2021-12-31 10:55 ` Liliana Marie Prikler
2022-01-01 1:41 ` Mark H Weaver
2022-01-01 11:12 ` Liliana Marie Prikler
2022-01-01 17:45 ` Timothy Sample
2022-01-01 19:52 ` Liliana Marie Prikler
2022-01-02 23:00 ` Timothy Sample
2022-01-03 15:46 ` Ludovic Courtès
2022-01-01 20:19 ` Mark H Weaver
2022-01-01 23:20 ` Liliana Marie Prikler
2022-01-02 12:25 ` Mark H Weaver [this message]
2022-01-02 14:09 ` Liliana Marie Prikler
2022-01-02 2:07 ` Bengt Richter
2021-12-31 17:56 ` Vagrant Cascadian
2022-01-03 15:51 ` Ludovic Courtès
2022-01-03 16:29 ` Vagrant Cascadian
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=87v8z2b9yz.fsf@netris.org \
--to=mhw@netris.org \
--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).