Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The empty list

tfeb.org

Post reply on HN
Print view View original

21–30 of 109 posts

Re: The empty list

#21

Post by tlarkworthy »

shadowgovt wrote: post #7
djha-skin wrote: post #3

It's very difficult to deserialize in serialize things like yaml and json in CL because it doesn't have a distinct false object. When you do deserialize `false` it turns into nil. Then when you serialize it back again it turns into `null`. From a practical perspective, this is annoying. I don't hate using it as a language, it's fine, but because it's different enough than other languages it confuses people.

Yep. It's probably the case that one should have a more complicated serializer / deserializer for JSON in CL (one that takes into account the expected JSON datatypes) because JSON is yet another type and value system from Scheme's and CL's, but there's an isomorphism from the Scheme one to the JSON one and there's no such similar isomorphism for the primitive CL types (though were one so inclined, one could certainly…

There is no undefined value in JSON. (Of course ommitting something is like an undefined)

https://stackoverflow.com/questions/13796751/json-undefined-...

Re: The empty list

#22

Post by shadowgovt »

NoboruWataya wrote: post #18

I've been trying to learn CL by using it to do AOC. As someone coming from mostly Python, there is a lot about it that confuses and, occasionally, frustrates me. Maybe I'm just missing something obvious but it doesn't seem like you can start with an empty list that you can repeatedly append to. The empty list is nil, and `(append nil foo)` seems to just yield `foo`, not `(list foo)`. So trying to append to that objec…

In LISP, the cheap / straightforward operation is attaching things to the front of a list.

Appending to the rear of a list is (usually) going to be the more expensive operation (naively, doing so requires walking all the way to the end of the list, because lists are more like linked list constructs than arrays that silently resize as needed).

Re: The empty list

#23

Post by martinflack »

NoboruWataya wrote: post #18

I've been trying to learn CL by using it to do AOC. As someone coming from mostly Python, there is a lot about it that confuses and, occasionally, frustrates me. Maybe I'm just missing something obvious but it doesn't seem like you can start with an empty list that you can repeatedly append to. The empty list is nil, and `(append nil foo)` seems to just yield `foo`, not `(list foo)`. So trying to append to that objec…

APPEND is for concatenating two lists. If you're trying to add a value, then if your NIL is already in a variable, use PUSH to add the value (to the front). This will build the result list in reverse, so you can NREVERSE it at the end.

Re: The empty list

#24

Post by tuukkah »

NoboruWataya wrote: post #18

I've been trying to learn CL by using it to do AOC. As someone coming from mostly Python, there is a lot about it that confuses and, occasionally, frustrates me. Maybe I'm just missing something obvious but it doesn't seem like you can start with an empty list that you can repeatedly append to. The empty list is nil, and `(append nil foo)` seems to just yield `foo`, not `(list foo)`. So trying to append to that objec…

append concatenates lists so you'd need (append nil '(foo))

Re: The empty list

#25

Post by shadowgovt »

bombolo wrote: post #14
shadowgovt wrote: post #12

Earlier quoted context omitted.

Do you mean you can't iterate a null in JavaScript or in LISP? You can't iterate a null in JavaScript, but that's a design decision of the language that could have gone another way; `for (const elem of null) {do();}` could have been specified to be valid JavaScript that never calls `do()`, but it wasn't because it wasn't.

Well if you could iterate a null, you'd also be able to sum 2 nulls. And you'd need null to carry a length (of zero, I presume).

Correct. Which could, of course, all be defined.

- null + null === null ; list + null === list; null + list === list

- null.length === 0 /* should probably make it a runtime error to write this property, or allow it but have the result be a list with length elements, all undefined */

(Note: somewhat hilariously, null + null is already defined in JavaScript. It, of course, is 0. Wat. ;) )

Whether null and empty list should be different or the same is an old argument, and both directions lead to different problems. http://thecodelesscode.com/case/6

Re: The empty list

#26

Post by thomastjeffery »

lisper wrote: post #6
djha-skin wrote: post #3

It's very difficult to deserialize in serialize things like yaml and json in CL because it doesn't have a distinct false object. When you do deserialize `false` it turns into nil. Then when you serialize it back again it turns into `null`. From a practical perspective, this is annoying. I don't hate using it as a language, it's fine, but because it's different enough than other languages it confuses people.

I share your frustration, particularly since one could add a canonical false value to CL in a backwards-compatible way. But it's too late now. But as a practical solution you could de-serialize false into, say, :false, in order to distinguish them from empty lists, and then do a post-processing step to turn those into nils if you wanted to.

> in a backwards-compatible way. But it's too late now.

You just contradicted yourself.

Re: The empty list

#27

Post by lisper »

thomastjeffery wrote: post #26
lisper wrote: post #6

Earlier quoted context omitted.

I share your frustration, particularly since one could add a canonical false value to CL in a backwards-compatible way. But it's too late now. But as a practical solution you could de-serialize false into, say, :false, in order to distinguish them from empty lists, and then do a post-processing step to turn those into nils if you wanted to.

> in a backwards-compatible way. But it's too late now. You just contradicted yourself.

No, that's not a contradiction. To add a canonical false value you would have to change the semantics of the language, which means you have to change the standard. In general changing standards is possible, but in the case of CL it is not possible for practical reasons: changing standards costs money and no one would fund such an effort. CL is moribund, not unlike Smalltalk, APL, and COBOL.

Re: The empty list

#28

Post by JoelMcCracken »

I like the way scheme does it, but IMO this is one of the least significant reasons scheme choices are much preferable to cl imo. It’s just a much cleaner, friendlier language overall

Re: The empty list

#29

Post by bombolo »

shadowgovt wrote: post #25
bombolo wrote: post #14

Earlier quoted context omitted.

Well if you could iterate a null, you'd also be able to sum 2 nulls. And you'd need null to carry a length (of zero, I presume).

Correct. Which could, of course, all be defined. - null + null === null ; list + null === list; null + list === list - null.length === 0 /* should probably make it a runtime error to write this property, or allow it but have the result be a list with length elements, all undefined */ (Note: somewhat hilariously, null + null is already defined in JavaScript. It, of course, is 0. Wat. ;) ) Whether null and empty list s…

Why not just have empty lists instead of null then? :D Seems simpler.

Re: The empty list

#30

Post by lisper »

tuukkah wrote: post #5

TLDR (at the end): "Certainly the CL approach carries more historical baggage." > Combining the empty list and the special false object can lead to particularly good implementations perhaps. I suppose they wanted the null pointer to represent them both in RAM, because every CPU has an instruction to test whether a value is zero, or even a flag that is set for free when you encounter the value.

That's one reason. Another is that it allows you to use the idiom (if X ...) to test for non-null rather than (if (not (null X)) ...)
Post reply on HN