11 ms·

While I also like Lisp syntax, it's nowhere close to the power of SGML as a text format. SGML gives you regular type checking and inference of omitted tags, inj

While I also like Lisp syntax, it's nowhere close to the power of SGML as a text format. SGML gives you regular type checking and inference of omitted tags, injection-free content transclusion, user-defined Wiki syntax, parametric template expansion, and pipelined, automaton-based processing/styling. I've just published my slides/paper on this topic at http://sgmljs.net/blog.html http://sgmljs.net/blog.html .

lisper 10y ago
There is a one-to-one correspondence between (correct) SGML and S-expressions so your claim that S-expressions are "nowhere close to the power of SGML" cannot possibly be true. It might be true that the tools available for processing S-expressions as markup are not as powerful as the tools for processing SGML, but that is not a limitation of the syntax. BTW, when you say "inference of omitted tags" did you mean "inference of omitted close tags"? Because if so, this is not a feature. It's a patch to cover up a design flaw in SGML, namely, that close tags are required to match and so it is possible to make the mistake of omitting or mismatching them. This is one of the reasons S-expressions are superior to SGML: S-expressions are DRY. SGML isn't.
- kazinator 10y ago
  In fact, inferring missing close tags is criminally stupid; when such a situation is diagnosed in any of the *ML languages, it should be loudly diagnosed. Early in the web history, browsers tried to out-do each other in guessing what broken HTML means and render it. That led to a nasty situation of everyone having to emulate everyone else's bugs and hacks.
  - recursive 10y ago
    Like it or not, it's enshrined in the specification of HTML5.
    - JimDabell 10y ago
      It's actually been a standard part of HTML from the very start. It's got nothing to do with browser guessing and it's not new to HTML 5. To give a concrete example for tannhaeuser's point, consider this document: <!DOCTYPE html> <title>…</title> <p>… This is a completely correct, valid HTML document. The first thing to notice is that it's not a tree made up of elements. That first line is not a tag, and isn't part of the DOM tree. Then we get to the DOM tree. It's got several implied start and end tags, so the tree itself looks like this: html head title … body p … Again, this is a completely correct, valid document and this is the correct way to parse it. While you may be able to represent the parsed DOM as an S-expression, you can't represent all valid HTML documents as S-expressions, at least not in the convenient way people assume – and it's not "broken HTML" to blame.
      - lisper 10y ago
        > you can't represent all valid HTML documents as S-expressions, at least not in the convenient way people assume Of course you can. Here is how to express your example as an s-expression: ((:!doctype html) (:title "This is the title") (:p "...")) Here it is being rendered by CL-WHO: ? (princ (html ((:!doctype "html")) (:title "This is the title") (:p "..."))) <!doctype "html"> <title>This is the title </title> <p>... </p>
        JimDabell 10y ago
        No, you're confusing HTML documents with their parsed DOM. The example you gave is different HTML to the example I gave.
        joe-user 10y ago
        Although the HTML he (lisper) gave is different in that it has the closing </p> tag, I'm failing to see any case where this is bad or would result in different behavior from your example. To be clear, he seems to be talking about rendering HTML only, not parsing it. Wouldn't both your example and his have the same parsed DOM? Am I missing something?
- tannhaeuser 10y ago
  Re tag inference: no I mean both start- and end-tag inference, like HTML does. It's explained in my linked paper, and it's not for "covering up design flaws". I think you're making quite strong conclusions here considering your lack of knowledge of SGML.
  - lisper 10y ago
    We're talking about syntax here. Start-tag inference is not syntactic. There is no way to tell if there's a missing start tag in: <a><c></c></a> End-tag inference is semi-syntactic. You can tell that the following might have a missing end tag: <a><c></a> But the previous example definitely does not.
    - tannhaeuser 10y ago
      SGML/HTML tag inference is guided by content model declarations, eg. <!ELEMENT html O O (head,body)> tells SGML that the html element should contain a head element, followed by a body element. "O O" (capital letter O for omission) are tag omission indicators (in this case meaning that both the start- and the end-element tags for html can be omitted). This is covered in depth in the linked paper/slides (in fact, covering JimDabell's example exactly).
      - lisper 10y ago
        You really don't seem to understand the difference between syntax and semantics. Syntax has to do with the rules that govern what strings of characters constitute legal programs. Semantics has to do with what strings of characters which are legal programs mean. For example, the following two documents are both syntactically correct: <!document ...> <a><c></c></a> <!document ...> <!element a O O (b,c)> <a><c></c></a> They just have different semantics. If parsed as HTML, the first produces a DOM with two nodes and the second produces a DOM with three nodes. By way of contrast, this is syntactically incorrect: <table><tr><td>data</img> So is this: <img src=x<y.html> There is no DOM that corresponds to those two examples. One of the (many) problems with SGML is that it muddies the distinction between syntax and semantics. That is one of the (many) reasons that using S-expression syntax to write SGML-like languages is advantageous.
kazinator 10y ago
The fact that you can do HTML in Lisp is because there is code behind that doing the semantics. What makes you think that those SGML requirements couldn't be done? Sounds to me like about one week's worth of evening hacking.
- tannhaeuser 10y ago
  You're off several orders of magnitude. Implementing SGML is a multi-year effort. You don't have to take my word for it, James Clark has said the same (he has implemented SGML and XML, and also DSSSL, the Scheme-based precursor of CSS and XSLT). [1]: http://drdobbs.com/a-triumph-of-simplicity-james-clark-on-m/184404686 http://drdobbs.com/a-triumph-of-simplicity-james-clark-on-m/...
  - kazinator 10y ago
    Admittedly, I'm assuming that we can use some typesetting back end; i.e., for instance, we don't have the requirement to generate a typesetter-ready image (or PDF document) without any third-party code; we don't have to do our own font rendering and kerning, etc. Also, I'm assuming we don't have to burn cycles Greenspunning up half of Lisp in some dumb langauge.

lisper 10y ago

There is a one-to-one correspondence between (correct) SGML and S-expressions so your claim that S-expressions are "nowhere close to the power of SGML" cannot possibly be true. It might be true that the tools available for processing S-expressions as markup are not as powerful as the tools for processing SGML, but that is not a limitation of the syntax. BTW, when you say "inference of omitted tags" did you mean "inference of omitted close tags"? Because if so, this is not a feature. It's a patch to cover up a design flaw in SGML, namely, that close tags are required to match and so it is possible to make the mistake of omitting or mismatching them. This is one of the reasons S-expressions are superior to SGML: S-expressions are DRY. SGML isn't.

kazinator 10y ago
In fact, inferring missing close tags is criminally stupid; when such a situation is diagnosed in any of the *ML languages, it should be loudly diagnosed. Early in the web history, browsers tried to out-do each other in guessing what broken HTML means and render it. That led to a nasty situation of everyone having to emulate everyone else's bugs and hacks.
- recursive 10y ago
  Like it or not, it's enshrined in the specification of HTML5.
  - JimDabell 10y ago
    It's actually been a standard part of HTML from the very start. It's got nothing to do with browser guessing and it's not new to HTML 5. To give a concrete example for tannhaeuser's point, consider this document: <!DOCTYPE html> <title>…</title> <p>… This is a completely correct, valid HTML document. The first thing to notice is that it's not a tree made up of elements. That first line is not a tag, and isn't part of the DOM tree. Then we get to the DOM tree. It's got several implied start and end tags, so the tree itself looks like this: html head title … body p … Again, this is a completely correct, valid document and this is the correct way to parse it. While you may be able to represent the parsed DOM as an S-expression, you can't represent all valid HTML documents as S-expressions, at least not in the convenient way people assume – and it's not "broken HTML" to blame.
    - lisper 10y ago
      > you can't represent all valid HTML documents as S-expressions, at least not in the convenient way people assume Of course you can. Here is how to express your example as an s-expression: ((:!doctype html) (:title "This is the title") (:p "...")) Here it is being rendered by CL-WHO: ? (princ (html ((:!doctype "html")) (:title "This is the title") (:p "..."))) <!doctype "html"> <title>This is the title </title> <p>... </p>
      - JimDabell 10y ago
        No, you're confusing HTML documents with their parsed DOM. The example you gave is different HTML to the example I gave.
        joe-user 10y ago
        Although the HTML he (lisper) gave is different in that it has the closing </p> tag, I'm failing to see any case where this is bad or would result in different behavior from your example. To be clear, he seems to be talking about rendering HTML only, not parsing it. Wouldn't both your example and his have the same parsed DOM? Am I missing something?
tannhaeuser 10y ago
Re tag inference: no I mean both start- and end-tag inference, like HTML does. It's explained in my linked paper, and it's not for "covering up design flaws". I think you're making quite strong conclusions here considering your lack of knowledge of SGML.
- lisper 10y ago
  We're talking about syntax here. Start-tag inference is not syntactic. There is no way to tell if there's a missing start tag in: <a><c></c></a> End-tag inference is semi-syntactic. You can tell that the following might have a missing end tag: <a><c></a> But the previous example definitely does not.
  - tannhaeuser 10y ago
    SGML/HTML tag inference is guided by content model declarations, eg. <!ELEMENT html O O (head,body)> tells SGML that the html element should contain a head element, followed by a body element. "O O" (capital letter O for omission) are tag omission indicators (in this case meaning that both the start- and the end-element tags for html can be omitted). This is covered in depth in the linked paper/slides (in fact, covering JimDabell's example exactly).
    - lisper 10y ago
      You really don't seem to understand the difference between syntax and semantics. Syntax has to do with the rules that govern what strings of characters constitute legal programs. Semantics has to do with what strings of characters which are legal programs mean. For example, the following two documents are both syntactically correct: <!document ...> <a><c></c></a> <!document ...> <!element a O O (b,c)> <a><c></c></a> They just have different semantics. If parsed as HTML, the first produces a DOM with two nodes and the second produces a DOM with three nodes. By way of contrast, this is syntactically incorrect: <table><tr><td>data</img> So is this: <img src=x<y.html> There is no DOM that corresponds to those two examples. One of the (many) problems with SGML is that it muddies the distinction between syntax and semantics. That is one of the (many) reasons that using S-expression syntax to write SGML-like languages is advantageous.

kazinator 10y ago

The fact that you can do HTML in Lisp is because there is code behind that doing the semantics. What makes you think that those SGML requirements couldn't be done? Sounds to me like about one week's worth of evening hacking.

tannhaeuser 10y ago
You're off several orders of magnitude. Implementing SGML is a multi-year effort. You don't have to take my word for it, James Clark has said the same (he has implemented SGML and XML, and also DSSSL, the Scheme-based precursor of CSS and XSLT). [1]: http://drdobbs.com/a-triumph-of-simplicity-james-clark-on-m/184404686 http://drdobbs.com/a-triumph-of-simplicity-james-clark-on-m/...
- kazinator 10y ago
  Admittedly, I'm assuming that we can use some typesetting back end; i.e., for instance, we don't have the requirement to generate a typesetter-ready image (or PDF document) without any third-party code; we don't have to do our own font rendering and kerning, etc. Also, I'm assuming we don't have to burn cycles Greenspunning up half of Lisp in some dumb langauge.