5 ms·

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'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.

lisper 4y ago
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.
- kmstout 4y ago
  > you could de-serialize false into, say, :false ... That's the approach that st-json [0] builds on: - true and false become :true and :false, respectively - [] becomes nil - {} becomes #s(st-json:jso :alist nil) --- [0] in QuickLisp and at https://github.com/marijnh/ST-JSON https://github.com/marijnh/ST-JSON
  - lisper 4y ago
    Yeah, good point. IMHO the lack of a canonical serialization for hash tables is a much more serious omission than not having a separate boolean false value.
- thomastjeffery 4y ago
  > in a backwards-compatible way. But it's too late now. You just contradicted yourself.
  - lisper 4y ago
    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.
    - ykonstant 4y ago
      >CL is moribund, not unlike Smalltalk, APL, and COBOL. If someone wants to do some hobby/small-scale but complex programming in LISP, what kind of dialect should they use? Scheme/Racket or something else?
      - lisper 4y ago
        Personally I do all my personal coding in CL but it's a matter of taste. Another word for "moribund" is "stable" and that can be a good thing. But it really is mostly personal preference. And you might want to add Clojure to your list of languages to consider. The reason I like CL is that I find it is a local optimum impedance match for my brain in language design space. But that is at least in part because I have been using it for 35 years so I am used to its quirks (of which there are many). But it also has lots of really nice features, some of which are still unique to CL and which I find indispensable to my coding style. Generic functions are at the top of that list, and a close second is the macro system.
        baq 4y ago
        I'm afraid you're confusing 'stable' with 'stagnant'. (The dictionary suggests 'dying'... I won't go there ;))
        lisper 4y ago
        CL is not stagnant. SBCL and Quicklisp are still active, and Franz is still a going concern.
shadowgovt 4y ago
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 build one in one's own application). I'd be willing to argue that this is indicative of JSON's unnecessary complexity (inherited from its source language... why does JavaScript need a false and an empty array and a null and even an undefined?), but reasonable developers can disagree on that point.
- bombolo 4y ago
  You want empty lists because you can't iterate a null. So an empty list should be an empty list, otherwise it will require special code to check for the null case.
  - shadowgovt 4y ago
    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.
    - bombolo 4y ago
      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).
      - shadowgovt 4y ago
        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 http://thecodelesscode.com/case/6
stassats 4y ago
> it's different enough than other languages it confuses people. And javascript integers (or lack thereof) don't match CL integers. So if you want to interoperate between distinct languages you do have to consider the differences anyway.
User23 4y ago
I agree that it’s annoying. It is possible to work around without too much trouble by defining some other constant that evaluates to nil to distinguish.
rhn_mk1 4y ago
Serialization formats not designed specifically for the language should not be treated as serializers for objects in that language. That is, JSON is not a representation of objects in your language. It's your application that holds a representation of JSON data. If you're not paying attention to the translation layer between your native objects and the JSON ones, you'll hit problems sooner or later.
- scatters 4y ago
  JSON is the JavaScript Object Notation; it's in the name! The closer your language's object model is to JavaScript, the more likely it is you'll get away with treating it as a direct serialization format. Conversely, the further your language is from JavaScript, the more you'll need to add types specifically to represent JSON.
dragonwriter 4y ago
> It's very difficult to deserialize in serialize things like yaml and json in CL because it doesn't have a distinct false object. Its not particularly hard to represent JSON’s type system in CL and deserialize JSON to CL objects. Its also not particularly hard to construct and use a model of CL data in JSON from CL. (Its even easier with YAML.) OTOH, yes, JSONs data model is almost exactly JS’s data model (minus anything callable, which js a lot of JS, and with a slightly different model of numbers, but anything that doesn’t exactly match JS’s model is canonically unreliable and so discouraged), So with any thing other than JS using JSON, you have to determine if your use case is modeling your language’s data in JSON or JSON’s data model in your language, while with a particular subset of JS you can just ignore the distinction.

lisper 4y ago

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.

kmstout 4y ago
> you could de-serialize false into, say, :false ... That's the approach that st-json [0] builds on: - true and false become :true and :false, respectively - [] becomes nil - {} becomes #s(st-json:jso :alist nil) --- [0] in QuickLisp and at https://github.com/marijnh/ST-JSON https://github.com/marijnh/ST-JSON
- lisper 4y ago
  Yeah, good point. IMHO the lack of a canonical serialization for hash tables is a much more serious omission than not having a separate boolean false value.
thomastjeffery 4y ago
> in a backwards-compatible way. But it's too late now. You just contradicted yourself.
- lisper 4y ago
  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.
  - ykonstant 4y ago
    >CL is moribund, not unlike Smalltalk, APL, and COBOL. If someone wants to do some hobby/small-scale but complex programming in LISP, what kind of dialect should they use? Scheme/Racket or something else?
    - lisper 4y ago
      Personally I do all my personal coding in CL but it's a matter of taste. Another word for "moribund" is "stable" and that can be a good thing. But it really is mostly personal preference. And you might want to add Clojure to your list of languages to consider. The reason I like CL is that I find it is a local optimum impedance match for my brain in language design space. But that is at least in part because I have been using it for 35 years so I am used to its quirks (of which there are many). But it also has lots of really nice features, some of which are still unique to CL and which I find indispensable to my coding style. Generic functions are at the top of that list, and a close second is the macro system.
      - baq 4y ago
        I'm afraid you're confusing 'stable' with 'stagnant'. (The dictionary suggests 'dying'... I won't go there ;))
        lisper 4y ago
        CL is not stagnant. SBCL and Quicklisp are still active, and Franz is still a going concern.

shadowgovt 4y ago

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 build one in one's own application). I'd be willing to argue that this is indicative of JSON's unnecessary complexity (inherited from its source language... why does JavaScript need a false and an empty array and a null and even an undefined?), but reasonable developers can disagree on that point.

bombolo 4y ago
You want empty lists because you can't iterate a null. So an empty list should be an empty list, otherwise it will require special code to check for the null case.
- shadowgovt 4y ago
  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.
  - bombolo 4y ago
    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).
    - shadowgovt 4y ago
      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 http://thecodelesscode.com/case/6

stassats 4y ago

> it's different enough than other languages it confuses people. And javascript integers (or lack thereof) don't match CL integers. So if you want to interoperate between distinct languages you do have to consider the differences anyway.

User23 4y ago

I agree that it’s annoying. It is possible to work around without too much trouble by defining some other constant that evaluates to nil to distinguish.

rhn_mk1 4y ago

Serialization formats not designed specifically for the language should not be treated as serializers for objects in that language. That is, JSON is not a representation of objects in your language. It's your application that holds a representation of JSON data. If you're not paying attention to the translation layer between your native objects and the JSON ones, you'll hit problems sooner or later.

scatters 4y ago
JSON is the JavaScript Object Notation; it's in the name! The closer your language's object model is to JavaScript, the more likely it is you'll get away with treating it as a direct serialization format. Conversely, the further your language is from JavaScript, the more you'll need to add types specifically to represent JSON.

dragonwriter 4y ago

> It's very difficult to deserialize in serialize things like yaml and json in CL because it doesn't have a distinct false object. Its not particularly hard to represent JSON’s type system in CL and deserialize JSON to CL objects. Its also not particularly hard to construct and use a model of CL data in JSON from CL. (Its even easier with YAML.) OTOH, yes, JSONs data model is almost exactly JS’s data model (minus anything callable, which js a lot of JS, and with a slightly different model of numbers, but anything that doesn’t exactly match JS’s model is canonically unreliable and so discouraged), So with any thing other than JS using JSON, you have to determine if your use case is modeling your language’s data in JSON or JSON’s data model in your language, while with a particular subset of JS you can just ignore the distinction.