What I don't understand is why you (and a lot of other people) just expect S-expression parsers to not have the exact same problems.

▲

eadmund 2 days ago | parent | next [-]

Because canonical S-expressions don’t have numbers, just atoms (i.e., byte sequences) and lists. It is up to the using code to interpret "34" as the string "34" or the number 34 or the number 13,108 or the number 13,363, which is part of the protocol being used. In most instances, the byte sequence is probably a decimal number.

Now, S-expressions as used for programming languages such as Lisp do have numbers, but again Lisp has bignums. As for parsers of Lisp S-expressions written in other languages: if they want to comply with the standard, they need to support bignums.

	▲	tsimionescu a day ago \| parent \| next [-]
		You can write JSON that exclusively uses strings, so this is not really relevant. Sure, maybe it can be considered an advantage that s-expressions force you to do that, though it can also be seen just as easily as a disadvantage. It certainly hurts readability of the format, which is not a 0-cost thing. This is also why all Lisps use more than plain sexps to represent their code: having different syntax for different types helps.
	▲	its-summertime 2 days ago \| parent \| prev \| next [-]
		"it can do one of 4 things" sounds very much like the pre-existing issue with JSON
	▲	motorest 20 hours ago \| parent \| prev [-]
		> Because canonical S-expressions don’t have numbers, just atoms (i.e., byte sequences) and lists. If types other than string and a list bother you, why don't you stick with those types in JSON?

▲

2 days ago | parent | prev | next [-]

[deleted]

▲

01HNNWZ0MV43FF 2 days ago | parent | prev [-]

I think they mean that Common Lisp has bigints by default

▲

ryukafalz 2 days ago | parent [-]

As do Scheme and most other Lisps I'm familiar with, and integers/floats are typically specified to be distinct. I think we'd all be better off if that were true of JSON as well.

I'd be happy to use s-expressions instead :) Though to GP's point, I suppose we might then end up with JS s-expression parsers that still treat ints and floats interchangeably.

	▲	petre a day ago \| parent [-]
		And in addition to that are unable to distingush between a string "42" and a number 42.