guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On raw strings in <origin> commit field


From: Liliana Marie Prikler
Subject: Re: On raw strings in <origin> commit field
Date: Sun, 02 Jan 2022 15:09:15 +0100
User-agent: Evolution 3.42.1

Hi Mark,

Am Sonntag, dem 02.01.2022 um 07:25 -0500 schrieb Mark H Weaver:
> 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.
We can agree on an absence of knowledge, but an absence of knowledge is
not an absence of assumption, which is why I'm making a stronger
statement than what you agree with.

> 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.
It's not quite as harsh, since either way we are making predictions
about uncertain events in the future.  We could for instance make a bet
on a given package, whether a given tag will be moved/dropped within
1/2/5/10 years and whoever wins gets the commit in which we updated the
package description as NFT, bragging rights, or something similarly
trivial.  There is no such thing as absolute truth to either statement
(the tag changes/does not change), there is only an observation whether
one or the other holds in past tense at a given point in time.

> 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".
Whether or not LST changes obviously depends on BODY here, but this
form is ill-suited to draw comparison.  C++ const (correctness) would
be closer to what we're discussing, as would be the following Scheme
code inside a module:

  (define LST '(1 2 3))
  (define (F) (peek LST))

Let's assume that some outsider redefines LST to '(4 5 6).  What would
be the value printed and returned by F?  This depends on whether the
compiler was optimistic and inlined LST or pessimistic and did not
inline it.  In either case, the compiler makes an assumption about
whether LST *does change* and it can be wrong.

> 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.
"Tags in Git can change" is not an assumption that one person can make
and another dispute.  It is a fact/rule/whatever given by Git, that
they can.  In a similar manner, it is a fact, that servers can move to
different locations in both geographical and virtual address spaces and
can over time serve different content.

The question is what policies we derive from said facts, which is a
typical is/ought dilemma.  Since at this point we are far removed from
facts that we can state with certainty, we have to instead rely on
assumptions, whether they come from experience, gut feelings or an old
lady with a crystal ball down the street.  

This does not mean that you assume each and every tag out in the wild
changes every few commits to the Guix repository.  But it does mean
that you find it likely and/or troublesome enough to warrant a policy,
which in turn is based either on the assumption that it is likelier to
change than not or some ad-hoc justification to bet against the odds as
well as a rough assumption on said odds.  It's like asking someone to
estimate whether the glass is full or empty, but with the added bonus
that we don't even know how much water it contains.

Now I am very open about my assumption that tags won't break for a
large number of packages.  I can also understand if you make a
different assumption for one package out there and thereby justify
using git-version, and there's even an argument to be made that all
git-based ought to use it by generalizing that assumption.  But you
cannot assume both to hold at the same time without being inconsistent
and there's nothing meaningful to derive from not knowing because
you'll make a guess either way.

Cheers



reply via email to

[Prev in Thread] Current Thread [Next in Thread]