4 ms·

While people are directing their attention here: Last year I looked into Common Lisp for a while, but got turned off when I found that there's no distinction b

by s_kilk 10y ago

While people are directing their attention here: Last year I looked into Common Lisp for a while, but got turned off when I found that there's no distinction between the empty list and boolean false (or nil, in CL-speak). I found this kinda weird and vaguely off-putting. I don't want to write code to handle the diffence between, say, an empty array and false or null in deserialized JSON data. Can anyone comment on whether this comes up as an actual issue in practice?

aidenn0 10y ago
It comes up in practice but is easilly avoided with the mapping of: null -> :null [] -> #() and false -> nil Mapping arrays to lists instead of arrays seems wrong to me, but is what most json libraries do by default. Fortunately most of them allow you to change that.
- s_kilk 10y ago
  Would that mean I'd need to carry the `:null` symbol all throughout the codebase, wherever that data-structure might be accessed?
  - aidenn0 10y ago
    I'm not sure I understand the question. If you need to check if a value is null, you compare it with :null. It does mean that values you are going to serialize out to JSON should use :null rather than the more lispy nil, but JSON interfaces where you are required to send null values are quite rare (in fact I don't recall ever encountering one), so it hasn't been a problem for me in practice.
  - db48x 10y ago
    Symbols are interned, and become a simple integer comparison once compiled. It's no different than comparing against 0, except that :null will have some other non-zero value.
fiddlerwoaroof 10y ago
So, I really dislike truthiness and falsiness in other languages but somehow, in Lisp, it just seems to work. One thing that helps is that, in places where the distinction between null and false matters, other features of lisp help keep them distinct: so, for example, getting a value from a hash table returns nil if the value is not found and, consequently, you can't distinguish a missing key from a stored null. GETHASH solves this by returning multiple values: the first is the value stored (if there is one) while the second indicates whether or not the key was found in the hash table. Similarly, optional arguments [declared like (defun foo (&optional bar))] default to null but, if you want to no whether a value was actually passed, you can change the argument declaration to account for this: (defun foo (&optional (bar nil bar-p))) In this case, when bar isn't passed, bar-p will b nil but when bar is passed, it will be t.

by s_kilk 10y ago

aidenn0 10y ago

It comes up in practice but is easilly avoided with the mapping of: null -> :null [] -> #() and false -> nil Mapping arrays to lists instead of arrays seems wrong to me, but is what most json libraries do by default. Fortunately most of them allow you to change that.

s_kilk 10y ago
Would that mean I'd need to carry the `:null` symbol all throughout the codebase, wherever that data-structure might be accessed?
- aidenn0 10y ago
  I'm not sure I understand the question. If you need to check if a value is null, you compare it with :null. It does mean that values you are going to serialize out to JSON should use :null rather than the more lispy nil, but JSON interfaces where you are required to send null values are quite rare (in fact I don't recall ever encountering one), so it hasn't been a problem for me in practice.
- db48x 10y ago
  Symbols are interned, and become a simple integer comparison once compiled. It's no different than comparing against 0, except that :null will have some other non-zero value.

fiddlerwoaroof 10y ago

So, I really dislike truthiness and falsiness in other languages but somehow, in Lisp, it just seems to work. One thing that helps is that, in places where the distinction between null and false matters, other features of lisp help keep them distinct: so, for example, getting a value from a hash table returns nil if the value is not found and, consequently, you can't distinguish a missing key from a stored null. GETHASH solves this by returning multiple values: the first is the value stored (if there is one) while the second indicates whether or not the key was found in the hash table. Similarly, optional arguments [declared like (defun foo (&optional bar))] default to null but, if you want to no whether a value was actually passed, you can change the argument declaration to account for this: (defun foo (&optional (bar nil bar-p))) In this case, when bar isn't passed, bar-p will b nil but when bar is passed, it will be t.