Tomorrow, i will return to job but today continue posting.
Another point I find very amazing for social study is next.
I wrote
(a (b (a (a (a (b))))))
and I heard from XML fans -or no so fan- that this way one does not
know -without 'special' editors- what is closing one of latter
")".
Then they say me that one of advantages of technical design of XML is
that end-tags help to readability, because one knows what is closing
what. Sure? I remain unconvinced.
Why any piece of XML (SGML or HTML) I read on tutorials is NOT written
like
<a>
<b>
<a>
<a>
<a>
<b></b></a></a></a></b></a>
or
<a>
<b>
<a>
<a>
<a>
<b></b>
</a>
</a>
</a>
</b>
</a>
if end tags are so good? Why not?
It would be not very difficult to notice that XML is _never_ indented
this way because end tags do not help to matching on those cases.
XML code, like SGML or HTML code, is always indented for _vertical_
matching.
<a>
<b>
<a>
<a>
<a>
<b></b>
</a>
</a>
</a>
</b>
</a>
The empty tags do not really help you to matching once vertically
indented as next code proves
<a>
<b>
<a>
<a>
<a>
<b></b>
</>
</>
</>
</>
</>
You know what is closing each </> because of the vertical aligment with
start tag. Now, one can notice that this is just a verbose version for
[a
[b
[a
[a
[a
[b]
]
]
]
]
]
or
[a
[b
[a
[a
[a
[b]]]]]]
I used [] because -I think- readability of ) at beggining of a line is
lower than for ] or }.
Juan R. wrote:
> Tomorrow, i will return to job but today continue posting.
>
> Another point I find very amazing for social study is next.
>
> I wrote
>
> (a (b (a (a (a (b))))))
>
> and I heard from XML fans -or no so fan- that this way one does not
> know -without 'special' editors- what is closing one of latter
> ")".
>
> Then they say me that one of advantages of technical design of XML is
> that end-tags help to readability, because one knows what is closing
> what. Sure? I remain unconvinced.
>
> Why any piece of XML (SGML or HTML) I read on tutorials is NOT written
> like
>
> <a>
> <b>
> <a>
> <a>
> <a>
> <b></b></a></a></a></b></a>
>
> or
>
> <a>
> <b>
> <a>
> <a>
> <a>
> <b></b>
> </a>
> </a>
> </a>
> </b>
> </a>
>
> if end tags are so good? Why not?
>
> It would be not very difficult to notice that XML is _never_ indented
> this way because end tags do not help to matching on those cases.
>
> XML code, like SGML or HTML code, is always indented for _vertical_
> matching.
>
> <a>
> <b>
> <a>
> <a>
> <a>
> <b></b>
> </a>
> </a>
> </a>
> </b>
> </a>
Indeed. And vertical matching can be used with s-exprs too, as you
have found, in fact it can be used with most free-form data formats.
It's also worth mentioning that if you design the program then you
design how the s-exprs look. So, what you can do is require each sexpr
to end with the same word that started it. ie. (foo stuff .. (more
stuff ...) .. foo)
This is unnecessary though.
Rob Thorpe wrote:
> Indeed. And vertical matching can be used with s-exprs too, as you
> have found, in fact it can be used with most free-form data formats.
The real killers are:
1. People can program with S-exps. Proof: large, comfortably managed
Lisp projects.
2. In spite of the wide adoption of XML, it has not caught on as a
programming notation, in spite of various projects to wrap programming
semantics in XML.
3. Programming languages with matching tags are generally despised and
have by and large died. They were advantageous in the days of the
punched card, when it was important for parsers to do a good job of
recovering from errors. If everything appears hopelessly bungled while
parsing "PROCEDURE FOO" then maybe it's possible to look for a punched
card containing "END FOO", reset the parser, to get more diagnostics
about the program in the same pass, so that the programmers makes fewer
round trips through the punched card job submission process.
There is a more fundamental difference between Lisp and _ML:
Lisp absence of specialized closings ENFORCES NESTING, whereas _ML does
not enforce by itself (requires recommendations and rules).
For instance, HTML does in principle allow to write
<B>some text<UL>more text</B>and more</UL>
while in Lisp a construction like that is impossible.
This is for me the whole difference between them. It is shocking that
XML later forbids this type of constructions, namely the only novelties
it could offer.
On 2006-11-27 17:59:57 +0000, ·······@eurogaran.com said:
> <B>some text<UL>more text</B>and more</UL>
> while in Lisp a construction like that is impossible.
> This is for me the whole difference between them. It is shocking that
> XML later forbids this type of constructions, namely the only novelties
> it could offer.
It is also impossible in SGML (and hence in HTML). To be precise, that
markup might be possible (I haven't checked the DTD, and I don't think
it is in any case, see below) but it will parse as something you
probably don't expect, which will be DTD-dependent but probably
something like:
<b>some text</b><ul><li><b>more text</b>and more</li></ul>
In other words: in SGML everything must nest just as it must in XML
(with possible very weird exceptions which are not allowed by any HTML
DTD) but you can often omit a large amount of the markup, because the
parser can reinstate them. Unfortunately the parser requires knowledge
of the DTD to do so, and one of XML's goals was to allow more of the
parsing to be DTD-less and thus vastly simplify the parser.
Of course, what you are actually referring to is that many things that
render HTML are (or were) essentially `tag soup' systems which don't
care about nesting but just treat (say) <b> as meaning `turn on the
bold flag' and </b> as `turn it off'. That's very different than
saying it was legal HTML.
--tim
(I'm fairly sure the above is not legal because of the </b> - I don't
think the opening <b> can be inferred, but I am wrong.
You are right. I just wanted to point out how markup languages'
semantics end up constraining the superior freedom their syntax offered
over Lisp. I did not comment on whether to enforce nesting is a
necessary thing to do in a language or not, which would by itself be an
interesting matter of discussion.
·······@eurogaran.com wrote:
> You are right. I just wanted to point out how markup languages'
> semantics end up constraining the superior freedom their syntax offered
> over Lisp.
Yes, I see what you mean: SGML (and XML I suppose) has a *syntax* which
would allow much more flexibility than it actually does allow (because
closing tags are labelled), while s-expressions don't.
> I did not comment on whether to enforce nesting is a
> necessary thing to do in a language or not, which would by itself be an
> interesting matter of discussion.
I think that if you don't you rapidly end up in a nightmare of
context-sensitive grammars with resultant hideous parsing performance.
(Or in a nightmare of tag-soup systems which don't care at all about
validity).
--tim
·······@eurogaran.com schrieb:
> There is a more fundamental difference between Lisp and _ML:
> Lisp absence of specialized closings ENFORCES NESTING, whereas _ML does
> not enforce by itself (requires recommendations and rules).
> For instance, HTML does in principle allow to write
> <B>some text<UL>more text</B>and more</UL>
> while in Lisp a construction like that is impossible.
> This is for me the whole difference between them. It is shocking that
> XML later forbids this type of constructions, namely the only novelties
> it could offer.
>
In Lisp you could express your example with a macro:
(html
(:b "some text" (:ul "more text" :/b "and more")))
Andr�
--
From: Holger Schauer
Subject: Re: More fun about S-EXPR versus XML
Date:
Message-ID: <yxzd56z49yq.fsf@gmx.de>
On 4835 September 1993, Kaz Kylheku wrote:
> 2. In spite of the wide adoption of XML, it has not caught on as a
> programming notation, in spite of various projects to wrap programming
> semantics in XML.
FWIW, I recently had the "chance" to work with a scripting language
using XML. It's horrible to put it mildly. If you don't have structure
editing capabilities in your editor, programming in XML is really
going to make you groan.
> 3. Programming languages with matching tags are generally despised and
> have by and large died.
Funny, I recently also had the "chance" to do some programming in
Ruby, which I would discribe as somewhere between Perl and Lisp
(though far nearer towards the Perl end of the scale), and while it
does not have any "tags" as such, it does use "do ... end" often
enough that it reminded me of Pascal. So perhaps the above eulogy
was given a little too early.
Holger
--
--- http://hillview.bugwriter.net/ ---
"Can you imagine if carpenters were like computer scientists? Some of
them would argue that it's not necessary to own a hammer because the
butt of a screwdriver is naildriver-complete."
-- Barry Margolin in comp.lang.lisp
On 2006-11-26 13:07:35 +0000, "Juan R."
<··············@canonicalscience.com> said:
> Then they say me that one of advantages of technical design of XML is
> that end-tags help to readability, because one knows what is closing
> what. Sure? I remain unconvinced.
I think the actual reason for this was that SGML had explicit close
tags. Because that was so painful, SGML then went on to provide a
bunch of stuff so that tags (close and open tags) could be omitted, so
that, say:
<ul>
<li>foo
<li>bar
</ul>
parses as
<ul>
<li>foo</li>
<li>bar</li>
</ul>
But to do this requires the parser to know the DTD, and XML wanted to
avoid that, so it just got rid of all this stuff (which was a good
thing).
Why SGML wanted explicit close tags is another issue. My suspicion
(based on having done stuff with SGML in the very early 90s and read
various of the specs and history at that point) is that SGML was
designed to be typed by people with no editor support at all, and
particularly no kind of matching or indentation support.
I think all other justifications are just spurious rewriting of history.
--tim
Tim Bradshaw wrote:
>
> I think the actual reason for this was that SGML had explicit close
> tags. Because that was so painful, SGML then went on to provide a
> bunch of stuff so that tags (close and open tags) could be omitted, so
> that, say:
>
> <ul>
> <li>foo
> <li>bar
> </ul>
>
> parses as
>
> <ul>
> <li>foo</li>
> <li>bar</li>
> </ul>
>
> But to do this requires the parser to know the DTD, and XML wanted to
> avoid that, so it just got rid of all this stuff (which was a good
> thing).
I cannot continue this interesting discussion because bussy and this is
my last post (at least before next weekend). You point to so
interesting points i am obligated to reply.
I agree that avoiding DTDs has been one fantastic idea (in most cases)
and that that obligate to end tags. However, one of ironies of XML is
that empty tags are obligated when most of XML applications use very
strict DTDs in practice (XHTML, SVG, MathML, CML...).
> Why SGML wanted explicit close tags is another issue. My suspicion
> (based on having done stuff with SGML in the very early 90s and read
> various of the specs and history at that point) is that SGML was
> designed to be typed by people with no editor support at all, and
> particularly no kind of matching or indentation support.
>
> I think all other justifications are just spurious rewriting of history.
redundancy of full end tags was disccused in a xml list in Aug [*]. I
was one of proponents for </> (from SGML) in XML. You can read the full
thread if desire. Some replies were:
Michael Kay:
This was permitted in an early draft of the XML spec, and (IIRC) in the
first Microsoft XML parsers. I remember a client threatening to sue
Microsoft when the spec changed and Microsoft withdrew the capability.
Elliotte Harold:
Irrespective of the costs of changing XML at this late date, it's a bad
idea. Short end-tags make XML too hard to read and too hard to debug.
This was done in SGML, and it was removed from XML for good reason.
Redundancy isn't necessary for computers, but it's critical for humans.
James Fuller:
w/o sounding too argumentative, 'removing unnec clutter' is not solved
by this...putting in an something like </> this will confuse a number
of
users.
Tatu Saloranta:
Actually, I wouldn't really see it as human-oriented
at all (like Elliotte pointed out, removing the name
would be against human readability) thing, but rather
a simple compression method of redundant information.
Mitch Amiano:
</> makes the closure of an element anonymous. To the human reader, a
long span of content in which the start tag is no longer near the
anonymous end tag makes a visual scan useless.
Liam Quin from the W3C said:
One of the reasons we took this out of XML (it was in SGML, of
course) was that we knew from a decade (roughly) of implementation
experience that there were some problems with it.
The most common problem was people losking track of tags, and
thinking they had closed something they hadn't. Sometimes they
would get an error and spend ages trying to fix it. A program
that filled in the close tags would (as they saw it) "do the
wrong thing", and they'd even file bug reports, at SoftQuad we
got bug reports about minimization on a regular basis even
though the problem was always (OK, once someone found a real
bug, so almost always) though it was the data that was faulty.
Moreover, Quin pointed to LISP:
When there was no error, the markup was incorrect.
And sometimes the frustrated people trying to correct the error
would just shove end tags in there until the thing parsed :-)
With a LISP program,
(multiply (3 (add 4 7) 6))
and
(multiply (3 (add 4 7 6)))
are both syntacitcally valid, but when you run them you get different
results.
---
I find curious that Quin wrote about LISP because these examples in
MathML (XML) just are
<apply><times/><apply><cn>3</cn> <apply><plus/>
<cn>4</cn><cn>7</cn></apply> <cn>6</cn></apply></apply>
<apply><times/><apply><cn>3</cn><apply><plus/><cn>4</cn><cn>7</cn><cn>6</cn></apply></apply></apply>
and end tags do not help more than the ")". Therefore again i find an
flawed argument pro XML.
---
It is true that avoiding final tags in input is related to existence of
DTD and autoclosing capabilities, but note i did _not_ wrote about
explicit close tags. I wrote about final matching-names on end tags.
<ul>
<li>foo</>
<li>bar</>
</>
is valid SGML. The end tags are always needed. You can avoid them as
you noticed but then the parser close the list items thanks to matching
a concrete DTD. But it is not valid XML because this option for short
end tags was eliminated from the spec. The "</>" are the verbose
version of ")".
[*] http://lists.xml.org/archives/xml-dev/200608/msg00234.html
Juan R. wrote:
> It is true that avoiding final tags in input is related to existence of
> DTD and autoclosing capabilities, but note i did _not_ wrote about
> explicit close tags. I wrote about final matching-names on end tags.
>
> <ul>
> <li>foo</>
> <li>bar</>
> </>
>
> is valid SGML. The end tags are always needed.
It does, as you say, seem bizarre that XML omitted this - it's not as
convenient as Lisp (or in the textual domain something like TML's <tag
attrs |body ... >, which is as easy to type (deliberately so) for
textual markup as Lisp is for program markup), but it's better than
nothing and it already existed in SGML and does not require DTD
knowledge (I'd actually forgotten this syntax - is it SHORTTAG?).
Even more bizarre, it seems to me, were a lot of the arguments that you
quoted & I elided. Most of them smell to me as if they assume people
will *still* be typing XML with no editor support. From first-hand
experience with TML, which for quite a long time had a parser whose
error messages were basically one of `oops, hit the end of the stream'
or `oops, saw a > I didn't expect' and an emacs major mode which was
simple-minded to say the least, we rather seldom had matching problems,
on quite substantial and deeply nested structures. And in the wider
domain there is really quite a lot of experience with programming
language design (and I don't mean Lisp ) almost none of which use named
closing delimiters (what actually does that's in common use? the
Bourne shell, for some constructs, I suppose).
--tim
On Nov 27, 4:29 am, "Juan R." <··············@canonicalscience.com>
wrote:
> Moreover, Quin pointed to LISP:
>
> When there was no error, the markup was incorrect.
>
> And sometimes the frustrated people trying to correct the error
> would just shove end tags in there until the thing parsed :-)
>
> With a LISP program,
> (multiply (3 (add 4 7) 6))
> and
> (multiply (3 (add 4 7 6)))
> are both syntacitcally valid, but when you run them you get different
> results.
>
Don't you just love it when XML people complain about Lisp while
demonstrating they clearly don't even remember the little bit of it
they learned in their undergrad Survey of Programming Languages course?
Both of the examples above are valid S-expressions, but neither of
them are valid Lisp expressions as they try to call a function named
'3'.
Sheesh...
"bob_bane" <········@gst.com> writes:
> On Nov 27, 4:29 am, "Juan R." <··············@canonicalscience.com>
> wrote:
>> Moreover, Quin pointed to LISP:
>>
>> When there was no error, the markup was incorrect.
>>
>> And sometimes the frustrated people trying to correct the error
>> would just shove end tags in there until the thing parsed :-)
>>
>> With a LISP program,
>> (multiply (3 (add 4 7) 6))
>> and
>> (multiply (3 (add 4 7 6)))
>> are both syntacitcally valid, but when you run them you get different
>> results.
>>
>
> Don't you just love it when XML people complain about Lisp while
> demonstrating they clearly don't even remember the little bit of it
> they learned in their undergrad Survey of Programming Languages course?
> Both of the examples above are valid S-expressions, but neither of
> them are valid Lisp expressions as they try to call a function named
> '3'.
Agreed. But:
(defmacro add (&rest args) `(+ ,@args))
(defmacro multiply (args) `(* ,@args))
(values (multiply (3 (add 4 7) 6))
(multiply (3 (add 4 7 6))))
--> 198 ;
51
--
__Pascal Bourguignon__ http://www.informatimago.com/
NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may
technically be entitled to claim that this product is
ten-dimensional. However, the consumer is reminded that this
confers no legal rights above and beyond those applicable to
three-dimensional objects, since the seven new dimensions are
"rolled up" into such a small "area" that they cannot be
detected.
bob_bane wrote:
> On Nov 27, 4:29 am, "Juan R." <··············@canonicalscience.com>
> wrote:
> > Moreover, Quin pointed to LISP:
> >
> > When there was no error, the markup was incorrect.
> >
> > And sometimes the frustrated people trying to correct the error
> > would just shove end tags in there until the thing parsed :-)
> >
> > With a LISP program,
> > (multiply (3 (add 4 7) 6))
> > and
> > (multiply (3 (add 4 7 6)))
> > are both syntacitcally valid, but when you run them you get different
> > results.
> >
>
> Don't you just love it when XML people complain about Lisp while
> demonstrating they clearly don't even remember the little bit of it
> they learned in their undergrad Survey of Programming Languages course?
> Both of the examples above are valid S-expressions, but neither of
> them are valid Lisp expressions as they try to call a function named
> '3'.
>
I do not love memory faults, and i cannot critize Quin because does not
remembering undergrad LISP courses. He did mean probably
(times (plus 4 7) 6 3)
and
(times (plus 4 7 6) 3)
The important point is that he (one of great W3C guys) used that
example as illustration of good design becoming from the XML camp, but
he just did not notice that the (W3C) representation in XML is
identical but much more verbose than LISP.
That is, he waited that XML expression would contain end tags </times>
and </plus> like
<times> <plus> ...</plus> ... </times>
as proof of better readability, but is not the official approach.
He is claiming that ")" is "evil" because does not explicit what is
closing (apart from nesting level) but in XML, they are using </apply>
instead ")" which is more evil still.
The XML representation is poor than LISP one still people got excited
and i never read that XML is full of Silly (Superfluous) brackets.
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: More fun about S-EXPR versus XML
Date:
Message-ID: <REM-2006dec05-004@Yahoo.Com>
> From: "Juan R." <··············@canonicalscience.com>
> With a LISP program,
> (multiply (3 (add 4 7) 6))
> and
> (multiply (3 (add 4 7 6)))
> are both syntacitcally valid, but when you run them you get different
> results.
Neither is syntactially valid Lisp source code, as somebody pointed
out already. The above claims to be calling a function called 3.
Nevertheless, parsing it visually as just s-expressions, some kind
of data structure, I can see at a glance that the following are
sub-expressions respectively:
(add 4 7)
(add 4 7 6)
By comparison:
> <apply><times/><apply><cn>3</cn> <apply><plus/>
> <cn>4</cn><cn>7</cn></apply> <cn>6</cn></apply></apply>
The equivalent of the first sub-expression isn't visually apparent at all.
> <apply><times/><apply><cn>3</cn><apply><plus/><cn>4</cn><cn>7</cn><cn>6</cn></apply></apply></apply>
Same there, even worse.
If you have a tree-editor to help you, in either case you see something like:
multiply
`--3
|--add
| |--4
| `--7
`--6
multiply
`--3
`--add
|--4
|--7
`--6
It would be quite apparent from the tree view that both are wrong.
> again i find an flawed argument pro XML.
Indeed. For short expressions, s-expression notation is clearly
superior. For extremely large expressions, either is difficult to
parse without help from the editor. But a much larger expression is
feasible as s-expressions than as XML, partly because s-expressions
fit so much more per screenful, assuming both are properly indented.
Robert Maas, see http://tinyurl.com/uh3t wrote:
> > From: "Juan R." <··············@canonicalscience.com>
> > With a LISP program,
> > (multiply (3 (add 4 7) 6))
> > and
> > (multiply (3 (add 4 7 6)))
> > are both syntacitcally valid, but when you run them you get different
> > results.
>
> Neither is syntactially valid Lisp source code, as somebody pointed
> out already. The above claims to be calling a function called 3.
See above Pascal comments and my following reply. The W3C folk probably
did mean
(times (plus 4 7) 6 3)
and
(times (plus 4 7 6) 3)
but -i suppose- his memory failed.
> Nevertheless, parsing it visually as just s-expressions, some kind
> of data structure, I can see at a glance that the following are
> sub-expressions respectively:
> (add 4 7)
> (add 4 7 6)
> By comparison:
> > <apply><times/><apply><cn>3</cn> <apply><plus/>
> > <cn>4</cn><cn>7</cn></apply> <cn>6</cn></apply></apply>
> The equivalent of the first sub-expression isn't visually apparent at all.
> > <apply><times/><apply><cn>3</cn><apply><plus/><cn>4</cn><cn>7</cn><cn>6</cn></apply></apply></apply>
> Same there, even worse.
True. They use a special -does not apply to other XML applications, for
instance XHTML- WS model where any space inside tags is eliminated.
Special identation is also used. Tutorials write.
<apply>
<times/>
<apply>
<plus/>
<cn> 4 </cn>
<cn> 7 </cn>
</apply>
<cn> 6 </cn>
<cn> 3 </cn>
</apply>
and
<apply>
<times/>
<apply>
<plus/>
<cn> 4 </cn>
<cn> 7 </cn>
<cn> 6 </cn>
</apply>
<cn> 3 </cn>
</apply>
Note also that XML introduces a special notation for empty tags, e.g.
<times/> instead real <time></times>.
Readability is poor when using namespaces. Look for (* a (+ b c)) at
[1]
> If you have a tree-editor to help you, in either case you see something like:
> multiply
> `--3
> |--add
> | |--4
> | `--7
> `--6
>
> multiply
> `--3
> `--add
> |--4
> |--7
> `--6
>
> It would be quite apparent from the tree view that both are wrong.
>
> > again i find an flawed argument pro XML.
>
> Indeed. For short expressions, s-expression notation is clearly
> superior. For extremely large expressions, either is difficult to
> parse without help from the editor. But a much larger expression is
> feasible as s-expressions than as XML, partly because s-expressions
> fit so much more per screenful, assuming both are properly indented.
[1] http://cnx.org/content/m9008/latest/
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: More fun about S-EXPR versus XML
Date:
Message-ID: <REM-2006dec07-002@Yahoo.Com>
> From: "Juan R." <··············@canonicalscience.com>
> Note also that XML introduces a special notation for empty tags,
> e.g. <times/> instead real <time></times>.
That's actually not too bad visually. I'm reading along, see the
start of the tag, expect a bunch of stuff and closing tag, but I
see the final / already so I close off my expectation of stuff to
follow. A year or so ago, when I discovered the XHTML transitional
verification site, I started converting some of my Web pages from
<p> and <br> to <p /> and <br /> respectively, which seems to keep
the validator happy, and doesn't break lynx when viewing it.
I suppose in a sense that's cheating. :-)
> [1] http://cnx.org/content/m9008/latest/
Note: This browser cannot correctly display MathML.
That completely kills the MathML idea for me.
Oh, also, several places I've see <apply> used where funcall would
normally be used in Lisp. APPLY in Lisp is quite different. For
example:
(setq x 5)
(setq y 9)
(setq args (list x y))
(+ x y)
(funcall #'+ x y)
(apply #'+ args)
In all the examples, it's as if:
(apply #'+ x y)
which is plum wrong. Apparently the inventor of MathML never
learned that really fundamental part of Lisp?
Robert Maas, see http://tinyurl.com/uh3t wrote:
> > From: "Juan R." <··············@canonicalscience.com>
> > Note also that XML introduces a special notation for empty tags,
> > e.g. <times/> instead real <time></times>.
>
> That's actually not too bad visually. I'm reading along, see the
> start of the tag, expect a bunch of stuff and closing tag, but I
> see the final / already so I close off my expectation of stuff to
> follow. A year or so ago, when I discovered the XHTML transitional
> verification site,
Be carefull with W3C verification, it is limited. Other day i
discovered that it checks as valid a fraction with three childs, when
only can contain two: numerator and denominator!
> I started converting some of my Web pages from
> <p> and <br> to <p /> and <br /> respectively, which seems to keep
> the validator happy, and doesn't break lynx when viewing it.
> I suppose in a sense that's cheating. :-)
Be carefull, the validator is confusing here. From a strict point of
view <br /> is invalid HTML [*]. Current browsers i know accept it as
valid html but there is plans to do this strictly _invalid_ in next
HTML 5 under development by WhatWG body being leaded by 'hixie'. Maybe
you could find legacy problems in a future.
> > [1] http://cnx.org/content/m9008/latest/
> Note: This browser cannot correctly display MathML.
> That completely kills the MathML idea for me.
>
> Oh, also, several places I've see <apply> used where funcall would
> normally be used in Lisp. APPLY in Lisp is quite different. For
> example:
> (setq x 5)
> (setq y 9)
> (setq args (list x y))
> (+ x y)
> (funcall #'+ x y)
> (apply #'+ args)
> In all the examples, it's as if:
> (apply #'+ x y)
> which is plum wrong. Apparently the inventor of MathML never
> learned that really fundamental part of Lisp?
MathML was designed "by committe" and has been rudely critized by
several technical mistakes and glaring omisions. So far as i know no
LISP expert was on.
[*] See section "The Myth of 'HTML-compatible XHTML 1.0 documents'" on
http://www.hixie.ch/advocacy/xhtml
Tim Bradshaw wrote:
> On 2006-11-26 13:07:35 +0000, "Juan R."
> <··············@canonicalscience.com> said:
...
> Why SGML wanted explicit close tags is another issue. My suspicion
> (based on having done stuff with SGML in the very early 90s and read
> various of the specs and history at that point) is that SGML was
> designed to be typed by people with no editor support at all, and
> particularly no kind of matching or indentation support.
>
> I think all other justifications are just spurious rewriting of history.
Possibly. I'd also point out that SGML is incredibly difficult to
parse, AFAIK early parsers had real hard work with it. As usual when a
language is hard to parse its the quality of error messages that
suffers. The end tags allowed the parser to know a little bit more in
error situations than it would have done otherwise.
Rob Thorpe wrote:
> Possibly. I'd also point out that SGML is incredibly difficult to
> parse, AFAIK early parsers had real hard work with it. As usual when a
> language is hard to parse its the quality of error messages that
> suffers. The end tags allowed the parser to know a little bit more in
> error situations than it would have done otherwise.
But it's incredibly hard to parse largely because of all the myriad
options it had to let one *not* type closing tags :-) (Or in fact any
tags at all - there was all sorts of magic which I thankfully forget
which let you do things like replace two newlines with </p><p> or
something.)
--tim