[[ This is another in a series of delayed items. Delays seem to occur when I REPLY to a message, but doctor the To: and Cc: lines so that individuals are removed and only the w3c-math-erb list remains. If anyone knows why this might cause delays or confuse mailers, please let me know. Meanwhile, delete the duplicate, if and when it arrives. -Ron ]] Bob writes: > One thing that occurred to me when looking at your > recent samples is that "good" TeX authors define macros > for things like vectors, so they have > > \def\Vector#1{{\bf #1}} > > or whatever, so that they can adjust the formatting at any time > for all vectors. We use something similar in an an internal > project and add some type information as well. While I know > you were asking about the final, expanded expressions, what > are the plans to allow macros? The WP does (or will) contain provision for macros. Bruce will be providing some more concrete detail about the capability when he has a chance. MINSE compounds achieve the same. It's true, I was asking about the notation one might employ to indicate font changes within the WP, but I did also want to get at questions such as yours on how best to handle whatever semantical information an author might want to transmit. I see two broad methods of doing this, via macros and via embedded semantical cues. My sense of the difference is roughly macro ----- externally: information about macros (such as precedence, renderings, semantical cues) is kept in a resource table (I think Dave has used the term "knowledge base") indexed by macro names vector -> ... internally: macro names are then used within the document ... and we see that <math>\vector{x}</math> is ... embedded notation ----------------- internally: document instances are accompanied by non-rendering semantical cues ... and we see that <math>&interpretation{vector}&bold;x</math> is ... Bruce has indicated that he thinks both styles (macros and embedded cues) will be supported in the WP, although he thought that ultimately the embedded semantical cues might be handled by element attributes rather than the sort of operator-style notation above. Attribute notation is somewhat different than the operator-precedence style we're using elsewhere, so it seems to me that the style above might be used and parsed into attributes, but that's a detail for further consideration. (Bruce only commented about attributes in terms of how the information would be carried in the expression tree; I don't think he's commented on input form.) MINSE appears to be driven more fundamentally by compounds, and I don't recall any comment from Ping regarding embedded cues. Macros are more efficient and less cluttering when they occur frequently within a document. Modifications to renderings might be easily achieved with well-done macros. I think the primary argument against macros is that some methods of employment can make documents harder for others to read and handle. If, for example, in the instance above one wanted to specify that some vectors come from R^n and some from R^{n+1}, I can imagine wanting to use the embedded notation rather than 2 different macros. (And since the value of n can vary in a paper anyway, listing "the" type of a macro as an element of R^n is a little phony anyway.) Or if this isn't convincing, try to imagine situations where one thinks one has a reasonable encoding in macros, only to find some odd exception inserted after development produces an irregularity and hence a need for either a new macro or a modification of the encoding which appeared neat. This is only an argument which says that embedded cues are good for ad hoc, one-off, or less-regular situations. In some ways, the embedded cues are simply general annotations which one might want, as Bob suggested, for editorial comments. The question then might be whether one considers the cues naturally "mathematical" or "textual", and I think I'd answer "textual". "context" (in the sense of OpenMath) information seems textual, although type-theoretic information might be mathematical (in the sense of involving mathematical notation as in C^{k+1}). (But do you (Bob) foresee employing mathematical notation in type-theoretic information? I know you want the cues to be simple, but something like "vector" alone strikes me as unuseful to a CAS. I realize you didn't claim "vector" as being complete type-theoretic information.) I mention the value of embedded notation partially because I think that macros are beguiling (not to mention wrong when they are used to allow variation in rendering, but fudge their supposed semantical parts, as with the vector example above). The extra vocabulary they introduce and their distance between instance and specification can lead to headaches. The number of papers AMS has received wherein an author has done a truly helpful job to AMS with his/her macros is very small. I think it's valuable to focus on what we want the notation to be and to carry, then specify afterward what macro techniques are allowable. Macros will be useful when standards are followed, but I suspect they'll only be useful to an author when they're out of an author's head. What I'm saying may be no different than what others would say. -RonReceived on Tuesday, 27 August 1996 21:01:59 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 15 April 2023 17:19:57 UTC