6 ms·

It's oh so convenient until it isn't; until you need to make distinctions between missing values and booleans. I still haven't decided if it's a good idea or n

• blacktriangle 5y ago
  In which data structures? For example in CL hashes use multiple returns so in 99% of cases you can just not care, and when you do care about the difference you just check the second return value.
  • fiddlerwoaroof 5y ago
    Yes, I think the two return values convention in CL mostly makes this a non-issue.
  • codr7 5y ago
    I've run into issues when interfacing databases and writing interpreters, and probably more that I've forgotten. They're just minor culture clashes that add up...
    • ruricolist 5y ago
      I like the way CL does things but it makes dealing with JSON occasionally annoying.
      • fmakunbound 5y ago
        Do you mean, for example, a null node versus a missing node?
        • ruricolist 5y ago
          I mean distinguishing between `null`, `false`, and `[]` on the JSON side. Most JSON libraries for CL by default parse them all as `nil`. (ST-JSON excepted.)
          • codr7 5y ago
            I guess that means you can't generate false and [] either? So this would be a good example the culture clashes I mentioned, handled badly.
• moonchild 5y ago
  In general, even if you do have a separate boolean type, you need to distinguish between the function which intended to return null and the function which was unable to return anything. We see here also the distinction between sum types and union types: Maybe Maybe a has three variants: None, Some None, and Some Some a; but (T | null) | null collapses to just T | null.
  • b3morales 5y ago
    This has a simple solution. In the same way that Maybe is effectively a container, use a container for the Lisp value. I.e., a list. None -> '() Some None -> '(nil) Some Some a -> '(a)
    • moonchild 5y ago
      Yes, and this is what e.g. assoc and member do. But in those cases there's already a container, whereas in a hash table you would have to construct a new one. I do think that multiple values are easier to use and result in more direct code; the problem is that they don't enforce correct usage the way a container does.
• deleted 5y ago
  [deleted]
• nine_k 5y ago
  SQL has true, false, and null, for a good reason. The nil / null value is an attempt to cheaply produce from type T a type like Maybe T, or Optional<T>, or basically T | nil. It's sort of practical. OTOH making false and nil indistinguishable is much less convenient than one might think, and leads to subtle errors.
  • medstrom 5y ago
    You're saying I should use custom symbols like 'true and 'false and put in checks like (eq 'false x) instead of (null x)? To avoid subtle errors? Honest question.
    • weavie 5y ago
      Postmodern (https://quickref.common-lisp.net/postmodern.htm https://quickref.common-lisp.net/postmodern.htm), a library to interface with Postresql will use the keyword `:null` to represent null, and T and nil to represent boolean true and false.
  • ajuc 5y ago
    And then SQL implementations use empty string as null :)
  • hashkb 5y ago
    JS has false, null, and undefined... and NaN and 0... and nobody is ever confused.