unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / Atom feed
* Using #true and #false everywhere?
@ 2020-10-16 10:38 Ludovic Courtès
  2020-10-16 13:19 ` Maxim Cournoyer
                   ` (4 more replies)
  0 siblings, 5 replies; 31+ messages in thread
From: Ludovic Courtès @ 2020-10-16 10:38 UTC (permalink / raw)
  To: guix-devel

Hello Guix!

As discussed on IRC recently, several of us think that using “#true” and
“#false” instead of “#t” and “#f” throughout or documentation and code
would probably make it easier for newcomers to decipher that.

WDYT?

This syntax is supported since Guile 2.0.  ‘write’ still uses the
abbreviations, but the good thing is that it means we can change all of
gnu/packages without triggering a single rebuild.

As for the manual, I’m afraid it’ll make every msgid that contains
@code{#t} stale.  So maybe now’s not a good time to make this change?

Thoughts?

Ludo’.


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-16 10:38 Using #true and #false everywhere? Ludovic Courtès
@ 2020-10-16 13:19 ` Maxim Cournoyer
  2020-10-16 13:36   ` Tobias Geerinckx-Rice
  2020-10-16 16:24 ` Vagrant Cascadian
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 31+ messages in thread
From: Maxim Cournoyer @ 2020-10-16 13:19 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

Hello Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello Guix!
>
> As discussed on IRC recently, several of us think that using “#true” and
> “#false” instead of “#t” and “#f” throughout or documentation and code
> would probably make it easier for newcomers to decipher that.
>
> WDYT?
>
> This syntax is supported since Guile 2.0.  ‘write’ still uses the
> abbreviations, but the good thing is that it means we can change all of
> gnu/packages without triggering a single rebuild.
>
> As for the manual, I’m afraid it’ll make every msgid that contains
> @code{#t} stale.  So maybe now’s not a good time to make this change?
>
> Thoughts?

What's the current status of #true/#false in the current Scheme
revision?  It doesn't seem to have been standardized yet, no?

I'd only agree to such a change if it's already been standardized in the
RnRS as such; #f and #t have a long history and I don't think they are
cognitively much harder to grasp than #false and #true, so the gain
seems small compared to the downsides (hurting git blame's effectiveness
across the code base, having to re-teach all contributors to use #true
and #false everywhere, augmenting the lint tools, etc.).

Maxim


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-16 13:19 ` Maxim Cournoyer
@ 2020-10-16 13:36   ` Tobias Geerinckx-Rice
  2020-10-18  1:36     ` Maxim Cournoyer
  2020-10-20  9:57     ` Andreas Enge
  0 siblings, 2 replies; 31+ messages in thread
From: Tobias Geerinckx-Rice @ 2020-10-16 13:36 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: Ludovic Courtès, guix-devel

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

Maxim,

Maxim Cournoyer 写道:
> I'd only agree to such a change if it's already been 
> standardized in the
> RnRS as such

Sure, I think that's implied.  #true and #false are part of the 
R7RS-small standard.

I don't know what Guile ‘is’, but it supports that part of the 
standard.  I don't think it implements any of the RnRS completely? 
I've heard it said that Guile targets R5RS, but that was ages ago.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-16 10:38 Using #true and #false everywhere? Ludovic Courtès
  2020-10-16 13:19 ` Maxim Cournoyer
@ 2020-10-16 16:24 ` Vagrant Cascadian
  2020-10-16 23:45 ` Danny Milosavljevic
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 31+ messages in thread
From: Vagrant Cascadian @ 2020-10-16 16:24 UTC (permalink / raw)
  To: Ludovic Courtès, guix-devel

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On 2020-10-16, Ludovic Courtès wrote:
> As discussed on IRC recently, several of us think that using “#true” and
> “#false” instead of “#t” and “#f” throughout or documentation and code
> would probably make it easier for newcomers to decipher that.
>
> WDYT?

I would very much welcome this as someone relatively new to guile and
scheme. Making it explicit with "plain" words is always preferable to
having to guess or look things up.

I've since learned that particular #t/#f convention, and it wouldn't
probably make a huge difference for me now personally, but I think it
would make the learning curve to contributing Guix a little gentler for
newcomers in general, and every bit helps. :)


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-16 10:38 Using #true and #false everywhere? Ludovic Courtès
  2020-10-16 13:19 ` Maxim Cournoyer
  2020-10-16 16:24 ` Vagrant Cascadian
@ 2020-10-16 23:45 ` Danny Milosavljevic
  2020-10-20 10:32 ` Andreas Enge
  2020-10-24 18:29 ` Robin Templeton
  4 siblings, 0 replies; 31+ messages in thread
From: Danny Milosavljevic @ 2020-10-16 23:45 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

Hi Ludo,

On Fri, 16 Oct 2020 12:38:23 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> As for the manual, I’m afraid it’ll make every msgid that contains
> @code{#t} stale.  So maybe now’s not a good time to make this change?

Now's definitely not a good time to make this change.

I think it's a good idea to make the change eventually, but I wouldn't change
it so short before a release.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-16 13:36   ` Tobias Geerinckx-Rice
@ 2020-10-18  1:36     ` Maxim Cournoyer
  2020-10-18  2:22       ` Bengt Richter
  2020-10-19 20:45       ` zimoun
  2020-10-20  9:57     ` Andreas Enge
  1 sibling, 2 replies; 31+ messages in thread
From: Maxim Cournoyer @ 2020-10-18  1:36 UTC (permalink / raw)
  To: Tobias Geerinckx-Rice; +Cc: guix-devel

Hello Tobias,

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Maxim,
>
> Maxim Cournoyer 写道:
>> I'd only agree to such a change if it's already been standardized in
>> the
>> RnRS as such
>
> Sure, I think that's implied.  #true and #false are part of the
> R7RS-small standard.

Thanks, I couldn't find where that was defined.  Now that you've pointed
it to me, it's defined in section 6.3 Booleans:

   The standard boolean objects for true and false are written as #t and
   #f. Alternatively, they can be written #true and #false,
   respectively.

> I don't know what Guile ‘is’, but it supports that part of the
> standard.  I don't think it implements any of the RnRS completely? 
> I've heard it said that Guile targets R5RS, but that was ages ago.

info '(guile) Guile and Scheme' suggests it supports all of the R5RS,
R6RS or R7RS standards, plus a bunch of srfi modules.

With this cleared, I don't have an objection to the proposal, other than
the other points I've mentioned earlier (to recall those points: I don't
perceive much value in it and it'll make the 'git blame' output noisy).

Thanks,

Maxim


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-18  1:36     ` Maxim Cournoyer
@ 2020-10-18  2:22       ` Bengt Richter
  2020-10-19 20:45       ` zimoun
  1 sibling, 0 replies; 31+ messages in thread
From: Bengt Richter @ 2020-10-18  2:22 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: guix-devel

Hi,

On +2020-10-17 21:36:06 -0400, Maxim Cournoyer wrote:
> Hello Tobias,
> 
> Tobias Geerinckx-Rice <me@tobias.gr> writes:
> 
> > Maxim,
> >
> > Maxim Cournoyer 写道:
> >> I'd only agree to such a change if it's already been standardized in
> >> the
> >> RnRS as such
> >
> > Sure, I think that's implied.  #true and #false are part of the
> > R7RS-small standard.
> 
> Thanks, I couldn't find where that was defined.  Now that you've pointed
> it to me, it's defined in section 6.3 Booleans:
> 
>    The standard boolean objects for true and false are written as #t and
>    #f. Alternatively, they can be written #true and #false,
>    respectively.
> 
> > I don't know what Guile ‘is’, but it supports that part of the
> > standard.  I don't think it implements any of the RnRS completely? 
> > I've heard it said that Guile targets R5RS, but that was ages ago.
> 
> info '(guile) Guile and Scheme' suggests it supports all of the R5RS,
> R6RS or R7RS standards, plus a bunch of srfi modules.
> 
> With this cleared, I don't have an objection to the proposal, other than
> the other points I've mentioned earlier (to recall those points: I don't
> perceive much value in it and it'll make the 'git blame' output noisy).
> 
> Thanks,
> 
> Maxim
> 

I am against editing legacy code to s/#t/#true/ and s/#f/#false/

For those who need it, why not an emacs mode to view whatever beautification they like?

Or a separate canonicalizer/prettyprinter filter that you could invoke by command line
or from any editor that can pipe thhrough filters?

ISTM any any editing of signed-off sources creates quality/security-control work for
developers who are too valuable to waste their time on non-fun.

Delegating such simple changes to newbie contributors doesn't avoid the oversight work
and potential security risk: a "whoops, that better be reverted" may open a door just
long enough for some exploitation -- or at least require the conscientious to think about
whether the whoops really could have been exploitable somehow.

I see a waste of developer time, that can be much better used.
My 2¢ :)

-- 
Regards,
Bengt Richter


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-18  1:36     ` Maxim Cournoyer
  2020-10-18  2:22       ` Bengt Richter
@ 2020-10-19 20:45       ` zimoun
  2020-10-21  9:56         ` Ludovic Courtès
  1 sibling, 1 reply; 31+ messages in thread
From: zimoun @ 2020-10-19 20:45 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: Guix Devel

Dear,

On Sun, 18 Oct 2020 at 03:36, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
> Tobias Geerinckx-Rice <me@tobias.gr> writes:
> > Maxim Cournoyer 写道:

> >> I'd only agree to such a change if it's already been standardized in
> >> the
> >> RnRS as such
> >
> > Sure, I think that's implied.  #true and #false are part of the
> > R7RS-small standard.
>
> Thanks, I couldn't find where that was defined.  Now that you've pointed
> it to me, it's defined in section 6.3 Booleans:
>
>    The standard boolean objects for true and false are written as #t and
>    #f. Alternatively, they can be written #true and #false,
>    respectively.
>
> > I don't know what Guile ‘is’, but it supports that part of the
> > standard.  I don't think it implements any of the RnRS completely?
> > I've heard it said that Guile targets R5RS, but that was ages ago.
>
> info '(guile) Guile and Scheme' suggests it supports all of the R5RS,
> R6RS or R7RS standards, plus a bunch of srfi modules.
>
> With this cleared, I don't have an objection to the proposal, other than
> the other points I've mentioned earlier (to recall those points: I don't
> perceive much value in it and it'll make the 'git blame' output noisy).

I do not have a strong opinion but I am still perplex if it really
simplifies because all the material around about Scheme and especially
the Guile manual still uses #t/#f and not #true/#false.  For example,

--8<---------------cut here---------------start------------->8---
$ guix repl
GNU Guile 3.0.4
Copyright (C) 1995-2020 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,use(gnu packages base)
scheme@(guix-user)> (eq? hello coreutils)
$1 = #f
--8<---------------cut here---------------end--------------->8---

Is it possible to display #false instead?  If not, I am not convinced
it is really easier to read #true/#false in the Guix code, then #t/#f
in the REPL or Guile documentation.

My bikeshedding time is over. :-)

All the best,
simon


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-16 13:36   ` Tobias Geerinckx-Rice
  2020-10-18  1:36     ` Maxim Cournoyer
@ 2020-10-20  9:57     ` Andreas Enge
  2020-10-21  9:59       ` Ludovic Courtès
  1 sibling, 1 reply; 31+ messages in thread
From: Andreas Enge @ 2020-10-20  9:57 UTC (permalink / raw)
  To: Tobias Geerinckx-Rice; +Cc: guix-devel

Hello,

on the bikeshedding front: I find #true and #false confusing, since
everything I see on the Scheme language seems to use #t and #f. My first
impression was that #true and #false were guilisms...

On Fri, Oct 16, 2020 at 03:36:06PM +0200, Tobias Geerinckx-Rice wrote:
> Maxim Cournoyer 写道:
> > I'd only agree to such a change if it's already been standardized in the
> > RnRS as such
> Sure, I think that's implied.  #true and #false are part of the R7RS-small
> standard.

...but since this does not seem to be the case, I can live with either.

Try this for the fun of it:
$ guile
scheme@(guile-user)> (eq? #t #true)
$1 = #t

So this would be another argument to stay with #t.

Andreas



^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-16 10:38 Using #true and #false everywhere? Ludovic Courtès
                   ` (2 preceding siblings ...)
  2020-10-16 23:45 ` Danny Milosavljevic
@ 2020-10-20 10:32 ` Andreas Enge
  2020-10-20 11:10   ` Ricardo Wurmus
                     ` (2 more replies)
  2020-10-24 18:29 ` Robin Templeton
  4 siblings, 3 replies; 31+ messages in thread
From: Andreas Enge @ 2020-10-20 10:32 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

And since we are on the bikeshedding front, I feel like writing a second
message.

On Fri, Oct 16, 2020 at 12:38:23PM +0200, Ludovic Courtès wrote:
> As discussed on IRC recently, several of us think that using “#true” and
> “#false” instead of “#t” and “#f” throughout or documentation and code
> would probably make it easier for newcomers to decipher that.

Honestly, I think either of them is sufficiently easy to understand, in the
presence of much more difficult questions:
- The "non-typedness of booleans": Does "(if 1 2 3)" raise an exception or
  work, and if the latter is true, what is the result? And if I replace
  "1" by "0" or the empty list? (In Guix, this is related to the question:
  Do I need to add #t or #f at the end of a phase, or is the value of its
  last statement sufficient?)
- What are the different procedures for comparing things?
- What are quotes, quasiquotes, unquotes? How do they relate to code staging
  in Guix? (This is to me the most difficult part of Guix code, in particular
  for someone coming from a language where code is code and data are data.)
- Actually, why are there two ways to define literal lists? Do they have
  the same result? This is a mixture of the previous two questions; try
     (eq? '(1) '(1))
  vs.
     (eq? '(1) (list 1))
  or
     (eq? (list 1) (list 1))
  Then try again with eqv? and equal?.
  Then try again with "(eq? '() (list))" and so on. (This one still
  surprises me.)
  Does it matter? (Probably not much in the context of Guix.)
- If I want to know what are and what happens in the phases of
  the perl build system, do I look in build/perl-build-system.scm or
  build-system/perl.scm? Why is there no build-system/perl-build-system.scm
  or build/perl.scm instead? (Just a little trolling at the end of my post,
  no real harm intended ;-) But I am honestly unable to remember the answer,
  and look at the two files every time I wonder about a build system, which
  is of course entirely feasible, some might even argue instructional.)

Andreas



^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-20 10:32 ` Andreas Enge
@ 2020-10-20 11:10   ` Ricardo Wurmus
  2020-10-20 12:02     ` zimoun
  2020-10-21  1:25     ` Mark H Weaver
  2020-10-20 12:45   ` zimoun
  2020-10-21 10:20   ` Ludovic Courtès
  2 siblings, 2 replies; 31+ messages in thread
From: Ricardo Wurmus @ 2020-10-20 11:10 UTC (permalink / raw)
  To: Andreas Enge; +Cc: guix-devel


Andreas Enge <andreas@enge.fr> writes:

> And since we are on the bikeshedding front, I feel like writing a second
> message.
>
> On Fri, Oct 16, 2020 at 12:38:23PM +0200, Ludovic Courtès wrote:
>> As discussed on IRC recently, several of us think that using “#true” and
>> “#false” instead of “#t” and “#f” throughout or documentation and code
>> would probably make it easier for newcomers to decipher that.
>
> Honestly, I think either of them is sufficiently easy to understand, in the
> presence of much more difficult questions:
> - The "non-typedness of booleans": Does "(if 1 2 3)" raise an exception or
>   work, and if the latter is true, what is the result? And if I replace
>   "1" by "0" or the empty list? (In Guix, this is related to the question:
>   Do I need to add #t or #f at the end of a phase, or is the value of its
>   last statement sufficient?)

I think it’s very ugly that we still need to end phases with #T, even
though build systems don’t care any more.  The only thing that aborts a
build phase now is an exception.  In the next core-updates cycle we
should probably remove the warning about ending build phases with
anything other than #T and then remove all spurious #Ts from existing
package definitions.

> - What are quotes, quasiquotes, unquotes? How do they relate to code staging
>   in Guix? (This is to me the most difficult part of Guix code, in particular
>   for someone coming from a language where code is code and data are
>   data.)

It’s tricky.  I found the toggle switch imagery (taken from “The Land of
Lisp”) to be a very useful teaching aid, but it isn’t necessarily
obvious to newcomers *why* we would want to quote code anyway.

> - Actually, why are there two ways to define literal lists? Do they have
>   the same result? This is a mixture of the previous two questions; try
>      (eq? '(1) '(1))
>   vs.
>      (eq? '(1) (list 1))
>   or
>      (eq? (list 1) (list 1))
>   Then try again with eqv? and equal?.
>   Then try again with "(eq? '() (list))" and so on. (This one still
>   surprises me.)
>   Does it matter? (Probably not much in the context of Guix.)

Comparison with EQ? is rarely useful in the context of Guix, because we
usually don’t care about identity (“is the value behind this variable
name and the value behind this other variable name one and the same,
i.e. are the variables just aliases of an identical value?”)  but about
equivalence (“does evaluating this expression lead to the same result as
evaluating this other expression?”).

The difference between a quoted list literal and an expression using
LIST is that the former is immutable whereas the latter is mutable.  The
resulting value is equivalent, but the values themselves are not
identical.

> - If I want to know what are and what happens in the phases of
>   the perl build system, do I look in build/perl-build-system.scm or
>   build-system/perl.scm? Why is there no build-system/perl-build-system.scm
>   or build/perl.scm instead? (Just a little trolling at the end of my post,
>   no real harm intended ;-) But I am honestly unable to remember the answer,
>   and look at the two files every time I wonder about a build system, which
>   is of course entirely feasible, some might even argue
>   instructional.)

Hah, I also always look at both files!  But the simple answer is that
everything in guix/build/* is build-side code, not host code.

-- 
Ricardo


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-20 11:10   ` Ricardo Wurmus
@ 2020-10-20 12:02     ` zimoun
  2020-10-20 12:59       ` Tobias Geerinckx-Rice
  2020-10-21  1:25     ` Mark H Weaver
  1 sibling, 1 reply; 31+ messages in thread
From: zimoun @ 2020-10-20 12:02 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: Guix Devel

Hi Ricardo,

On Tue, 20 Oct 2020 at 13:12, Ricardo Wurmus <rekado@elephly.net> wrote:

> Comparison with EQ? is rarely useful in the context of Guix, because we
> usually don’t care about identity (“is the value behind this variable
> name and the value behind this other variable name one and the same,
> i.e. are the variables just aliases of an identical value?”)  but about
> equivalence (“does evaluating this expression lead to the same result as
> evaluating this other expression?”).

If you do not buy the 'eq?', maybe this one is more relevant:

--8<---------------cut here---------------start------------->8---
$ guix repl
GNU Guile 3.0.4
Copyright (C) 1995-2020 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,use(guix packages)
scheme@(guix-user)> ,use(gnu packages base)
scheme@(guix-user)> (package? hello)
$1 = #t
--8<---------------cut here---------------end--------------->8---

So 'define-syntax define-record-type*' needs to be fixed to return
#true...  Well, to keep consistency it is not a small change and maybe
now is not a good timing.

All the best,
simon


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-20 10:32 ` Andreas Enge
  2020-10-20 11:10   ` Ricardo Wurmus
@ 2020-10-20 12:45   ` zimoun
  2020-10-20 12:55     ` Andreas Enge
  2020-10-21 10:20   ` Ludovic Courtès
  2 siblings, 1 reply; 31+ messages in thread
From: zimoun @ 2020-10-20 12:45 UTC (permalink / raw)
  To: Andreas Enge; +Cc: guix-devel

Hi Andreas,

On Tue, 20 Oct 2020 at 12:33, Andreas Enge <andreas@enge.fr> wrote:

> And since we are on the bikeshedding front, I feel like writing a second
> message.

You are playing the devil's lawyer role, right?


> On Fri, Oct 16, 2020 at 12:38:23PM +0200, Ludovic Courtès wrote:

> - The "non-typedness of booleans": Does "(if 1 2 3)" raise an exception or
>   work, and if the latter is true, what is the result? And if I replace
>   "1" by "0" or the empty list? (In Guix, this is related to the question:

This is a question about the standard, right?  It is not about #true
or #false vs #t or #f.

>   Do I need to add #t or #f at the end of a phase, or is the value of its
>   last statement sufficient?)

The question is how to know the value of the last statement.  And it
is Scheme/Guile question, right?  Not really about the #true vs #t,
isn't it?


> - What are the different procedures for comparing things?

The Guile manual explains well, isn't it?

<https://www.gnu.org/software/guile/manual/html_node/Equality.html>


Cheers,
simon

ps:
Well, one example showing all the points is, IMHO:

--8<---------------cut here---------------start------------->8---
scheme@(guix-user)> (define (f x) (when (> x 2) #true))
scheme@(guix-user)> (map f '(1 2 3 4))
$1 = (#<unspecified> #<unspecified> #t #t)
--8<---------------cut here---------------end--------------->8---

(whatever the comparison (> x 2) is; could be package related.)


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-20 12:45   ` zimoun
@ 2020-10-20 12:55     ` Andreas Enge
  0 siblings, 0 replies; 31+ messages in thread
From: Andreas Enge @ 2020-10-20 12:55 UTC (permalink / raw)
  To: zimoun; +Cc: guix-devel

Hello,

On Tue, Oct 20, 2020 at 02:45:54PM +0200, zimoun wrote:
> You are playing the devil's lawyer role, right?
> This is a question about the standard, right?  It is not about #true
> or #false vs #t or #f.
> The Guile manual explains well, isn't it?

yes, indeed. What I want to say: Besides other problems that newcomers of
different backgrounds might have when learning Scheme and/or Guile and/or
Guix, having to learn that "#f" means "false" is in my opinion one of the
least; whereas my other examples provide what I think are real difficulties
(some of which simply need a bit of studying of documentation).

Andreas



^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-20 12:02     ` zimoun
@ 2020-10-20 12:59       ` Tobias Geerinckx-Rice
  2020-10-20 13:11         ` zimoun
  0 siblings, 1 reply; 31+ messages in thread
From: Tobias Geerinckx-Rice @ 2020-10-20 12:59 UTC (permalink / raw)
  To: zimoun; +Cc: Ricardo Wurmus, guix-devel

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

zimoun 写道:
> So 'define-syntax define-record-type*' needs to be fixed to 
> return
> #true...

Not sure if this is a misunderstanding on my part or yours, but:

~ λ guile
scheme@(guile-user)> (define (return-#true) #true)
scheme@(guile-user)> (return-#true)
$3 = #t

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-20 12:59       ` Tobias Geerinckx-Rice
@ 2020-10-20 13:11         ` zimoun
  2020-10-20 13:32           ` Tobias Geerinckx-Rice
  0 siblings, 1 reply; 31+ messages in thread
From: zimoun @ 2020-10-20 13:11 UTC (permalink / raw)
  To: Tobias Geerinckx-Rice; +Cc: Guix Devel

On Tue, 20 Oct 2020 at 14:59, Tobias Geerinckx-Rice <me@tobias.gr> wrote:
> zimoun 写道:

> > So 'define-syntax define-record-type*' needs to be fixed to
> > return
> > #true...
>
> Not sure if this is a misunderstanding on my part or yours, but:
>
> ~ λ guile
> scheme@(guile-user)> (define (return-#true) #true)
> scheme@(guile-user)> (return-#true)
> $3 = #t

Maybe it is on my part but it returns #t and not #true.  So somehow
you need to know that #t is also #true or fix the REPL to return #true
and not #t.  Is that true? ;-)

Cheers,
simon


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-20 13:11         ` zimoun
@ 2020-10-20 13:32           ` Tobias Geerinckx-Rice
  2020-10-20 14:26             ` zimoun
  0 siblings, 1 reply; 31+ messages in thread
From: Tobias Geerinckx-Rice @ 2020-10-20 13:32 UTC (permalink / raw)
  To: zimoun; +Cc: Ricardo Wurmus, Guix Devel

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

zimoun 写道:
> Maybe it is on my part but it returns #t and not #true.  So 
> somehow
> you need to know that #t is also #true or fix the REPL to return 
> #true
> and not #t.

Right.  Making e.g. define-record-type ‘return #true’ would not 
change what's actually returned under the hood.

(Thank goodness!  That would be fun :-)

> Is that true? ;-)

#fu.

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-20 13:32           ` Tobias Geerinckx-Rice
@ 2020-10-20 14:26             ` zimoun
  2020-10-20 15:48               ` Taylan Kammer
  0 siblings, 1 reply; 31+ messages in thread
From: zimoun @ 2020-10-20 14:26 UTC (permalink / raw)
  To: Tobias Geerinckx-Rice; +Cc: Guix Devel

On Tue, 20 Oct 2020 at 15:32, Tobias Geerinckx-Rice <me@tobias.gr> wrote:
> zimoun 写道:
> > Maybe it is on my part but it returns #t and not #true.  So
> > somehow
> > you need to know that #t is also #true or fix the REPL to return
> > #true
> > and not #t.
>
> Right.  Making e.g. define-record-type ‘return #true’ would not
> change what's actually returned under the hood.

It is what I have tried to express [1]:  I am not convinced that
replacing in the Guix source by #true or #false instead of #t or #f
really simplifies and helps the newcomer.  Because all the internals
use #t or #f.  For example, there are often #t or #f in Backtrace
messages (random example [2]).  REPL is another example.  Somehow, you
have to know what #t and #f means, even if you are a newcomer.

The only remaining argument IMHO in favor of the change is cosmetic
(not newcomer friendly): it is more pleasant to read #false here and
there in the source code.  Well, I do not have a strong opinion,  I am
still doubtful.


> (Thank goodness!  That would be fun :-)

Maybe, but it is not a simple change, from what I understand. :-)

All the best,
simon

1: <https://lists.gnu.org/archive/html/guix-devel/2020-10/msg00307.html>
2: <http://issues.guix.gnu.org/43518>

ps:
my last bikeshed message on this topic. :-)


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-20 14:26             ` zimoun
@ 2020-10-20 15:48               ` Taylan Kammer
  0 siblings, 0 replies; 31+ messages in thread
From: Taylan Kammer @ 2020-10-20 15:48 UTC (permalink / raw)
  To: zimoun, Tobias Geerinckx-Rice; +Cc: Guix Devel

On 20.10.2020 16:26, zimoun wrote:
> On Tue, 20 Oct 2020 at 15:32, Tobias Geerinckx-Rice <me@tobias.gr> wrote:
>> zimoun 写道:
>>> Maybe it is on my part but it returns #t and not #true.  So
>>> somehow
>>> you need to know that #t is also #true or fix the REPL to return
>>> #true
>>> and not #t.
>>
>> Right.  Making e.g. define-record-type ‘return #true’ would not
>> change what's actually returned under the hood.
> 
> It is what I have tried to express [1]:  I am not convinced that
> replacing in the Guix source by #true or #false instead of #t or #f
> really simplifies and helps the newcomer.  Because all the internals
> use #t or #f.  For example, there are often #t or #f in Backtrace
> messages (random example [2]).  REPL is another example.  Somehow, you
> have to know what #t and #f means, even if you are a newcomer.
> 
> The only remaining argument IMHO in favor of the change is cosmetic
> (not newcomer friendly): it is more pleasant to read #false here and
> there in the source code.  Well, I do not have a strong opinion,  I am
> still doubtful.

Shouldn't it suffice to just change 'write'?  I think that should change 
99.9% of all places where Guile outputs "#f" or "#t" for false/true.

- Taylan


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-20 11:10   ` Ricardo Wurmus
  2020-10-20 12:02     ` zimoun
@ 2020-10-21  1:25     ` Mark H Weaver
  2020-10-21  6:18       ` Ricardo Wurmus
  1 sibling, 1 reply; 31+ messages in thread
From: Mark H Weaver @ 2020-10-21  1:25 UTC (permalink / raw)
  To: Ricardo Wurmus, Andreas Enge; +Cc: guix-devel

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

> I think it’s very ugly that we still need to end phases with #T, even
> though build systems don’t care any more.  The only thing that aborts a
> build phase now is an exception.

I would be glad if this were the case, but I believe you're mistaken.
On both master and core-updates, in (guix build gnu-build-system), the
'gnu-build' procedure iterates over the phases using 'every', and
procedure passed to 'every' ends by returning 'result', which is the
value that the phase returned.  Am I missing something?

     Regards,
       Mark


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-21  1:25     ` Mark H Weaver
@ 2020-10-21  6:18       ` Ricardo Wurmus
  2020-10-21 10:04         ` Ludovic Courtès
  0 siblings, 1 reply; 31+ messages in thread
From: Ricardo Wurmus @ 2020-10-21  6:18 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel

Hi Mark,

Mark H Weaver <mhw@netris.org> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> I think it’s very ugly that we still need to end phases with #T, even
>> though build systems don’t care any more.  The only thing that aborts a
>> build phase now is an exception.
>
> I would be glad if this were the case, but I believe you're mistaken.
> On both master and core-updates, in (guix build gnu-build-system), the
> 'gnu-build' procedure iterates over the phases using 'every', and
> procedure passed to 'every' ends by returning 'result', which is the
> value that the phase returned.  Am I missing something?

No, you are correct.  My meaning was more about intent; in the early
days of the change to INVOKE I’ve seen a couple of warnings telling me
that a phase returned #<unspecified> or #F, but that didn’t result in
aborting the build.  We have decided a long time ago that the only way
to exit a build should be through an exception, so I think it’s time to
update the last few build system remnants of the Boolean assumption (on
core-updates).

-- 
Ricardo


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-19 20:45       ` zimoun
@ 2020-10-21  9:56         ` Ludovic Courtès
  0 siblings, 0 replies; 31+ messages in thread
From: Ludovic Courtès @ 2020-10-21  9:56 UTC (permalink / raw)
  To: zimoun; +Cc: Guix Devel, Maxim Cournoyer

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> I do not have a strong opinion but I am still perplex if it really
> simplifies because all the material around about Scheme and especially
> the Guile manual still uses #t/#f and not #true/#false.  For example,
>
> $ guix repl
> GNU Guile 3.0.4
> Copyright (C) 1995-2020 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guix-user)> ,use(gnu packages base)
> scheme@(guix-user)> (eq? hello coreutils)
> $1 = #f
>
> Is it possible to display #false instead?  If not, I am not convinced
> it is really easier to read #true/#false in the Guix code, then #t/#f
> in the REPL or Guile documentation.

Currently it’s not possible to tell ‘write’ to write #true/#false.  It
would be nice to have a way to enable this, optionally.

Ludo’.


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-20  9:57     ` Andreas Enge
@ 2020-10-21  9:59       ` Ludovic Courtès
  2020-10-21 11:21         ` Andreas Enge
  2020-10-21 11:51         ` Roel Janssen
  0 siblings, 2 replies; 31+ messages in thread
From: Ludovic Courtès @ 2020-10-21  9:59 UTC (permalink / raw)
  To: Andreas Enge; +Cc: guix-devel

Hi,

Andreas Enge <andreas@enge.fr> skribis:

> on the bikeshedding front: I find #true and #false confusing, since
> everything I see on the Scheme language seems to use #t and #f.

What material are you referring to?  SICP & co.?

Unfortunately, “the” Scheme language is more of a concept; SICP targets
R5RS I think, which happens to work with most “Scheme implementations”,
but not necessarily by default (what if you use “#lang racket” for
instance?).

Ludo’.


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-21  6:18       ` Ricardo Wurmus
@ 2020-10-21 10:04         ` Ludovic Courtès
  0 siblings, 0 replies; 31+ messages in thread
From: Ludovic Courtès @ 2020-10-21 10:04 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> Mark H Weaver <mhw@netris.org> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> I think it’s very ugly that we still need to end phases with #T, even
>>> though build systems don’t care any more.  The only thing that aborts a
>>> build phase now is an exception.
>>
>> I would be glad if this were the case, but I believe you're mistaken.
>> On both master and core-updates, in (guix build gnu-build-system), the
>> 'gnu-build' procedure iterates over the phases using 'every', and
>> procedure passed to 'every' ends by returning 'result', which is the
>> value that the phase returned.  Am I missing something?
>
> No, you are correct.  My meaning was more about intent; in the early
> days of the change to INVOKE I’ve seen a couple of warnings telling me
> that a phase returned #<unspecified> or #F, but that didn’t result in
> aborting the build.  We have decided a long time ago that the only way
> to exit a build should be through an exception, so I think it’s time to
> update the last few build system remnants of the Boolean assumption (on
> core-updates).

I agree.  That means replacing ‘every’ with ‘for-each’.

Ludo’.


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-20 10:32 ` Andreas Enge
  2020-10-20 11:10   ` Ricardo Wurmus
  2020-10-20 12:45   ` zimoun
@ 2020-10-21 10:20   ` Ludovic Courtès
  2 siblings, 0 replies; 31+ messages in thread
From: Ludovic Courtès @ 2020-10-21 10:20 UTC (permalink / raw)
  To: Andreas Enge; +Cc: guix-devel

Hi,

Andreas Enge <andreas@enge.fr> skribis:

> On Fri, Oct 16, 2020 at 12:38:23PM +0200, Ludovic Courtès wrote:
>> As discussed on IRC recently, several of us think that using “#true” and
>> “#false” instead of “#t” and “#f” throughout or documentation and code
>> would probably make it easier for newcomers to decipher that.
>
> Honestly, I think either of them is sufficiently easy to understand, in the
> presence of much more difficult questions:

Writing #true instead of #t will not make the language immediately
obvious to everyone.  You’re right about those other pitfalls.

To me it’s really about the height of the barrier to entry: I view this
change as a simple way to lower it by a bit.  I did hear comments from
newcomers who just wanted to package something and stared at those #t/#f
wondering what it could mean.  Vagrant shared a similar experience.

There’s a convention in Scheme to spell things out for clarity, even
‘call-with-current-continuation’.  I do think it helps a great deal make
code more intelligible.  #t/#f are an exception to that rule.

> - What are quotes, quasiquotes, unquotes? How do they relate to code staging
>   in Guix? (This is to me the most difficult part of Guix code, in particular
>   for someone coming from a language where code is code and data are data.)

There are examples of quote/unquote at
<https://www.gnu.org/software/guile/manual/html_node/Expression-Syntax.html>,
there’s also a discussion of code staging at
<https://guix.gnu.org/manual/devel/en/html_node/G_002dExpressions.html>,
but I gather it’s hard to grasp.

If you have suggestions on how to improve documentation on these topics,
I’m all ears!

Recently I’ve been working on the manual in the spirit of making it
easier to get started using the Scheme APIs, for packaging in
particular, and what we’re discussing here goes in the same direction.

Thanks,
Ludo’.


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-21  9:59       ` Ludovic Courtès
@ 2020-10-21 11:21         ` Andreas Enge
  2020-10-21 15:52           ` Ludovic Courtès
  2020-10-21 11:51         ` Roel Janssen
  1 sibling, 1 reply; 31+ messages in thread
From: Andreas Enge @ 2020-10-21 11:21 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

On Wed, Oct 21, 2020 at 11:59:40AM +0200, Ludovic Courtès wrote:
> What material are you referring to?  SICP & co.?

I simply used my favourite search engine with something such as
   scheme language boolean

In my case the first link is to the racket manual:
   https://docs.racket-lang.org/reference/booleans.html

Or this:
   https://courses.cs.washington.edu/courses/cse341/02sp/scheme/basics.html

Or the Wikipedia entry:
   https://en.wikipedia.org/wiki/Scheme_%28programming_language%29

Any kind of search quickly reveals that booleans in Scheme are coded
using #t and #f; whereas to find #true and #false, my impression is that
one already needs to know that these are possibilities. I find their use
more confusing than helpful.

Now if we drop the #t from phases as discussed in the present thread,
that would be even better. I have never been convinced by phases that
always return #t and never #f; what is the point of a return value
if it is not really checked?

Andreas



^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-21  9:59       ` Ludovic Courtès
  2020-10-21 11:21         ` Andreas Enge
@ 2020-10-21 11:51         ` Roel Janssen
  1 sibling, 0 replies; 31+ messages in thread
From: Roel Janssen @ 2020-10-21 11:51 UTC (permalink / raw)
  To: Ludovic Courtès, Andreas Enge; +Cc: guix-devel

On Wed, 2020-10-21 at 11:59 +0200, Ludovic Courtès wrote:
> Hi,
> 
> Andreas Enge <andreas@enge.fr> skribis:
> 
> > on the bikeshedding front: I find #true and #false confusing, since
> > everything I see on the Scheme language seems to use #t and #f.
> 
> What material are you referring to?  SICP & co.?
> 

Sorry to inject in the thread, but here's more material that uses #t
and #f:

  $ guile
  GNU Guile 3.0.4
  Copyright (C) 1995-2020 Free Software Foundation, Inc.

  Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
  This program is free software, and you are welcome to redistribute it
  under certain conditions; type `,show c' for details.

  Enter `,help' for help.
  scheme@(guile-user)> (= 1 1)
  $1 = #t
  scheme@(guile-user)> (= 1 2)
  $2 = #f

I don't remember ever being confused about #t and #f, so perhaps my
opinion doesn't matter much in this, but I'd prefer #t and #f because
it's already widespread use in Scheme.  (And with widespread I mean:
Pretty much all Scheme code I read).

I do remember being confused about the double parenthesis on "let" ;).

Kind regards,
Roel Janssen




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-21 11:21         ` Andreas Enge
@ 2020-10-21 15:52           ` Ludovic Courtès
  0 siblings, 0 replies; 31+ messages in thread
From: Ludovic Courtès @ 2020-10-21 15:52 UTC (permalink / raw)
  To: Andreas Enge; +Cc: guix-devel

Andreas Enge <andreas@enge.fr> skribis:

> On Wed, Oct 21, 2020 at 11:59:40AM +0200, Ludovic Courtès wrote:
>> What material are you referring to?  SICP & co.?
>
> I simply used my favourite search engine with something such as
>    scheme language boolean

OK.  Note that it’s a different topic though: someone going through the
Guix manual or looking at package definitions would have no reason to
search for that when they see “#true”, for example.

> In my case the first link is to the racket manual:
>    https://docs.racket-lang.org/reference/booleans.html
>
> Or this:
>    https://courses.cs.washington.edu/courses/cse341/02sp/scheme/basics.html
>
> Or the Wikipedia entry:
>    https://en.wikipedia.org/wiki/Scheme_%28programming_language%29
>
> Any kind of search quickly reveals that booleans in Scheme are coded
> using #t and #f; whereas to find #true and #false, my impression is that
> one already needs to know that these are possibilities. I find their use
> more confusing than helpful.

If we change the Guix (and Guile?) manual to use #true and #false
consistently, we can give you something different to see.

We can even do SEO so that Racket doesn’t show up early (heck, they
chose not to call it a Scheme implementation :-)).  Though it saddens me
that the programming landscape is shaped by what search engines provide…

Ludo’.


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-16 10:38 Using #true and #false everywhere? Ludovic Courtès
                   ` (3 preceding siblings ...)
  2020-10-20 10:32 ` Andreas Enge
@ 2020-10-24 18:29 ` Robin Templeton
  4 siblings, 0 replies; 31+ messages in thread
From: Robin Templeton @ 2020-10-24 18:29 UTC (permalink / raw)
  To: guix-devel

Ludovic Courtès <ludo@gnu.org> writes:

> Hello Guix!
>
> As discussed on IRC recently, several of us think that using “#true” and
> “#false” instead of “#t” and “#f” throughout or documentation and code
> would probably make it easier for newcomers to decipher that.
>
> WDYT?
>
> This syntax is supported since Guile 2.0.  ‘write’ still uses the
> abbreviations, but the good thing is that it means we can change all of
> gnu/packages without triggering a single rebuild.
>
> As for the manual, I’m afraid it’ll make every msgid that contains
> @code{#t} stale.  So maybe now’s not a good time to make this change?
>
> Thoughts?

I like the bikeshed color just as it is ;-) It's not obvious to me that
the "#t"/"#f" syntax is actually more confusing than "#true"/"#false"
for newcomers, and many users would need to learn both ways to write
boolean constants anyway. It may be *more* confusing to newcomers who
know pre-R7RS Scheme, or who refer to external documentation that uses
the shorter names, including the Guile reference manual, existing web
pages about Guix, pre-R7RS Scheme tutorials, etc.



^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
  2020-10-16 22:06 Miguel Ángel Arruga Vivas
@ 2020-10-17  0:25 ` jbranso
  0 siblings, 0 replies; 31+ messages in thread
From: jbranso @ 2020-10-17  0:25 UTC (permalink / raw)
  To: Miguel Ángel Arruga Vivas, guix-devel

I use "f" for followup.  That works for me.  :)

October 16, 2020 6:08 PM, "Miguel Ángel Arruga Vivas" <rosen644835@gmail.com> wrote:

> I didn't send this to the list... I must start using S L always instead
> of R and changing the headers manually, sorry. :o)
> 
> ---
> Hi Ludo,
> 
> Ludovic Courtès <ludo@gnu.org> writes:
> 
>> Hello Guix!
>> 
>> As discussed on IRC recently, several of us think that using “#true” and
>> “#false” instead of “#t” and “#f” throughout or documentation and code
>> would probably make it easier for newcomers to decipher that.
>> 
>> WDYT?
> 
> I think that it could help to the reader.
> 
>> This syntax is supported since Guile 2.0. ‘write’ still uses the
>> abbreviations, but the good thing is that it means we can change all of
>> gnu/packages without triggering a single rebuild.
> 
> This is even better. :)
> 
>> As for the manual, I’m afraid it’ll make every msgid that contains
>> @code{#t} stale. So maybe now’s not a good time to make this change?
> 
> It may be a big issue with a release in one week, but on the other hand
> the msgids would break just after releasing...
> 
> Maybe other translators have a say.
> 
> Happy hacking!
> Miguel


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: Using #true and #false everywhere?
@ 2020-10-16 22:06 Miguel Ángel Arruga Vivas
  2020-10-17  0:25 ` jbranso
  0 siblings, 1 reply; 31+ messages in thread
From: Miguel Ángel Arruga Vivas @ 2020-10-16 22:06 UTC (permalink / raw)
  To: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

I didn't send this to the list... I must start using S L always instead
of R and changing the headers manually, sorry.  :o)

---
Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:
> Hello Guix!
>
> As discussed on IRC recently, several of us think that using “#true” and
> “#false” instead of “#t” and “#f” throughout or documentation and code
> would probably make it easier for newcomers to decipher that.
>
> WDYT?

I think that it could help to the reader.

> This syntax is supported since Guile 2.0.  ‘write’ still uses the
> abbreviations, but the good thing is that it means we can change all of
> gnu/packages without triggering a single rebuild.

This is even better. :)

> As for the manual, I’m afraid it’ll make every msgid that contains
> @code{#t} stale.  So maybe now’s not a good time to make this change?

It may be a big issue with a release in one week, but on the other hand
the msgids would break just after releasing...

Maybe other translators have a say.

Happy hacking!
Miguel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2020-10-24 18:29 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-16 10:38 Using #true and #false everywhere? Ludovic Courtès
2020-10-16 13:19 ` Maxim Cournoyer
2020-10-16 13:36   ` Tobias Geerinckx-Rice
2020-10-18  1:36     ` Maxim Cournoyer
2020-10-18  2:22       ` Bengt Richter
2020-10-19 20:45       ` zimoun
2020-10-21  9:56         ` Ludovic Courtès
2020-10-20  9:57     ` Andreas Enge
2020-10-21  9:59       ` Ludovic Courtès
2020-10-21 11:21         ` Andreas Enge
2020-10-21 15:52           ` Ludovic Courtès
2020-10-21 11:51         ` Roel Janssen
2020-10-16 16:24 ` Vagrant Cascadian
2020-10-16 23:45 ` Danny Milosavljevic
2020-10-20 10:32 ` Andreas Enge
2020-10-20 11:10   ` Ricardo Wurmus
2020-10-20 12:02     ` zimoun
2020-10-20 12:59       ` Tobias Geerinckx-Rice
2020-10-20 13:11         ` zimoun
2020-10-20 13:32           ` Tobias Geerinckx-Rice
2020-10-20 14:26             ` zimoun
2020-10-20 15:48               ` Taylan Kammer
2020-10-21  1:25     ` Mark H Weaver
2020-10-21  6:18       ` Ricardo Wurmus
2020-10-21 10:04         ` Ludovic Courtès
2020-10-20 12:45   ` zimoun
2020-10-20 12:55     ` Andreas Enge
2020-10-21 10:20   ` Ludovic Courtès
2020-10-24 18:29 ` Robin Templeton
2020-10-16 22:06 Miguel Ángel Arruga Vivas
2020-10-17  0:25 ` jbranso

unofficial mirror of guix-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-devel/0 guix-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-devel guix-devel/ https://yhetil.org/guix-devel \
		guix-devel@gnu.org
	public-inbox-index guix-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.devel
	nntp://news.gmane.io/gmane.comp.gnu.guix.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git