Talk:S-expressions: Difference between revisions
→JavaScript version bugfix for \" and \n in strings: added example
(→JavaScript version bugfix for \" and \n in strings: added example) |
|||
| (8 intermediate revisions by 5 users not shown) | |||
Line 15:
Common Lisp: ANSI Standard available in the form of the [[http://www.lispworks.com/documentation/HyperSpec/Front/index.htm Common Lisp HyperSpec]]. The reader syntax is described in [[http://www.lispworks.com/documentation/HyperSpec/Body/02_.htm Syntax]].
:this page describing the [http://www.lispworks.com/documentation/HyperSpec/Body/02_ad.htm Character Syntax Types] seems most
::Yes. In Common Lisp, the reading is very simple. Characters are assigned to categories in a read-table (in a context-independent way). The reader takes a character and based on what category it is in, it assembles it into a token, or dispatches a function associated with that character. Donald Knuth's TeX has a similar approach: it also has character categories (which TeX code can manipulate).[[Special:Contributions/24.85.131.247|24.85.131.247]] 02:22, 20 October 2011 (UTC)
:::indeed, i like the approach, it also demonstrates the simplicity of s-expressions (and lisp) syntax. you could not do this as easely with xml or json.--[[User:EMBee|eMBee]] 05:22, 20 October 2011 (UTC)
Line 47:
* atom: a symbol, string or number
* S-Expression: a sequence of atoms or S-Expressions separated by whitespace and surrounded by parentheses ()
do we need others? the rfc above introduces special syntax for hex, and base64 encodings, as well as length-prefix encodings, all of which i consider not needed. there are other standards for hex, and there are other encodings, so i don't see why they need to be treated special.
Line 233 ⟶ 234:
:: if it wasn't so late i would have added it to the task directly. being late is the reason for it being extra credit. this way the exiting tasks are not invalidated.
:: one could argue to make this a separate task though, but it's debatable which is better. --[[User:EMBee|eMBee]] 07:18, 26 October 2012 (UTC)
== extend task for Associative Arrays, Mappings, Dictionarys? ==
I'd like to extend this task to support Associative Arrays using the Lisp method of Cons Pairs:
((key1 . value1) (key2 . value2)) for { key1:value1, key2:value2 }
i think it is better to add it as Extra Credit to this task instead of creating a new task for it because a new task would require all of the code that this task needs, and then we'll get people wondering if the tasks should be merged.
i am aware that (a b) is equivalent to (a . (b)) in Lisp and therefore any list could be treated as an associative array, however for the purpose of this task (and for the usability as an interchangeable data format, we could just require that a pair with a list as value be written as (a . (b))
for the same reason a solution in lisp better ought to use a hash type when reading the data.
--[[User:EMBee|eMBee]] 11:07, 26 October 2012 (UTC)
== Haskell version failing with GHC 7.10.3 and current Stack ==
Compilation failing with two errors at the moment:
# 'between' is not in scope. (Not included in the imports)
# "Precedence parsing error cannot mix ‘<?>’ [infix 0] and ‘<?>’ [infix 0] in the same infix expression"-- [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 22:12, 27 April 2017 (UTC)
== JavaScript version bugfix for \" and \n in strings ==
I found that the present solution doesn't treat escaped double quotes and newlines in strings right (used in KiCad)
(property "ki_description" "Power symbol creates a global label with name \"GND\" ,\nexample new line")
See below for my "hack" for the procedural version. The functional version is too difficult to read for me - in any case, I hope that the original author comes back to fix it correctly, right now it just works for my purpose
String.prototype.parseSexpr = function () {
//schweick: modified first option in regexp to catch string containing \"
//I just trusted the expression from https://stackoverflow.com/a/30737232 (some others would not work):
var t = this.match(/\s*("(?:[^"\\]*(?:\\.)?)*"|\(|\)|"|[^\s()"]+)/g)
for (var o, c = 0, i = t.length - 1; i >= 0; i--) {
var n, ti = t[i].trim()
if (ti == '"') return
else if (ti == '(') t[i] = '[', c += 1
else if (ti == ')') t[i] = ']', c -= 1
else if ((n = +ti) == ti) t[i] = n
// schweick: inserted two replacements to double escape \", \n in strings
// which otherwise would loose their backslash in toPretty():
else t[i] = '\'' + ti.replace('\'', '\\\'').replace(/\\"/g, '\\\\"').replace(/\\n/g, '\\\\n') + '\''
if (i > 0 && ti != ']' && t[i - 1].trim() != '(') t.splice(i, 0, ',')
if (!c) if (!o) o = true; else return
}
return c ? undefined : eval(t.join(''))
}
Please delete my comment above when taken care of on the main page
[[User:Schweick|Schweick]] ([[User talk:Schweick|talk]]) 09:17, 25 January 2023 (UTC)
| |||