3 ms·

It is absolutely not-ambiguous: Pairs in parentheses are attributes, everything after is values. He later introduces the || syntax to disambiguate: (foo (bar "z

by anon4 11y ago

It is absolutely not-ambiguous: Pairs in parentheses are attributes, everything after is values. He later introduces the || syntax to disambiguate: (foo (bar "zot")) vs (foo || (bar "zot")). The <|> syntax is also absolutely non-ambiguous.

lisper 11y ago
Well now, this is interesting. All of the other responses here have acknowledged that it is ambiguous (as Erik himself acknowledged) and argued that it should be ambiguous. And here you are saying the exact opposite: it is not ambiguous, the original rendering making it ambiguous is broken and needs to be fixed, and Erik fixes it by introducing new syntax (which, BTW, makes the new representation no longer an S expression). It seems to me that the fact that people can't even agree whether he actually meant P or ~P ought to call his wisdom (or at least his ability to communicate) into question.
- kmill 11y ago
  Erik clearly states that he thinks the attribute/element distinction is "_incredibly_ stupid," and while he does give an example of an expression which combined the two, he does not neglect to call it "pathological." I'm fairly certain that the reason he handles the pathological cases is so that he may interface with other people's XML specs. One can hate the design while meaningfully working with others, right? By the way, it is an S expression. He uses the empty symbol || as a delimiter for the pathological cases. Furthermore, the Enamel syntax he describes is a reader macro; whether you think that is OK is up to your own personal aesthetics, but it is just an alternative syntax for lists (not everything has to syntactically be an S-expression, after all). You (lisper) keep mentioning that there is a distinction between metadata and data, and you mention that composibility is the big distinction. However, as far as I can tell, you can compose child elements in an ordered sequence which you can't do with attributes (though you can append sets of attributes as sets), and you can't nest attributes. It seems to me that the only reason for everything not to be elements is that they take longer to type with XML syntax. Also, child elements are in some sense just attributes with implicit numeric keys, if attributes could be data other than strings. What is an example of this distinction between attributes and elements which is not just syntax?
  - lisper 11y ago
    > Erik clearly states that he thinks the attribute/element distinction is "_incredibly_ stupid," Yes. And I'm saying he's wrong. Not only is he wrong, he's clearly wrong. Not only is it not "incredibly stupid", the distinction between attributes and elements is both reasonable and useful. And the reason it's reasonable and useful is because it reflects a reasonable and useful distinction between data and metadata. > What is an example of this distinction between attributes and elements which is not just syntax? I don't understand that question. My claim is that, in the context of markup languages, there is a useful distinction to be made between data and metadata, and that this distinction is useful enough that it is not unreasonable to make this distinction syntactically. Of course, it doesn't have to be made syntactically. In Lisp, there is no syntactic difference between function calls and control constructs. Consider: (foo (baz bar) bing) Is (bar bar) a function call? If FOO is a macro that expands to: (dotimes (baz bar) bing) then BAZ is a variable binding. Arguably, it would be worthwhile to make a syntactic distinction here. For example, you could use square brackets for variable bindings, so that you could tell that in: (foo [baz bar] bing) BAZ was a variable binding without having to know how FOO was defined. It's not a slam dunk, but it is a defensible position. Likewise, it is a defensible position that the difference between <foo baz=bar>bing</foo> and <foo><baz>bar</baz></foo> -- whatever that difference might actually be in practice -- is valuable and ought to be preserved. Again, not a slam-dunk, but a defensible position. What makes Erik clearly wrong is this his rendering of <foo baz=bar>bing</foo> is NOT actually any simpler than a rendering that preserves the attribute/element distinction. His rendering has EXACTLY the same level of nesting, the same number of tokens. The ONLY difference is the location of a paren. And the way he moves the paren, he loses information. Without a compelling argument why moving that paren has more value than the information that he loses, that paren ought not to be moved. All else being equal (and in this case all else is equal) it is better to keep information than to lose it. Not only does Erik not make a compelling argument, he makes no argument at all. He simply proclaims that it is "incredibly stupid" and his acolytes, for reasons passing my comprehension, agree.
    - ICWiener 11y ago
      > Not only is he wrong, he's clearly wrong. You keep repeating that, but the more you discuss it, the less "clear" it is. > I don't understand your question. You acknowleded that we need to have a specification in order to make sense from a piece of markup. When we know what elements are to be expected in a format, what "clear" and "useful" advantage gives an additional arbitrary syntactic separatation over a sub-element-only layout? and why is it more "reasonnable" to have this separation when it actually make it slightly more difficult to manipulate the data? > My claim is that, in the context of markup languages, there is a useful distinction to be made between data and metadata, ... Originally, attributes made sense "in the context of markup languages" because attributes were metadata and sub-elements where "content". This is a reason why Naggum was first favorable for the distinction. But then the line was blurred, because not everything is so simple and you find attributes that refer to "data" (title attribute) and sub-elements that refer to "meta-data" (<meta> tag, for example). > (foo [baz bar] bind) > ... you could tell that ... BAZ was a variable binding without having to know how FOO was defined. It's not a slam dunk, but it is a defensible position. You don't need to know how FOO was defined, but you have a contract with FOO: there are many other distinctions one could make (not only bindings/parameters): will you invent a new syntax for everyone of them? Is that really useful? XML is used when you don't want to have a complex syntax and when a standard AST suffice. And then, attributes are an added complexity with little benefits.

by anon4 11y ago

lisper 11y ago

Well now, this is interesting. All of the other responses here have acknowledged that it is ambiguous (as Erik himself acknowledged) and argued that it should be ambiguous. And here you are saying the exact opposite: it is not ambiguous, the original rendering making it ambiguous is broken and needs to be fixed, and Erik fixes it by introducing new syntax (which, BTW, makes the new representation no longer an S expression). It seems to me that the fact that people can't even agree whether he actually meant P or ~P ought to call his wisdom (or at least his ability to communicate) into question.

kmill 11y ago
Erik clearly states that he thinks the attribute/element distinction is "_incredibly_ stupid," and while he does give an example of an expression which combined the two, he does not neglect to call it "pathological." I'm fairly certain that the reason he handles the pathological cases is so that he may interface with other people's XML specs. One can hate the design while meaningfully working with others, right? By the way, it is an S expression. He uses the empty symbol || as a delimiter for the pathological cases. Furthermore, the Enamel syntax he describes is a reader macro; whether you think that is OK is up to your own personal aesthetics, but it is just an alternative syntax for lists (not everything has to syntactically be an S-expression, after all). You (lisper) keep mentioning that there is a distinction between metadata and data, and you mention that composibility is the big distinction. However, as far as I can tell, you can compose child elements in an ordered sequence which you can't do with attributes (though you can append sets of attributes as sets), and you can't nest attributes. It seems to me that the only reason for everything not to be elements is that they take longer to type with XML syntax. Also, child elements are in some sense just attributes with implicit numeric keys, if attributes could be data other than strings. What is an example of this distinction between attributes and elements which is not just syntax?
- lisper 11y ago
  > Erik clearly states that he thinks the attribute/element distinction is "_incredibly_ stupid," Yes. And I'm saying he's wrong. Not only is he wrong, he's clearly wrong. Not only is it not "incredibly stupid", the distinction between attributes and elements is both reasonable and useful. And the reason it's reasonable and useful is because it reflects a reasonable and useful distinction between data and metadata. > What is an example of this distinction between attributes and elements which is not just syntax? I don't understand that question. My claim is that, in the context of markup languages, there is a useful distinction to be made between data and metadata, and that this distinction is useful enough that it is not unreasonable to make this distinction syntactically. Of course, it doesn't have to be made syntactically. In Lisp, there is no syntactic difference between function calls and control constructs. Consider: (foo (baz bar) bing) Is (bar bar) a function call? If FOO is a macro that expands to: (dotimes (baz bar) bing) then BAZ is a variable binding. Arguably, it would be worthwhile to make a syntactic distinction here. For example, you could use square brackets for variable bindings, so that you could tell that in: (foo [baz bar] bing) BAZ was a variable binding without having to know how FOO was defined. It's not a slam dunk, but it is a defensible position. Likewise, it is a defensible position that the difference between <foo baz=bar>bing</foo> and <foo><baz>bar</baz></foo> -- whatever that difference might actually be in practice -- is valuable and ought to be preserved. Again, not a slam-dunk, but a defensible position. What makes Erik clearly wrong is this his rendering of <foo baz=bar>bing</foo> is NOT actually any simpler than a rendering that preserves the attribute/element distinction. His rendering has EXACTLY the same level of nesting, the same number of tokens. The ONLY difference is the location of a paren. And the way he moves the paren, he loses information. Without a compelling argument why moving that paren has more value than the information that he loses, that paren ought not to be moved. All else being equal (and in this case all else is equal) it is better to keep information than to lose it. Not only does Erik not make a compelling argument, he makes no argument at all. He simply proclaims that it is "incredibly stupid" and his acolytes, for reasons passing my comprehension, agree.
  - ICWiener 11y ago
    > Not only is he wrong, he's clearly wrong. You keep repeating that, but the more you discuss it, the less "clear" it is. > I don't understand your question. You acknowleded that we need to have a specification in order to make sense from a piece of markup. When we know what elements are to be expected in a format, what "clear" and "useful" advantage gives an additional arbitrary syntactic separatation over a sub-element-only layout? and why is it more "reasonnable" to have this separation when it actually make it slightly more difficult to manipulate the data? > My claim is that, in the context of markup languages, there is a useful distinction to be made between data and metadata, ... Originally, attributes made sense "in the context of markup languages" because attributes were metadata and sub-elements where "content". This is a reason why Naggum was first favorable for the distinction. But then the line was blurred, because not everything is so simple and you find attributes that refer to "data" (title attribute) and sub-elements that refer to "meta-data" (<meta> tag, for example). > (foo [baz bar] bind) > ... you could tell that ... BAZ was a variable binding without having to know how FOO was defined. It's not a slam dunk, but it is a defensible position. You don't need to know how FOO was defined, but you have a contract with FOO: there are many other distinctions one could make (not only bindings/parameters): will you invent a new syntax for everyone of them? Is that really useful? XML is used when you don't want to have a complex syntax and when a standard AST suffice. And then, attributes are an added complexity with little benefits.