3 ms·

Sadly this is not the case with Scheme and it makes for very unergonomic code, especially for a newbie like me. Which is a shame, because I prefer (Guile) Sche

by sph 2y ago

Sadly this is not the case with Scheme and it makes for very unergonomic code, especially for a newbie like me. Which is a shame, because I prefer (Guile) Scheme to Common Lisp.

pfdietz 2y ago
I'm very tied to Common Lisp, but I'm perfectly fine with the idea of a lisp in which car and cdr would be undefined on nil. Also, I'd be fine with a lisp in which () is not a symbol. I don't think these features of Common Lisp are essential or all that valuable.
- sph 2y ago
  They are not essential, but they make code that operates in lisp more compact and pleasant to write. In Scheme my code is littered with (if (null? lst) ;; handle empty case here ...) Simply because otherwise car throws an error. This whole section is often unnecessary in CL.
  - tmtvl 2y ago
    But you need to handle the empty case anyway otherwise you process nils ad infinitum.
    - erik_seaberg 2y ago
      You can say (if lst ...) if the empty list is falsy, but Scheme eventually chose to add #t and #f. Oddly #f is the only false value but #t is not the only true value.
      - tmtvl 2y ago
        I do prefer nil being the false value as well as the empty list, even if it makes it more awkward to distinguish between 'there is a result, but the result is an empty list' and 'there are no results'. But that has nothing to do with car and cdr in Common Lisp treating nil as though it were `(cons nil nil)'. The only value in that I can see is would be if rplaca and rplacd can do some useful things with that (so `(setf (car symbol-that-currently-points-at-nil) foo)' and `(setf (cdr stcpat) bar)' do those useful things).
        waterhouse 2y ago
        An oldie: https://ashwinram.org/1986/01/28/a-short-ballad-dedicated-to-the-growth-of-programs/ https://ashwinram.org/1986/01/28/a-short-ballad-dedicated-to... Describes the evolution from: (cdr (assq key a-list)) to: (let ((val (assq key a-list))) (cond ((not (null? val)) (cdr val)) (else nil)))
  - guenthert 2y ago
    Now, which is more pleasant to read (arguably the more important question for all, but the most primitive of applications)?
BoiledCabbage 2y ago
> Sadly this is not the case with Scheme and it makes for very unergonomic code, How so? If car of nil returns nil, then how does a caller distinguish between a value of nil and a container/list containing nil? The only way is they can check to see if it's a cons pair or not? So if you have to check if it's a cons pair then you're doing the same thing as in scheme right? I may be missing something, but isn't it effectively the same amount of work just potentially? Need to check for nil and need to check if it's a pair?
- susam 2y ago
  > How so? If car of nil returns nil, then how does a caller distinguish between a value of nil and a container/list containing nil? How about this? CL-USER> (null nil) T CL-USER> (null '(nil)) NIL CL-USER>
  - BoiledCabbage 2y ago
    I think that's my point. You still need a separate call to distinguish the nil rom the list of nil case. At that point, if you're making the two calls how is LISP's behavior any more ergonomic than Scheme. I'm not saying it's not possible, I just don't see it. Can you show code between the two and how one is much worse than the other?
    - g19205 2y ago
      cons is an adt and fundamental building block used to build lists (which is a builtin datatype) it's also used to build other data types. the property we're discussing is useful when you're operating on those other data types, rather than lists. when you're designing those other data types you have to be aware that null can be both the absence of value and a value, so you design those other data types appropriately. the property we're discussing becomes useful and handy when you don't care about that distinction, which is quite often in practice. for example a useful datatype is an association list. (setq x ((a . 1) (b . 2) (c . nil))) you can query it by calling (assoc 'a x) which is going to give you back a cons cell (a . 1) in this case. now the presence or absence of this cell indicates the association. if you want to know explicitly that C is nil, then you have an option to, and it's similar in function call counts to Scheme. if you don't care though about the distinction you can do (cdr (assoc 'a x)) which is going to give you 1. doing (cdr (assoc 'foo x)) will give you nil without erroring out. it's a pretty common pattern. in case of established data types like association list, you will probably have a library of useful functions already defined, like you can write your own getassoc function that hides the above. you can also return multiple values from getassoc the same way as gethash does the first value being the value, and the second value being whether or not there's a corresponding cons cell. but when you define your own adhoc cons cell based structures, you don't have the benefit of predefined functions. so let's say you have an association list of symbols to cons cells (setq x ((a . (foo . 1)) (b . (bar . 2)) (c . nil))). if I want to get foo out of that list, I'll say (cadr (assoc x 'a)) which will return foo. doing (cadr (assoc x 'c)) or (cadr (assoc x 'missing)) will both return nil. these later manipulations require extensive scaffolding in Scheme.

by sph 2y ago

Sadly this is not the case with Scheme and it makes for very unergonomic code, especially for a newbie like me. Which is a shame, because I prefer (Guile) Scheme to Common Lisp.

pfdietz 2y ago

I'm very tied to Common Lisp, but I'm perfectly fine with the idea of a lisp in which car and cdr would be undefined on nil. Also, I'd be fine with a lisp in which () is not a symbol. I don't think these features of Common Lisp are essential or all that valuable.

sph 2y ago
They are not essential, but they make code that operates in lisp more compact and pleasant to write. In Scheme my code is littered with (if (null? lst) ;; handle empty case here ...) Simply because otherwise car throws an error. This whole section is often unnecessary in CL.
- tmtvl 2y ago
  But you need to handle the empty case anyway otherwise you process nils ad infinitum.
  - erik_seaberg 2y ago
    You can say (if lst ...) if the empty list is falsy, but Scheme eventually chose to add #t and #f. Oddly #f is the only false value but #t is not the only true value.
    - tmtvl 2y ago
      I do prefer nil being the false value as well as the empty list, even if it makes it more awkward to distinguish between 'there is a result, but the result is an empty list' and 'there are no results'. But that has nothing to do with car and cdr in Common Lisp treating nil as though it were `(cons nil nil)'. The only value in that I can see is would be if rplaca and rplacd can do some useful things with that (so `(setf (car symbol-that-currently-points-at-nil) foo)' and `(setf (cdr stcpat) bar)' do those useful things).
      - waterhouse 2y ago
        An oldie: https://ashwinram.org/1986/01/28/a-short-ballad-dedicated-to-the-growth-of-programs/ https://ashwinram.org/1986/01/28/a-short-ballad-dedicated-to... Describes the evolution from: (cdr (assq key a-list)) to: (let ((val (assq key a-list))) (cond ((not (null? val)) (cdr val)) (else nil)))
- guenthert 2y ago
  Now, which is more pleasant to read (arguably the more important question for all, but the most primitive of applications)?

BoiledCabbage 2y ago

> Sadly this is not the case with Scheme and it makes for very unergonomic code, How so? If car of nil returns nil, then how does a caller distinguish between a value of nil and a container/list containing nil? The only way is they can check to see if it's a cons pair or not? So if you have to check if it's a cons pair then you're doing the same thing as in scheme right? I may be missing something, but isn't it effectively the same amount of work just potentially? Need to check for nil and need to check if it's a pair?

susam 2y ago
> How so? If car of nil returns nil, then how does a caller distinguish between a value of nil and a container/list containing nil? How about this? CL-USER> (null nil) T CL-USER> (null '(nil)) NIL CL-USER>
- BoiledCabbage 2y ago
  I think that's my point. You still need a separate call to distinguish the nil rom the list of nil case. At that point, if you're making the two calls how is LISP's behavior any more ergonomic than Scheme. I'm not saying it's not possible, I just don't see it. Can you show code between the two and how one is much worse than the other?
  - g19205 2y ago
    cons is an adt and fundamental building block used to build lists (which is a builtin datatype) it's also used to build other data types. the property we're discussing is useful when you're operating on those other data types, rather than lists. when you're designing those other data types you have to be aware that null can be both the absence of value and a value, so you design those other data types appropriately. the property we're discussing becomes useful and handy when you don't care about that distinction, which is quite often in practice. for example a useful datatype is an association list. (setq x ((a . 1) (b . 2) (c . nil))) you can query it by calling (assoc 'a x) which is going to give you back a cons cell (a . 1) in this case. now the presence or absence of this cell indicates the association. if you want to know explicitly that C is nil, then you have an option to, and it's similar in function call counts to Scheme. if you don't care though about the distinction you can do (cdr (assoc 'a x)) which is going to give you 1. doing (cdr (assoc 'foo x)) will give you nil without erroring out. it's a pretty common pattern. in case of established data types like association list, you will probably have a library of useful functions already defined, like you can write your own getassoc function that hides the above. you can also return multiple values from getassoc the same way as gethash does the first value being the value, and the second value being whether or not there's a corresponding cons cell. but when you define your own adhoc cons cell based structures, you don't have the benefit of predefined functions. so let's say you have an association list of symbols to cons cells (setq x ((a . (foo . 1)) (b . (bar . 2)) (c . nil))). if I want to get foo out of that list, I'll say (cadr (assoc x 'a)) which will return foo. doing (cadr (assoc x 'c)) or (cadr (assoc x 'missing)) will both return nil. these later manipulations require extensive scaffolding in Scheme.