cond construct for situation when a variable is t

cond construct for situation when a variable is t

[Heime]

How can I use the 'cond' construct for the case when a variable is 't' ? 
I can set a variable to boolean true using (setq var t), am I right ?

Re: cond construct for situation when a variable is t

[Emanuel Berg]

Heime wrote:

> How can I use the 'cond' construct for the case when
> a variable is 't' ?

It could look like this but in practice one would probably put
it in another way, that looks better.

(setq var nil)

(cond
  (var       1)
  ((not var) 0) )

> I can set a variable to boolean true using (setq var t), am
> I right ?

You can, you totally can. Just don't `setq' t to anything ;)

-- 
underground experts united
https://dataswamp.org/~incal

Re: cond construct for situation when a variable is t

[Rudolf Adamkovič]

Heime <heimeborgia@protonmail.com> writes:

> How can I use the 'cond' construct for the
> case when a variable is 't' ?

(cond ((equal some-variable t)
       (message "true")))

For more information, see 'C-h f cond RET'.

> I can set a variable to boolean true using
> (setq var t), am I right ?

Correct.

Rudy
-- 
"'Obvious' is all too often a synonym for 'wrong'."
-- Jeff Erickson, Algorithms, 2019

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: cond construct for situation when a variable is t

[Heime]

Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, August 23rd, 2023 at 12:10 AM, Emanuel Berg <incal@dataswamp.org> wrote:


> Heime wrote:
> 
> > How can I use the 'cond' construct for the case when
> > a variable is 't' ?
> 
> 
> It could look like this but in practice one would probably put
> it in another way, that looks better.
> 
> (setq var nil)
> 
> (cond
> (var 1)
> ((not var) 0) )

Which one looks better, the one you wrote with 0 and 1 ?

Is it not recommended to use t ?
 
> > I can set a variable to boolean true using (setq var t), am
> > I right ?
> 
> 
> You can, you totally can. Just don't `setq' t to anything ;)

Right, because one can set the letter t to something which would then
screw up the idea that t means a truth condition. 
 
> --
> underground experts united
> https://dataswamp.org/~incal

Re: cond construct for situation when a variable is t

[Heime]

Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, August 23rd, 2023 at 12:10 AM, Emanuel Berg <incal@dataswamp.org> wrote:


> Heime wrote:
> 
> > How can I use the 'cond' construct for the case when
> > a variable is 't' ?
> 
> 
> It could look like this but in practice one would probably put
> it in another way, that looks better.
> 
> (setq var nil)
> 
> (cond
> (var 1)
> ((not var) 0) )
> 
> > I can set a variable to boolean true using (setq var t), am
> > I right ?
> 
> 
> You can, you totally can. Just don't `setq' t to anything ;)
> 
> --
> underground experts united
> https://dataswamp.org/~incal

I am getting somewhat confused after your comments Emanuel.  There is no 
'boolean datatype' in elisp.  With nil and empty list () being false, 
anything else is true.  That t is used for true, is that by convention ?
Should t be used, or is it unreliable ?

RE: [External] : Re: cond construct for situation when a variable is t

[Drew Adams]

> > You can, you totally can. Just don't `setq' t to anything ;)
> 
> Right, because one can set the letter t to something which would then
> screw up the idea that t means a truth condition.

(setq t 42)

Debugger entered--Lisp error: (setting-constant t)
  signal(setting-constant (t))
  (progn (signal 'setting-constant (list 't)))
  (progn (progn (signal 'setting-constant (list 't))))
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  command-execute(eval-last-sexp)

And `t' is not a "letter" here; it's a _symbol_
whose name is "t".

RE: [External] : Re: cond construct for situation when a variable is t

[Drew Adams]

> There is no 'boolean datatype' in elisp.
> With nil and empty list () being false,
> anything else is true.

There's no real true or false in Lisp.  But yes,
that's the convention, and that convention is
baked into primitive conditionals, such as `if'
and `cond'.  So sure, you can think of it as
being more than a convention.

> That t is used for true, is that by convention ?
> Should t be used, or is it unreliable ?

Just like the "convention" described above, it's
a convention.  But also just like it, it's baked
into primitives.  So yes, the constant `t' is a
typical non-nil value used by conditionals to
represent "true".  And it's the canonical way to
represent "true", meaning that it's the clearest
way to tell human readers of code that "true" is
meant.

Re: cond construct for situation when a variable is t

[Emanuel Berg]

Heime wrote:

>>> How can I use the 'cond' construct for the case when
>>> a variable is 't' ?
>> 
>> It could look like this but in practice one would probably
>> put it in another way, that looks better.
>> 
>> (setq var nil)
>> 
>> (cond
>> (var 1)
>> ((not var) 0) )
>
> Which one looks better, the one you wrote with 0 and 1 ?

No, that was for demonstration purposes only, that what you
asked for is possible to do with `cond'.

In practice I think most people would find another solution to
express the same thing, but it is as valid so if you like it,
that is up to you.

>> You can, you totally can. Just don't `setq' t to anything :)
>
> Right, because one can set the letter t to something which
> would then screw up the idea that t means a truth condition.

And all code that relies on that idea :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: cond construct for situation when a variable is t

[Emanuel Berg]

Drew Adams wrote:

>> Right, because one can set the letter t to something which
>> would then screw up the idea that t means
>> a truth condition.
>
> (setq t 42)
>
> Debugger entered--Lisp error: (setting-constant t)
>   signal(setting-constant (t))
>   (progn (signal 'setting-constant (list 't)))
>   (progn (progn (signal 'setting-constant (list 't))))
>   elisp--eval-last-sexp(nil)
>   eval-last-sexp(nil)
>   funcall-interactively(eval-last-sexp nil)
>   command-execute(eval-last-sexp)
>
> And `t' is not a "letter" here; it's a _symbol_ whose name
> is "t".

Okay, so they don't allow that anymore. Good, I guess.

Or maybe I did it in another way than using `setq', I say this
because I remember it very well that suddenly nothing worked.

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : Re: cond construct for situation when a variable is t

[Heime]

Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, August 23rd, 2023 at 4:17 AM, Drew Adams <drew.adams@oracle.com> wrote:


> > There is no 'boolean datatype' in elisp.
> > With nil and empty list () being false,
> > anything else is true.
> 
> 
> There's no real true or false in Lisp. But yes,
> that's the convention, and that convention is
> baked into primitive conditionals, such as `if' and` cond'. So sure, you can think of it as
> being more than a convention.
> 
> > That t is used for true, is that by convention ?
> > Should t be used, or is it unreliable ?
> 
> 
> Just like the "convention" described above, it's
> a convention. But also just like it, it's baked
> into primitives. So yes, the constant `t' is a
> typical non-nil value used by conditionals to
> represent "true". And it's the canonical way to
> represent "true", meaning that it's the clearest
> way to tell human readers of code that "true" is
> meant.

The canonical convention also stipulates that the symbol
t is not to be modified to something else though, am I right ?

RE: [External] : Re: cond construct for situation when a variable is t

[Drew Adams]

> > > There is no 'boolean datatype' in elisp.
> > > With nil and empty list () being false,
> > > anything else is true.
> >
> >
> > There's no real true or false in Lisp. But yes,
> > that's the convention, and that convention is
> > baked into primitive conditionals, such as `if' and` cond'. So sure, you
> can think of it as
> > being more than a convention.
> >
> > > That t is used for true, is that by convention ?
> > > Should t be used, or is it unreliable ?
> >
> >
> > Just like the "convention" described above, it's
> > a convention. But also just like it, it's baked
> > into primitives. So yes, the constant `t' is a
> > typical non-nil value used by conditionals to
> > represent "true". And it's the canonical way to
> > represent "true", meaning that it's the clearest
> > way to tell human readers of code that "true" is
> > meant.
> 
> The canonical convention also stipulates that the symbol
> t is not to be modified to something else though, am I right ?

Dunno why it would stipulate that, as trying to
change its value raises an error, as I showed.

You can do practically anything in Lisp, so maybe
there's a way to change its value (you can certainly
change the value of a symbol `t' in a different
obarray, but that's not what we're talking about).

RE: [External] : Re: cond construct for situation when a variable is t

[Drew Adams]

> >> Right, because one can set the letter t to something which
> >> would then screw up the idea that t means
> >> a truth condition.
> >
> > (setq t 42)
> >
> > Debugger entered--Lisp error: (setting-constant t)
> >   signal(setting-constant (t))
> >   (progn (signal 'setting-constant (list 't)))
> >   (progn (progn (signal 'setting-constant (list 't))))
> >   elisp--eval-last-sexp(nil)
> >   eval-last-sexp(nil)
> >   funcall-interactively(eval-last-sexp nil)
> >   command-execute(eval-last-sexp)
> >
> > And `t' is not a "letter" here; it's a _symbol_ whose name
> > is "t".
> 
> Okay, so they don't allow that anymore. Good, I guess.

Anymore?  It's true at least as far back as Emacs 20:

Signaling: (setting-constant t)
  (setq t 42)
  eval((setq t 42))
  eval-last-sexp((4))
  call-interactively(eval-last-sexp)

You can't even try to get around it by first
unsetting `t':

(makunbound 't)

Debugger entered--Lisp error: (setting-constant t)
  makunbound(t)
  (progn (makunbound 't))
  elisp--eval-last-sexp((4))
  eval-last-sexp((4))
  funcall-interactively(eval-last-sexp (4))
  command-execute(eval-last-sexp)

> Or maybe I did it in another way than using `setq', I say this
> because I remember it very well that suddenly nothing worked.

`M-x report-emacs-bug'