henryluo

31 ms·

61.
by henryluo 9y ago
Mark ( https://mark.js.org ) is a new notation that extends JSON with a type-name, which can be a more structured way to encode type info, instead of using custom string tag.
62.
Open source project trends for 2018 from GitHub(github.com)
2 points by henryluo 9y ago|0 comments
63.
by henryluo 9y ago
It seems obvious that the most important thing about XML is that it was the first. People did a lot of that with XML just because there was no other alternative. So it might be time to look into alternatives, like Mark ( https://m
64.
Show HN: A threaded or a flat discussion, which is easier to followithuse?
1 points by henryluo 9y ago|0 comments
65.
by henryluo 9y ago
In Mark implementation, care has been taken so that indexed contents are not enumerable. So e.g. when you run a for ... in loop on a Mark object, you'll only see properties, not the contents. This is one of the difference between Mark
66.
by henryluo 9y ago
In Mark, there are two types of 'comment'. // comment and /* comment */ are lexical comments, which are stripped during parsing. Then there's Mark pragma, like {!pragma}, which are preserved in the data m
67.
by henryluo 9y ago
But when s-expression is used to represent document, not a program, then it is also not free to refactor deep nested content. So s-expression is no better than XML/HTML/JSON/Mark when encountering deep nested content.
68.
by henryluo 9y ago
I used grammarkit ( https://github.com/dundalek/GrammKit ), which further uses railroad-diagrams ( https://github.com/tabatkins/railroad-diagrams ) library to generate the RR diagrams. I don't kn
69.
by henryluo 9y ago
Thanks for several comments pointing out the unclearness of what's being "more modern". I've updated the README to be: "The advantage of Mark over S-expressions is that it takes a more modern, JS-first approach in i
70.
by henryluo 9y ago
Being 'more modern' means Mark takes a JS-first or web-first approach in its design. Whether we like it or not, JS has dominated the web. JSON is successful, partly because it takes a JS-first approach. Mark inherits this approach
71.
by henryluo 9y ago
Being 'more modern' means Mark takes a JS-first or web-first approach in its design. Whether we like it or not, JS has dominated the web. JSON is successful, partly because it takes a JS-first approach. Mark inherits this approach
72.
by henryluo 9y ago
Firstly, I highly respect Lisp personally, and I have no intention of downplaying it. As some have seen, the Lisp spirit is actually in the design of Mark. Secondly, to clarify what I mean by 'being more modern'. Of course, it doe
73.
by henryluo 9y ago
Another way to support Mark in other languages, is just to use map for both properties and contents. E.g. in Java, the key in map can be integer. Of course, the performance will not be as good as primitive array. But it can be one man'
74.
by henryluo 9y ago
Data and markup/document separation might not always be that clear cut. The latest trend in CMS systems, piloted by the latest content editors, like Quill, Draft.js, ProseMirror, Slate.js is to use JSON to present the content, instead
75.
by henryluo 9y ago
I'll do that next time.
76.
by henryluo 9y ago
If all other languages have no problem supporting XML, they'll have no problem supporting Mark. It just that in languages like JS and Lua, where an object can be an map and a list at the same time, they'll have the convenience of
77.
by henryluo 9y ago
A new Mark-specific schema will need to be developed, based on the prior art or XML Schema, JSON Scheam, etc.
78.
by henryluo 9y ago
Date can be represented as an object {date '1985-04-12'} in Mark. Not perfect, but we don't have to introduce a lot of built-in types. The syntax can be kept simple.
79.
by henryluo 9y ago
Comment can just be {!comment} or {#comment} in Mark, if you like. In the README example, I deliberately made it resemble HTML comment, so as to make it easier for people to correlate.
80.
by henryluo 9y ago
JSON has a strong selling-point that it is compatible with JS in syntax. It is very hard to make major extension to JSON and still be compatible with JS syntax. Minor changes are possible, like in JSON5. Once it breaks JS compatibility, I d
81.
by henryluo 9y ago
HTML has the problem of </div></div></div></div></div></div></div>. Lisp has the problem of '))))))))'. JSON has the problem of '}}}}}}'. And Y
82.
by henryluo 9y ago
Yes, I'll do that.
83.
by henryluo 9y ago
XML is only semi-structured/typed without schema. JSON and Mark are always typed. Full formal schema definition, as in XML, is often a burden to ad-hoc scripting, which is common in JS. JSON/Mark provides sufficient type info for
84.
by henryluo 9y ago
Thanks for suggesting CBOR. Mark shall definitely have some binary representation, like BSON or CBOR, in future.
85.
by henryluo 9y ago
Removing '{' would make Mark become YAML. But in order to be a superset of JSON, YAML adds support of JSON syntax. So '{' is back.
86.
by henryluo 9y ago
YAML does not have good support for mixed content.
87.
by henryluo 9y ago
When used for mixed content, Mark is not necessarily always slower than JSON. Many existing JSON-based DOM solutions, like JsonML and virtual-dom, need to use several JS objects to represent one element, but Mark uses only one JS object. Ho
88.
by henryluo 9y ago
Thanks for feedback on the security aspect. It is something that Mark definitely needs to consider carefully. Current Mark implementation does not call arbitrary constructor during parsing. The constructors are created from scratch. But app
89.
by henryluo 9y ago
Thanks for the XKCD reference. May be I can use it for my next Mark blog head graphics. :-)
90.
by henryluo 9y ago
Grammar details in section 4 of https://mark.js.org/mark-syntax.html

More ›