5 ms·

I don't agree with this at all, and I wonder if it reflects what other languages you use that may have shaped your assumptions. `if mylist` feels very much like

by adamc 2y ago

I don't agree with this at all, and I wonder if it reflects what other languages you use that may have shaped your assumptions. `if mylist` feels very much like Common Lisp to me. In much of the code I've seen, the value would never be none because an empty list was definitely created.

Joker_vD 2y ago
Ah yes, reusing an empty list NIL as the false value because having a separate #f atom is bad for whatever reason.
- adamc 2y ago
  It is very convenient and makes the code terse and that matters.
  - Joker_vD 2y ago
    May I suggest J (or K) to you then? It has even more conveniences, and allows for much terser code than LISP — even its name is terser! And has even less extraneoues syntax: did you know that parentheses can also be dispensed with? It's true!
- kazinator 2y ago
  But it's only one value in the entire system. There is only one nil; there is no other false but nil. And there is no other empty list but nil. An empty array or string are not false. Zero is not false. In Lisp dialects with nil, we don't have endless discussions about how to test for false, or for empty, as the case may be.
  - Joker_vD 2y ago
    > And there is no other empty list but nil. Okay? That still doesn't justify using it as replacement for #f (which is also a unique value). Or as #t for that matter, there is also only one #t in the entire system. > An empty array or string are not false. Zero is not false. And an empty list is also not false, only #f is false. So simple and uniform! Wait, there is no #f, but an empty list is false? Why? Why is empty list so special? Or, alternatively, why are you using the false value as an empty list? The idea to represent a list as [1 | [2 | [3 | False]]] is quite strange. Just spare an atom, it's only what, eight bytes nowadays? > how to test for false In sane programming languages, the booleans are self-testing, so to speak, and they are the only values with such property, so: if not val then ... (if (not val) ... tests for false. > or for empty if val_specific_is_empty(val) then ... (if (null? val) ... But of course, it only matters for languages that have other options for building composite data types than CONS-ing two items together.
    - kazinator 2y ago
      No language with completely separate booleans has ever had a fun club. (Scheme isn't that language, because everything that is not #f is true.) List processing is cumbersome in Scheme because the empty list is't false, and because car and cdr cannot be applied to (). (Which, stupidly, isn't even self-evaluating; you have to use '()). The empty list is special because once upon a time lisp emphasized list processing more. Complex list processing is still important in metaprogramming, and representations of flexible dynamic data sets. You're not working with lists, it utterly doesn't matter that nil also has a role as the empty list. Just like you don't care that your physician also plays saxophone in a jazz band; he's not doing it during your appointment.

by adamc 2y ago

Joker_vD 2y ago

Ah yes, reusing an empty list NIL as the false value because having a separate #f atom is bad for whatever reason.

adamc 2y ago
It is very convenient and makes the code terse and that matters.
- Joker_vD 2y ago
  May I suggest J (or K) to you then? It has even more conveniences, and allows for much terser code than LISP — even its name is terser! And has even less extraneoues syntax: did you know that parentheses can also be dispensed with? It's true!
kazinator 2y ago
But it's only one value in the entire system. There is only one nil; there is no other false but nil. And there is no other empty list but nil. An empty array or string are not false. Zero is not false. In Lisp dialects with nil, we don't have endless discussions about how to test for false, or for empty, as the case may be.
- Joker_vD 2y ago
  > And there is no other empty list but nil. Okay? That still doesn't justify using it as replacement for #f (which is also a unique value). Or as #t for that matter, there is also only one #t in the entire system. > An empty array or string are not false. Zero is not false. And an empty list is also not false, only #f is false. So simple and uniform! Wait, there is no #f, but an empty list is false? Why? Why is empty list so special? Or, alternatively, why are you using the false value as an empty list? The idea to represent a list as [1 | [2 | [3 | False]]] is quite strange. Just spare an atom, it's only what, eight bytes nowadays? > how to test for false In sane programming languages, the booleans are self-testing, so to speak, and they are the only values with such property, so: if not val then ... (if (not val) ... tests for false. > or for empty if val_specific_is_empty(val) then ... (if (null? val) ... But of course, it only matters for languages that have other options for building composite data types than CONS-ing two items together.
  - kazinator 2y ago
    No language with completely separate booleans has ever had a fun club. (Scheme isn't that language, because everything that is not #f is true.) List processing is cumbersome in Scheme because the empty list is't false, and because car and cdr cannot be applied to (). (Which, stupidly, isn't even self-evaluating; you have to use '()). The empty list is special because once upon a time lisp emphasized list processing more. Complex list processing is still important in metaprogramming, and representations of flexible dynamic data sets. You're not working with lists, it utterly doesn't matter that nil also has a role as the empty list. Just like you don't care that your physician also plays saxophone in a jazz band; he's not doing it during your appointment.