Using #true and #false everywhere?

Using #true and #false everywhere?

[Ludovic Courtès]

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’.

Re: Using #true and #false everywhere?

[Maxim Cournoyer]

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

Re: Using #true and #false everywhere?

[Tobias Geerinckx-Rice]

[-- 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 --]

Re: Using #true and #false everywhere?

[Vagrant Cascadian]

[-- 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 --]

Re: Using #true and #false everywhere?

[Miguel Ángel Arruga Vivas]

[-- 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 --]

Re: Using #true and #false everywhere?

[Danny Milosavljevic]

[-- 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 --]

Re: Using #true and #false everywhere?

[jbranso]

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

Re: Using #true and #false everywhere?

[Maxim Cournoyer]

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

Re: Using #true and #false everywhere?

[Bengt Richter]

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

Re: Using #true and #false everywhere?

[zimoun]

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

Re: Using #true and #false everywhere?

[Andreas Enge]

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

Re: Using #true and #false everywhere?

[Andreas Enge]

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

Re: Using #true and #false everywhere?

[Ricardo Wurmus]

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

Re: Using #true and #false everywhere?

[zimoun]

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

Re: Using #true and #false everywhere?

[zimoun]

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.)

Re: Using #true and #false everywhere?

[Andreas Enge]

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

Re: Using #true and #false everywhere?

[Tobias Geerinckx-Rice]

[-- 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 --]

Re: Using #true and #false everywhere?

[zimoun]

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

Re: Using #true and #false everywhere?

[Tobias Geerinckx-Rice]

[-- 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 --]

Re: Using #true and #false everywhere?

[zimoun]

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. :-)

Re: Using #true and #false everywhere?

[Taylan Kammer]

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

Re: Using #true and #false everywhere?

[Mark H Weaver]

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

Re: Using #true and #false everywhere?

[Ricardo Wurmus]

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

Re: Using #true and #false everywhere?

[Ludovic Courtès]

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’.

Re: Using #true and #false everywhere?

[Ludovic Courtès]

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’.

Re: Using #true and #false everywhere?

[Ludovic Courtès]

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’.

Re: Using #true and #false everywhere?

[Ludovic Courtès]

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’.

Re: Using #true and #false everywhere?

[Andreas Enge]

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

Re: Using #true and #false everywhere?

[Roel Janssen]

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

Re: Using #true and #false everywhere?

[Ludovic Courtès]

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’.

Re: Using #true and #false everywhere?

[Robin Templeton]

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.