5 ms·

...when all we really needed all along was S-expressions.

• zeveb 11y ago
  It really is appalling how many man-millennia have been spent reimplementing an already-realised ideal. Imagine how much better the world would be if we had settled on Lisp or Smalltalk plus s-expressions back in the early 90s!
  • arethuza 11y ago
    Was there ever something that defined schemas for S-expressions? [NB I was using Common Lisp and CLOS in the early 1990s]
    • kyllo 11y ago
      I don't know about for CL but there is for Clojure: https://github.com/Prismatic/schema https://github.com/Prismatic/schema
• kabdib 11y ago
  Wish I could upvote this more than just once. OTOH you kind of need hashes/maps in the real world (sexprs can provide this by syntax, but not necessarily by agreed-upon function). And Unicode. And standard representations for the base datatypes. But aside from that there's no reason to enter the Sea of Arbitrary Anglebrackets.
  • kyllo 11y ago
    OTOH you kind of need hashes/maps in the real world (sexprs can provide this by syntax, but not necessarily by agreed-upon function). And Unicode. And standard representations for the base datatypes. I believe Clojure's EDN format offers all of the above https://github.com/edn-format/edn https://github.com/edn-format/edn
  • zeveb 11y ago
    > OTOH you kind of need hashes/maps in the real world Well, plists (foo bar baz quux) and alists ((foo . bar) (baz . quux)) or ((foo bar) (baz quux)) have provided good enough functionality for quite a long time. > And Unicode. S-expressions can be Unicode: (edelweiß) is a perfectly valid s-expression. > And standard representations for the base datatypes. Common Lisp's extensively documented reader algorithm[1] contains standard read forms for symbols, strings, characters lists, integers, rational numbers, floats, complex numbers, pathnames, structs, comments, vectors, arrays, bitfields as well as some miscellaneous other types. There's no reason that it couldn't be augmented with something like #{} for hashes (although this would require updating the standard: currently, those characters are reserved for the user; maybe #H{} instead?), #D"2015-12-01" for dates, #U"http://www.example.com/" http://www.example.com/" for URLs and so forth. This: #{(title "Example Scheme") (type "object") (properties #{(first-name #{(type string)}) (last-name ${(type string)}) (age ${(description "Age in years") (type integer) (minimum 0)})}) (required #(first-name last-name))} seems a lot nicer to my eyes than: { "title": "Example Schema", "type": "object", "properties": { "firstName": { "type": "string" }, "lastName": { "type": "string" }, "age": { "description": "Age in years", "type": "integer", "minimum": 0 } }, "required": ["firstName", "lastName"] } [1] http://www.lispworks.com/documentation/lw70/CLHS/Body/02_b.htm http://www.lispworks.com/documentation/lw70/CLHS/Body/02_b.h...
    • kabdib 11y ago
      Either of the above are tons better than XML. JSON is fine, but as you point out, things could be better.
  • dragonwriter 11y ago
    > OTOH you kind of need hashes/maps in the real world You need hashes/maps in programming languages. But you don't really need first class support for them in a serialization format, since if you have a way to specify custom types (which you need to serialize arbitrary, user-defined types), you can serialize maps as lists of pairs with an appropriate type annotation.