> > Lisp expressions are richly typed. How do you write a bitvector in > > XML? A complex number? A rational number? How do you distinguish > > between a symbol and a string? What about circularity? How do you > > write the following in XML?
> > #1=(a b #*0111(d e #1#) #c(2 3/2))
> > In XML, if I have <foo>1234</foo>, what is 1234? Is it a character > > string of four digits? Or is it an integer? Where are the semantics?
> Often it is clear from the context what type it is.
Note that ``often it is'' means ``sometimes it is not''.
Context is that information which is not present in the written representation; it's an implicit, shared understanding between the two communicating parties. As such, it's a catch-all bag; given enough context, you can derive arbitrary amounts of information from a single binary digit.
One problem is that context requires extra processing. If the notation hands me a character string, and the context tells me that it's an integer, I have to parse that character string to turn it into an integer, which means verifying that it has the right lexical form.
Another problem is that there is no universal convention for representing an integer, beyond a simple string of decimal digits. Do I handle a unary minus sign? In some conventions, the sign is part of the integer token; in others, it's an extra symbol that behaves like a unary operator. Can there be whitespace between the leading plus or minus and the digits? What about using bases other than ten? Do we use a prefix? Which one? 0x or #x for hex? Do we pardon and ignore trailing non-digit garbage?
Many programmers will unfortunately handle this case by delegating to the string-integer conversion that is built into their programming language. And so now you have dragged the semantics of a programming language into your XML representation.
> Often it doesn't matter, you can just treat everything as a string.
Often, that creates duplicity of process, overheads and hard to find defects. If data is not uniformly and correctly parsed into a properly typed data structure immediately on entry into the running software, there is no telling what will happen to it.
> And if you want to introduce type, nothing stops you. Example:
I don't *want* to introduce type. Type was introduced in the 1950's by my computing predecessors. In this new millennium, I just want to *use* type.
> <foo type="integer">1234</foo>
I'd rather just write 1234, and be universally understood.
> > > it. It's more verbose, ok, but I wouldn't consider this to be so a > > > great disadvantage.
> > It is not only more verbose, but substantially harder to parse.
> Ok, it's harder to parse. But this doesn't mean that it is a pile of > crap.
Sure it is. Something that lacks important virtues that are needed for excellence in its category is a pile of crap.
Anyone designing a printed data representation should have easy and efficient scanability as a major goal. Another goal should be a standard representation of types. Users of the notation should not have to agree on additional conventions, and use a whole lot of extra syntax, just to distinguish strings, symbols and integers.
> > > For example how would you save a Text document from > > > a wordprocessor with layout informations if you didn't use XML(or > > > something equivalent)?
> > I would use Lisp forms.
> Yes, but as I already said, you can convert any Lisp form to XML and > vice-versa.
You failed to show how my example #1=(a b #*0111(d e #1#) #c(2 3/2)) can be converted to XML and then back without loss of information.
That example has one virtue, by the way: it is universally understood to encode a certain abstract data structure. Even if you encode it into XML, with type information and all, an additional document will be required which will describe the semantics of all the extra tags and attributes you have to invent. That extra context will be needed to convert it to Lisp. The need for that context means that it's not really XML that did the the representing.
> Basically all you said is that XML is harder to parse.
Kaz Kylheku wrote: > As a language, TeX is an complete pile of crap. People use it, > especially in academia, because there is no other way to get equally > good looking documents. Don't assume that because some Lispers use > LaTeX, they endorse it as a language.
In what way is it a pile of crap? The so-called "mistake" people claimed that TeX made was the static/dynamic scoping of macros. However, I have yet to see how he Algol-like scoping works in such a typesetting language.
TeX doesn't need the endorsement of Lispers. It's used by mathematicians, physicists, and theoretical computer scientists.
> Knuth is one of those people who can hack some arcane garbage into > producing great output that is the result of sophisticated > computation. He's the ultimate Real Programmer.
I am not sure about the claim about the "arcane garage" part. Whether Knuth is *the* ultimate real programmer is very much disputable.
> Nothing epitomizes Knuth better than the obtuse instruction set > architecture he designed for the programming examples and exercises in > TAOCP. Bizarre numeric representations, strange encodings, odd > limitations. Blech. (Rhymes with TeX).
Did you ever read how Knuth explain the motivation and the intended improvement on the MIX language? Despite the fact that many people don't like it, it doesn't stop you from skipping all the MIX-coding stuff to enjoy the books. It's only when you are reading part of the volumne two that you need some of MIX code.
* thelif...@gmx.net (thelifter) | I don't understand your criticism of XML.
I sometimes regret that human memory is such a great tool for one's personal life that coming to rely on the wider context it provides in one's communication with others is so fragile. I have explained this dozens of times, but I guess each repetition adds something.
| Basically XML is just another way of writing S-expr or Trees or | whatever you want to call it.
They are not identical. The aspects you are willing to ignore are more important than the aspects you are willing to accept. Robbery is not just another way of making a living, rape is not just another way of satisfying basic human needs, torture is not just another way of interrogation. And XML is not just another way of writing S-exps. There are some things in life that you do not do if you want to be a moral being and feel proud of what you have accomplished.
SGML was a major improvement on the markup languages that preceded it (including GML), which helped create better publishing systems and helped people think about information in much improved ways, but when the zealots forgot the publishing heritage and took the notion that information can be separated from presentation out of the world of publishing into general data representation because SGML had had some success in "database publishing", something went awry, not only superficially, but fundamentally. It is not unlike when a baby, whose mother satisfies its every need before it is even aware that it has been expressed, grows up to believe that the world in general is both influenced by and obliged to satisfy its whims. Even though nobody in their right mind would argue that babies should fend for themselves and earn their own living, at some point in the child's life, it must begin a progression towards independence, which is not merely a quantitative difference from having every need satisfied by crying, but a qualitative difference of enormous consequence. Many an idea or concept not only looks, but /is/ good in its infancy, yet turns destructive later in life. Scaling and maturation are not the obvious processes they appear to be because they take so much time that the accumulated effort is easy to overlook. To be successful, they must also be very carefully guided by people who can envision the end result, but that makes it appear to many as if it merely "happens". Take a good idea out of its infancy, let it age without guidance so it does not mature, and it generally goes bad. If GML was an infant, SGML is the bright youngster far exceeds expectations and made its parents too proud, but XML is the drug-addicted gang member who had committed his first murder before he had sex, which was rape.
SGML is a good idea when the markup overhead is less than 2%. Even attributes is a good idea when the textual element contents is the "real meat" of the document and attributes only aid processing, so that the printed version of a fully marked-up document has the same characters as the document sans tags. Explicit end-tags is a good idea when the distance between start- and end-tag is more than the 20-line terminal the document is typed on. Minimization is a good idea in an already sparsely tagged document, both because tags are hard to keep track of and because clusters of tags are so intrusive. Character entities is a good idea when your entire character set is EBCDIC or ASCII. Validating the input prior to processing is a good idea when processing would take minutes, if not hours, and consume costly resources, only to abend. SGML had an important potential in its ability to let the information survive changes in processing equipment or software where its predecessors clearly failed. But, to continue the baby metaphor, you have to go into fetishism to keep using diapers as you age but fail to mature. (I note in passing that the stereotypical American male longs for much larger than natural female breasts, presumably to maintain the proportion to his own size from his infancy, which has caused the stereotypical American female to feel a need for breasts that will give the next generation a demand for even more disproportionally large breasts.) When the markup overhead exceeds 200%, when attributes values and element contents compete for the information, when the distance between 99% of the "tags" is /zero/, when the character set is Unicode, and when validation takes more time than processing, not to mention the sorry fact that information longevity is more /threatened/ by XML than by any other data representation in the history of computing, then SGML has gone from good kid, via bad teenager, to malfunctioning, evil adult as XML. SGML was in many ways smarter than necessary at the time it was a bright idea, it was evidence of too much intelligence applied to the problems it solved. A problem mankind has not often had to deal with is that of excessive intelligence; more often than not, technological solutions are barely intelligent enough to solve the problem at hand. If a solution is much smarter than the problem and really stupid people notice it, they believe they have got their hands on something /great/, and so they destroy it, not unlike how giving stupid people too much power can threaten world peace and unravel legal concepts like due process and presumption of innocence.
I once believed that it would be very beneficial for our long-term information needs to adorn the text with as much meta-information as possible. I still believe that the world would be far better off if it had evolved standardized syntactic notations for time, location, proper names, language, etc, and that even prose text would be written in such a way that precision in these matters would not be sacrificed, but most people are so obsessively concerned with their immediate personal needs that anything that could be beneficial on a much larger scale have no chance of surviving. Look at the United States of America, with its depressingly moronic units instead of going metric, with its inability to write dates in either ascending or descending order of unit size, and with its insistence upon the 12-hour clock, clearly evidencing the importance of the short-term pain threshold and resistance to doing anyone else's bidding. And now the one-time freest nation of the world has turned dictatorship with a dangerous moron in charge, set to attack Iraq to revenge his father's loss. Those who laughed when I said that stupidity is the worst threat to mankind laugh no more; they wait with bated breath to see if the world's most powerful incoherent moron will launch the world into a world war simply because he is too fucking stupid. But what really pisses me off is the spineless American people who fails to stop this madness. Presidents have been shot and killed before. I seem to be digressing -- the focal point is that the masses, those who exert no effort to better themselves, cannot be expected to help solve any problems larger than their own, and so they must be forced by various means, such as compulsory education, spelling checkers, newspaper editors who do /not/ publish their letters to the editor, and not least by the courts that restrain the will to revenge, in order to keep a modicum of sanity in the frail structure that is human society. We are clearly not at the stage of human development where writers are willing to accept the burden of communicating to the machine what they are thinking. One has to marvel at the wide acceptance of our existing punctuation marks and the sociology of their acceptance. "Tagging" text for semantic constructs that the human mind is able to discern from context must be millennia off.
In many ways, the current American presidency and XML have much in common. Both have clear lineages back to very intelligent people. Both demonstrate what happens when you give retards the tools of the intelligent. Some Americans obsess over gun control, to limit the number of handguns in the hands of their civilians, but support the most out-of-control nutcase in the young history of the nation and rally behind his world-threatening abuse of guns. The once noble concern over validation to curb excessive costs of too powerful a tool for the people who used it, has turned into an equally insane abuse of power in the XML world. How could such staggering idiots as have become "leaders" of the XML world and the free world come to their power? Clearly, they gain support from the masses who have no concerns but their immediate needs, no ability to look for long-term solutions and stability, no desire to think further ahead than that each individual decision they make be the best for them. Lethargy and pessimism, lack of long-term goals, apathy towards consequences, they are all symptoms of depressed people, and it is perhaps no coincidence that the world economy is now in a depression. My take on it is that it is because too much growth also rewarded people of such miniscule intellectual prowess that they turned to fraud rather than tackle the coming negative trends intelligently. Whether Enron or W3C or the GOP, everyone knows that fraud does pay in the short term and that bad money drives out good. When even the staggering morons are rewarded, the honest and intelligent must lose, and even the best character will have a problem when being honest means that he forfeits a chance to received a hundred million dollars. In both the Bush administration and the W3C standards administration, we see evidence that large groups of people did not believe that it would matter who assumed power. I am quite certain that just as
* thelif...@gmx.net (thelifter) | I don't understand your criticism of XML.
I sometimes regret that human memory is such a great tool for one's personal life that coming to rely on the wider context it provides in one's communication with others is so fragile. I have explained this dozens of times, but I guess each repetition adds something.
| Basically XML is just another way of writing S-expr or Trees or | whatever you want to call it.
They are not identical. The aspects you are willing to ignore are more important than the aspects you are willing to accept. Robbery is not just another way of making a living, rape is not just another way of satisfying basic human needs, torture is not just another way of interrogation. And XML is not just another way of writing S-exps. There are some things in life that you do not do if you want to be a moral being and feel proud of what you have accomplished.
SGML was a major improvement on the markup languages that preceded it (including GML), which helped create better publishing systems and helped people think about information in much improved ways, but when the zealots forgot the publishing heritage and took the notion that information can be separated from presentation out of the world of publishing into general data representation because SGML had had some success in "database publishing", something went awry, not only superficially, but fundamentally. It is not unlike when a baby, whose mother satisfies its every need before it is even aware that it has been expressed, grows up to believe that the world in general is both influenced by and obliged to satisfy its whims. Even though nobody in their right mind would argue that babies should fend for themselves and earn their own living, at some point in the child's life, it must begin a progression towards independence, which is not merely a quantitative difference from having every need satisfied by crying, but a qualitative difference of enormous consequence. Many an idea or concept not only looks, but /is/ good in its infancy, yet turns destructive later in life. Scaling and maturation are not the obvious processes they appear to be because they take so much time that the accumulated effort is easy to overlook. To be successful, they must also be very carefully guided by people who can envision the end result, but that makes it appear to many as if it merely "happens". Take a good idea out of its infancy, let it age without guidance so it does not mature, and it generally goes bad. If GML was an infant, SGML is the bright youngster far exceeds expectations and made its parents too proud, but XML is the drug-addicted gang member who had committed his first murder before he had sex, which was rape.
SGML is a good idea when the markup overhead is less than 2%. Even attributes is a good idea when the textual element contents is the "real meat" of the document and attributes only aid processing, so that the printed version of a fully marked-up document has the same characters as the document sans tags. Explicit end-tags is a good idea when the distance between start- and end-tag is more than the 20-line terminal the document is typed on. Minimization is a good idea in an already sparsely tagged document, both because tags are hard to keep track of and because clusters of tags are so intrusive. Character entities is a good idea when your entire character set is EBCDIC or ASCII. Validating the input prior to processing is a good idea when processing would take minutes, if not hours, and consume costly resources, only to abend. SGML had an important potential in its ability to let the information survive changes in processing equipment or software where its predecessors clearly failed. But, to continue the baby metaphor, you have to go into fetishism to keep using diapers as you age but fail to mature. (I note in passing that the stereotypical American male longs for much larger than natural female breasts, presumably to maintain the proportion to his own size from his infancy, which has caused the stereotypical American female to feel a need for breasts that will give the next generation a demand for even more disproportionally large breasts.) When the markup overhead exceeds 200%, when attributes values and element contents compete for the information, when the distance between 99% of the "tags" is /zero/, when the character set is Unicode, and when validation takes more time than processing, not to mention the sorry fact that information longevity is more /threatened/ by XML than by any other data representation in the history of computing, then SGML has gone from good kid, via bad teenager, to malfunctioning, evil adult as XML. SGML was in many ways smarter than necessary at the time it was a bright idea, it was evidence of too much intelligence applied to the problems it solved. A problem mankind has not often had to deal with is that of excessive intelligence; more often than not, technological solutions are barely intelligent enough to solve the problem at hand. If a solution is much smarter than the problem and really stupid people notice it, they believe they have got their hands on something /great/, and so they destroy it, not unlike how giving stupid people too much power can threaten world peace and unravel legal concepts like due process and presumption of innocence.
I once believed that it would be very beneficial for our long-term information needs to adorn the text with as much meta-information as possible. I still believe that the world would be far better off if it had evolved standardized syntactic notations for time, location, proper names, language, etc, and that even prose text would be written in such a way that precision in these matters would not be sacrificed, but most people are so obsessively concerned with their immediate personal needs that anything that could be beneficial on a much larger scale have no chance of surviving. Look at the United States of America, with its depressingly moronic units instead of going metric, with its inability to write dates in either ascending or descending order of unit size, and with its insistence upon the 12-hour clock, clearly evidencing the importance of the short-term pain threshold and resistance to doing anyone else's bidding. And now the one-time freest nation of the world has turned dictatorship with a dangerous moron in charge, set to attack Iraq to revenge his father's loss. Those who laughed when I said that stupidity is the worst threat to mankind laugh no more; they wait with bated breath to see if the world's most powerful incoherent moron will launch the world into a world war simply because he is too fucking stupid. But what really pisses me off is the spineless American people who fails to stop this madness. Presidents have been shot and killed before. I seem to be digressing -- the focal point is that the masses, those who exert no effort to better themselves, cannot be expected to help solve any problems larger than their own, and so they must be forced by various means, such as compulsory education, spelling checkers, newspaper editors who do /not/ publish their letters to the editor, and not least by the courts that restrain the will to revenge, in order to keep a modicum of sanity in the frail structure that is human society. We are clearly not at the stage of human development where writers are willing to accept the burden of communicating to the machine what they are thinking. One has to marvel at the wide acceptance of our existing punctuation marks and the sociology of their acceptance. "Tagging" text for semantic constructs that the human mind is able to discern from context must be millennia off.
In many ways, the current American presidency and XML have much in common. Both have clear lineages back to very intelligent people. Both demonstrate what happens when you give retards the tools of the intelligent. Some Americans obsess over gun control, to limit the number of handguns in the hands of their civilians, but support the most out-of-control nutcase in the young history of the nation and rally behind his world-threatening abuse of guns. The once noble concern over validation to curb excessive costs of too powerful a tool for the people who used it, has turned into an equally insane abuse of power in the XML world. How could such staggering idiots as have become "leaders" of the XML world and the free world come to their power? Clearly, they gain support from the masses who have no concerns but their immediate needs, no ability to look for long-term solutions and stability, no desire to think further ahead than that each individual decision they make be the best for them. Lethargy and pessimism, lack of long-term goals, apathy towards consequences, they are all symptoms of depressed people, and it is perhaps no coincidence that the world economy is now in a depression. My take on it is that it is because too much growth also rewarded people of such miniscule intellectual prowess that they turned to fraud rather than tackle the coming negative trends intelligently. Whether Enron or W3C or the GOP, everyone knows that fraud does pay in the short term and that bad money drives out good. When even the staggering morons are rewarded, the honest and intelligent must lose, and even the best character will have a problem when being honest means that he forfeits a chance to received a hundred million dollars. In both the Bush administration and the W3C standards administration, we see evidence that large groups of people did not believe that it would matter who assumed power. I am quite certain that just as
* thelifter wrote: > k...@ashi.footprints.net (Kaz Kylheku) wrote in message <news:cf333042.0212201140.66c2df58@posting.google.com>... >> In XML, if I have <foo>1234</foo>, what is 1234? Is it a character >> string of four digits? Or is it an integer? Where are the semantics? > Often it is clear from the context what type it is. Often it doesn't > matter, you can just treat everything as a string. And if you want to > introduce type, nothing stops you. Example: > <foo type="integer">1234</foo>
So now I have to write my own little string->integer routine, and my own little string->float routine, and my own little string->x routine for every type x that I want to support that isn't a string. You have no idea the joy I feel at having to write all these little parsers, especially the float one, which I have about 1% chance of getting right.
What was the problem XML was meant to solve, again? Something to do with not having every application have its own little parser for data interchange, wasn't it? But they didn't bother to provide syntax for numbers, a type of data that programs do quote often need to interchange, oh no, because that would have actually involved solving the problem rather than providing employment for a few thousand CS graduates writing yet another buggy, incomplete float parser. Well, I hate to tell you, but the high-tech bubble has pretty much burst and it might be about time that people designing data interchange formats actually designed them, rather than solving some trivial subset problem, badly: paying for non-working systems is no longer fashionable.
Tim Bradshaw <t...@cley.com> writes: > > <foo type="integer">1234</foo>
> So now I have to write my own little string->integer routine, and my > own little string->float routine, and my own little string->x routine > for every type x that I want to support that isn't a string. You have > no idea the joy I feel at having to write all these little parsers, > especially the float one, which I have about 1% chance of getting > right.
Then use <foo xsi:type="xsi:integer" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">1234</foo> or declare the content of foo to be of type xsi:integer in your schema, and use a library that gives you access to the PSVI (AFAIK Apache's Xerces should do).
Oh, you were looking for something that doesn't introduce more problems than it solves? Never mind. But it rocks if your documents contain lots of strangely formatted dates, times and durations ;-)
* Henrik Motakef wrote: > Oh, you were looking for something that doesn't introduce more > problems than it solves? Never mind. But it rocks if your documents > contain lots of strangely formatted dates, times and durations ;-)
Yes. I was looking for something that gives me as good or (preferably) better tradeoffs of utility against complexity than READ does. Better than READ would be easy - have some (not too complex) way of stopping automatic symbol interning for instance - but what XML gives me is so much worse you need a logarithmic scale to even *see* it.
* wni wrote: > In what way is it a pile of crap? The so-called "mistake" people claimed > that TeX made was the static/dynamic scoping of macros. However, > I have yet to see how he Algol-like scoping works in such a typesetting > language.
Try writing complex TeX macros some time. It is *so* much harder than it needs to be. Then try and write a set of complex macros that doesn't give you weird contextual issues (oh, you can't use that macro in headings, you have to use this other one that does the same thing except it works in headings). These problems don't have to exist, but they are very hard to avoid in TeX.
> I would guess I am not the first to attempt this - it might be > interesting to hear of others experience in relation to using s-exp in > this way.
Check out what I've been creating over the last few months. I finally got my new site up three hours ago: https://macrology.co.nz/
I only have one example of the S-expression source available so far at https://macrology.co.nz/?source (this is the source that generated the front page and companion PDF).
Regards, Adam
Note: I have discovered that MSIE 6.0 rendering doesn't markup verbatim and quotation correctly. I'm not sure what the cause is yet but they look fine using Mozilla 1.2.
In article <ey3bs356hf8....@cley.com>, Tim Bradshaw <t...@cley.com> wrote:
>* wni wrote:
>> In what way is it a pile of crap? The so-called "mistake" people claimed >> that TeX made was the static/dynamic scoping of macros. However, >> I have yet to see how he Algol-like scoping works in such a typesetting >> language.
>Try writing complex TeX macros some time. It is *so* much harder than >it needs to be. Then try and write a set of complex macros that >doesn't give you weird contextual issues (oh, you can't use that macro >in headings, you have to use this other one that does the same thing >except it works in headings). These problems don't have to exist, but >they are very hard to avoid in TeX.
These problems are really the problems of LaTeX, which raises expectations about composability and first-class-ness that the raw TeX primitives themselves do not, and that LaTeX ultimately fails to satisfy. Eg, and I think Kaz mentioned this, in LaTeX you can't call \verb inside a \footnote or a \section, although even an intermediate user cannot readily recognize why this should be. For a person coming to terms with the TeX language based on itself, these problems are peculiar library problems. He would read the TeXbook, and then would write \footnote and \section not as functions, but as things that open a group, so he doesn't have the situation of having an already-read argument with already-set catcodes.
This is not to say that TeX has no problems (I will come to that, but even so, it doesn't come close to satisfying any conditions to be called "a pile of crap"). But you have to approach it on its own terms and with humility, instead of "Hey, this is not like my beloved ANSI Common Lisp." A \footnote that interacts well with a potential \verb is then easy and only slightly tedious to write, but only one adept has to do it (because TeX is not a general-purpose or classroom language that everyone has to excel in in order to get good grades or promotions). Actually nobody has to do it, because a good \footnote has already been done in plain.tex. I don't understand why LaTeX didn't use the same approach for its own \footnote.
\section is a wee bit tougher. A \section title is used twice, once in the text, and once in a potential ToC. So you have to \write it out to an aux file in addition to typesetting it in-place. These require two different catcode assignments for the characters in the title. One could solve this problem by writing the title to a temporary location, and then reading it with different catcodes as the need arises. String ports would have solved this neatly, but temp files are good enough, and indeed I used something like that for my own documentation needs, where I embed \verb's in section titles often enough.
This is tedious stuff for people who just want things to work already, but not insurmountably so, and it is not going to satisfy someone expecting Lisp-like composability and higher-order functions and macros etc (but why is he wanting all that if he wants things working already? Is he even someone who can ever be satisfied?). And why should TeX be like Lisp? TeX reads characters one a time, it doesn't read structured data, like Lisp's Read does. If it did the latter, the amount of data it would have to slurp at each of its reads can be very large, given idiosyncratic documents (already Thomas-Mann-like paragraphs can rattle TeX, because TeX does some whole-paragraph analysis). TeX's goals are different -- excellent typographic quality with good reliability and without insanely anal markup -- and it solves them admirably.
The flaws of TeX are not really that it is not Lisplike, but that it is mired in a depression-era approach to computational resources. There are only so many registers available for use as counters, dimens, skips, input streams, output streams, what have you. Once you accept that it is a matter of manipulating these registers, and not about doing Lisp programming, the only problem that remains is having enough of these registers. This TeX does not, and for no good reason other than age. It should be very doable to write a modern TeX that does not have these limitations, or at least move their numbers from 2**8 (or 2**4, for streams) to the slightly less impoverished 2**16 ballpark -- so doable, in fact, that it has already been done more than a decade ago. This would be eTeX, although I'm not 100% sure that they addressed the problem of the fewness of input and output streams, because fixing that would let the user use string-port-like mechanisms freely without worrying about running out of resources. You continue to have the option of doing expressive programming outside of TeX (defining an \evalFollowingSexpInLisp in TeX is very easy), but are now assured that the TeX you generate will not die for want of registers.
Erik Naggum <e...@naggum.no> writes: > I am quite certain that just as Bush is supposed to be a > thoroughly /likable/ person, the people who work up the most > demented "standards" in the W3C lack that personality trait that > is both abrasive and exhibit leadership potential.
We select our leaders over here by `popular' vote (more or less, there is that electoral college, the supreme court, etc., etc. but you can hardly say that Bush was *significantly* (order of magnitude) less popular than Gore).
The US election system is optimized to favor good-looking, personable people with decent on-camera rapport. It works quite well in that regard.
Tim Bradshaw <t...@cley.com> writes: > * wni wrote:
> > In what way is it a pile of crap? The so-called "mistake" people claimed > > that TeX made was the static/dynamic scoping of macros. However, > > I have yet to see how he Algol-like scoping works in such a typesetting > > language.
> Try writing complex TeX macros some time.
Try writing *simple* TeX macros that a) work in all contexts, or b) compose predictably.
* Dorai Sitaram wrote: > These problems are really the problems of LaTeX, which > raises expectations about composability and > first-class-ness that the raw TeX primitives themselves > do not, and that LaTeX ultimately fails to satisfy.
No, I think the problems of writing non-trivial sets of macros in TeX (of which LaTeX is just one) are problems of TeX, not LaTeX. I've done such things (in plain TeX, as well as in LaTeX), and I found it really much harder work than it needed to be. *Perhaps* it is not harder work than is inherent in a macro language (or for that matter things like Unix shells - complex shell scripts are pretty hard to get right if you want to not have them blow up if you feed them something unexpected, like strings with spaces in...), but, well, the answer to that is not to use a macro language. TeX isn't helped any by the TeXbook, which was clearly written by someone with his head on upside down.
The resource issues you mention are another problem, but not really related.
> This is not to say that TeX has no problems (I will > come to that, but even so, it doesn't come close to > satisfying any conditions to be called "a pile of > crap").
No, I don't think it's crap - indeed if you go back in this thread I posted an article where I said that it's unequalled, in my opinion, for typing mathematical stuff, both in quality of output, and in ease of input. I do think that TeX *as a programming language for typesetting* could be very much better, and not (just) because of resource issues. I don't particularly want it to be like Lisp, I just want it to be less painful. In my opinion, the way to do that is by having the programming language be a different thing than the stuff you type in, so `macros' would be written in a completely separate syntax than whatever you type. I'm not even sure that I would change the look-and-feel of the surface syntax at all: TeX is pleasant enough to type text and maths into already.
> But you have to approach it on its own terms > and with humility, instead of "Hey, this is not like my > beloved ANSI Common Lisp."
I'm not likely to do that - I knew TeX some time before I knew CL (possibly before I knew any Lisp), indeed, I think I new TeX before CLtL1 was published...
| Tim Bradshaw <t...@cley.com> writes: | | > Try writing complex TeX macros some time. | | Try writing *simple* TeX macros that a) work in all contexts, or | b) compose predictably.
No problem, so long as you can do it entirely within the macro processor (aka TeX's mouth). In fact, you can do a decent bit of functional programming there. (Alan Jeffrey: Lists in TeX's Mouth, Tugboat vol 11 #2 (1990), 237-245.)
Henrik Motakef <henrik.mota...@web.de> writes: > Tim Bradshaw <t...@cley.com> writes: > > > <foo type="integer">1234</foo>
> Then use <foo xsi:type="xsi:integer" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">1234</foo> or > declare the content of foo to be of type xsi:integer in your schema, > and use a library that gives you access to the PSVI (AFAIK Apache's > Xerces should do).
This works, but it sucks, and it sucks because it is a duplication of work and it is tedious to use.
The application that ultimately reads this data necessarily must validate and parse it on its own, simply in the name of defensive programming.
With the Schema/DTD thing, one describes the data content twice: once in the application's implementation, and once in the schema.
The only time I see a use for Schema/DTDs are when one has the standard that is implemented by multiple people/vendors (e.g. an EJB deployment descriptor). In that case though, the grammars are really serving as a formal description on the file content.
-- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, bl...@telus.net The Rhythm has my soul.
Tim Bradshaw wrote: > No, I think the problems of writing non-trivial sets of macros in TeX > (of which LaTeX is just one) are problems of TeX, not LaTeX. I've > done such things (in plain TeX, as well as in LaTeX), and I found it > really much harder work than it needed to be. *Perhaps* it is not > harder work than is inherent in a macro language (or for that matter > things like Unix shells - complex shell scripts are pretty hard to get > right if you want to not have them blow up if you feed them something > unexpected, like strings with spaces in...), but, well, the answer to > that is not to use a macro language. TeX isn't helped any by the > TeXbook, which was clearly written by someone with his head on upside > down.
I loved (and still love) the TeXbook, but then my head is on upside down too. The fact that I encountered it at an impressionable age (16 or so) probably helps, too.
Writing non-trivial things in TeX is difficult for several different reasons. It's all done with macro expansion (and, just as when talking to C people it's necessary to point out that Lisp's macros aren't the ones they're used to, I should maybe mention for the benefit of non-TeXnicians that TeX's macros are possibly even nastier than C's). The whole thing is designed in this amazingly baroque way, where it seems that every time Knuth found something TeX couldn't do he added another random operator that enabled it to do it. \expandafter, for instance. And, even once you're past the pain of the *language*, the fact is that lots of things are just really hard to do in terms of TeX's boxes-and-glue model. (In something like the same way as programming in a more declarative language is hard for people used to programming in imperative languages. But, I think, worse.) And there are those resource problems too, and the way that lots of things are done in terms of magic numbers (which is related to the resource limitation thing but not the same problem).
But, dammit, TeX is still miles ahead of anything else that's remotely as readily available when it comes to typesetting, especially for mathematics.
> No, I don't think it's crap - indeed if you go back in this thread I > posted an article where I said that it's unequalled, in my opinion, > for typing mathematical stuff, both in quality of output, and in ease > of input. I do think that TeX *as a programming language for > typesetting* could be very much better, and not (just) because of > resource issues. I don't particularly want it to be like Lisp, I just > want it to be less painful. In my opinion, the way to do that is by > having the programming language be a different thing than the stuff > you type in, so `macros' would be written in a completely separate > syntax than whatever you type. I'm not even sure that I would change > the look-and-feel of the surface syntax at all: TeX is pleasant enough > to type text and maths into already.
That would be interesting to experiment with.
-- Gareth McCaughan Gareth.McCaug...@pobox.com .sig under construc
* Gareth McCaughan wrote: > I loved (and still love) the TeXbook, but then my head is on > upside down too. The fact that I encountered it at an impressionable > age (16 or so) probably helps, too.
I love it too, actually. Indeed, I bought it before I had access to a copy of TeX, and read it end to end. It's a great book, but it's a *terrible* reference manual. I remember working out that if you wanted to find the useful information on something (rather than a forward reference, or a joke about it, or something which only mentioned it in the most obscure way possible), you should look for the third boldface index entry (or something, I forget the details). That wouldn't work reliably, but it was definitely better than the obvious approach of looking at the first (bold?) entry, or anything like that.
Of course, the mistake CL made is not having a spec that arcane.
Your approach is very similar to what I am working on. I am using a slightly different interpretation of the s-exp, with the symbol representing the element and the attributes together in the first element of the list.
To answer those who mentioned that typing in s-exp is more tedious than entering LaTeX, I agree. Therefore I have a structured-text element which takes formatted text in a syntax similar to that used by the structured text parser in Python (the language) and automatically expands it into markup s-exp. Bulk Paragraphs of text are most easily entered in this way.
Indeed when I take user input (e.g. student written articles) from the website I take it as structured text, with no html tags allowed. The structured text syntax is flexible enough for users to refer to images, crossrefs etc in their articles as well as providing basic formatting and structure and the syntax is expandible to suit the particular application.
Therefore, like Adam, I think we can easily use s-exp as an input language, as an intermediate format for processing and for conversion to output to whatever other formats we want to use (basically html, plain text, or LaTeX to produce pdf).
>>>>> "Adam" == Adam Warner <use...@consulting.net.nz> writes:
Adam> Hi John Williams, >> I would guess I am not the first to attempt this - it might be >> interesting to hear of others experience in relation to using >> s-exp in this way.
Adam> Check out what I've been creating over the last few Adam> months. I finally got my new site up three hours ago: Adam> https://macrology.co.nz/
Adam> I only have one example of the S-expression source available Adam> so far at https://macrology.co.nz/?source (this is the Adam> source that generated the front page and companion PDF).
Adam> Regards, Adam
Adam> Note: I have discovered that MSIE 6.0 rendering doesn't Adam> markup verbatim and quotation correctly. I'm not sure what Adam> the cause is yet but they look fine using Mozilla 1.2.
>> I loved (and still love) the TeXbook, but then my head is on >> upside down too.
>I love it too, actually. Indeed, I bought it before I had access to a >copy of TeX, and read it end to end. It's a great book, but it's a >*terrible* reference manual. I remember working out that if you >wanted to find the useful information on something (rather than a >forward reference, or a joke about it, or something which only >mentioned it in the most obscure way possible), you should look for >the third boldface index entry (or something, I forget the details). >That wouldn't work reliably, but it was definitely better than the >obvious approach of looking at the first (bold?) entry, or anything >like that.
>Of course, the mistake CL made is not having a spec that arcane.
TeX is a domain-specific tool and the domain it addresses is both complicated and has quite a bit of history and (craft) tradition. It is to be expected that a manual for it will be difficult simply based on the subject matter, if the manual stakes any claim at all to comprehensiveness. General-purpose programming languages, on the other hand, are largely about defining and manipulating structures internal to the world that they create and offer, and there is a strongly omphaloskeptic feedback loop to ensure that the structures stay easy and easily described, or at least satisfy some Ockhamesque criterion that makes them elegant to describe cleanly. Thus a CL spec has a better shot at being unarcane than a TeX manual, even when both of them are committed to going into gory detail. (Note, too, that the parts of CL that begin to approach arcaneness have to do with pathnames and Format, which involve interfacing with a messy outside reality.)
That the TeXbook even suggests a comparison, however unfavorable, to a general-purpose programming language spec, is a tribute to how well its author has tamed TeX's domain for the purposes of casual programmability.
* Dorai Sitaram wrote: > TeX is a domain-specific tool and the domain it > addresses is both complicated and has quite a bit of > history and (craft) tradition. It is to be expected > that a manual for it will be difficult simply based on > the subject matter, if the manual stakes any claim at > all to comprehensiveness.
This is rubbish, sorry. The TeXbook, and in particular its index, is (are? am I referring to both?) just gratuitously weird and hard to use. I have read many other books in the area of typography (and computer typesetting), and the TeXbook is by far the least useful. This is not to say it is not a very good read - on the whole it is.
k...@ashi.footprints.net (Kaz Kylheku) writes: > Nothing epitomizes Knuth better than the obtuse instruction set > architecture he designed for the programming examples and exercises in > TAOCP.
many people don't realize TAOCP started in 1962, when he was only twenty four. he was young and inexperienced, even if much brighter than most of his critics...
so what do you think of MMIX? any deep criticism of his newer 64-bit risc architecture you want to share? see eg. mmixware, isbn 3-540-66938-8 in case you want to know more.
ozan s yigit wrote: > k...@ashi.footprints.net (Kaz Kylheku) writes:
>> Nothing epitomizes Knuth better than the obtuse instruction set >> architecture he designed for the programming examples and exercises >> in TAOCP. > so what do you think of MMIX? any deep criticism of his newer 64-bit > risc architecture you want to share? see eg. mmixware, isbn 3-540- > 66938-8 in case you want to know more.
