Talk:S-expression

Are s-exprs data structures, or a notation for them?

The article presents an (somewhat implicit) definition of s-exprs as binary trees with atoms as the leaves, but McCarthy himself defined them as notation that translates to these structures:

We shall now define the S-expressions (S stands for symbolic). They are formed by using the special characters

.

)

(

and an infinite set of distinguishable atomic symbols.

I think the article should be changed to reflect this. The whole point of s-exprs is to convey lists, not to represent them in memory as cons cells or in any other way. Qwertyus (talk) 11:19, 16 February 2012 (UTC)

True, it is the first time I see sexps described as pairs, and it is all the more misleading with the illustration, which also shows a binary tree, but not the same as pairs. The article needs a serious rewrite. Nowhere man (talk) 13:54, 7 August 2013 (UTC)

The diagram is incorrect - it's missing terminating NILs. I've replaced it with a rough PNG that shows the actual cons cell structure as trees (though this is not the ideal visualisation for cons cells). But at least the NILs are visible now. Natecull (talk) 03:47, 17 February 2014 (UTC)

Python parsing code example

The parser function is beautiful, but it has some errors. If the input is "1" the result is []. "1 1" gives ['1'], but "1 1 ()" gives ['1', '1', []]. Also, it lacks error handling to deal with mismatched (missing or extraneous) parentheses. Although I realize that code examples can't be expected to be complete, I think it would be nice if this was fixed. Alas, I am not a Python programmer... --Lasse Hillerøe Petersen (talk) 22:14, 28 June 2017 (UTC)

I really don't see the need for it at all. It's inappropriate here, in my view. Also I question whether it can handle unicode. Also any system based on s-exprs would surely have a solid parser available. And that's on top of the criticism above. Suggest we remove? 92.0.31.235 (talk) 11:25, 25 October 2018 (UTC)

After no feedback to this comment, I removed it. 79.75.123.141 (talk) 14:39, 22 November 2018 (UTC)

Weird sentence?

"For simple use cases, S-expressions are simpler than XML, but for more advanced use cases, XML has a query language so called XPath, many tools and third party libraries to simplify the handling of XML data."

The first half of this sentence seems to be leading you to something like "but for more advanced use cases, XML <is simpler because...>" but instead explains that the extra complexity of XML is handled by tools and libraries. That is, I read this as essentially: "for simple cases S-expressions are simpler; for complex cases XML is still complex and you need further tools to deal with that complexity". (Could probably drop the 'so' too.) 92.29.44.72 (talk) 10:10, 1 December 2023 (UTC)