Pawel Jackowski wrote:
I'm bound to tell the reason the 'dream about options' was issued for; ok, not *common* but *live* example. I'm working on low-level pdfTeX macros for generating unusual PDFs files for prepress software testing (uncommon colorspaces, graphic states, horror tiling patterns and others). The word 'unusual' means that the macros must be pretty flexible, not just provide high-end interface. Deeper I'm diggig, more clearly I see that primitive option-scanning mechanism is necessary for playing with object-oriented format in its whole generality. And the only way I see to make definition-oriented TeX more option-oriented are keywords.
hm, all that can be done with macros; also, my guess is that a hard coded keyword system will not satisfy everyone since demands differ, ans so we end up with a lot of extra code not used by many; what i remember from etex discussions is that the demands were too different and getting insight as well as agreement over what tex should provide is pretty hard. So, simple features on top of which one can build interfaces is the way to go. In the end you need to store options in macros (variables) anyway, so parsing and low level interfaces remain separated things. also, with respect to pdf features, it's not so much a big deal to support them, but given that the pdf ref manual is over 1000, any interface to features will end up in a configuration mess (many options, keywords, wierd side tracks, etc); don't let your dream end up in a nightmare: tex is a macro language; the fact that pdftex has primitives with keywords has an historic origin; it could as well have been something: \pdfannotwidth=.. \pdfannotheight=.. \pdfannot... \pdfannot {text} (if you look at how more complex packages for scripting languages are made, you'll notice that as soon as many parameters show up, hashes are used if only because they can be moved around comfortably) Hans