Thank you guys for comments. Hans:
sure, but there 'new methods' pop up and or constraints disappear (mem); tex is really optimized (i did lots of timing and many low level context commands and k/v handling are optimized to the max)[...]
Ye, admit I'm optimization freak and whenever trying to speed-up something I realise that the gain is really inconsiderable comparing with assignments, box-list handling, the time needed to read/write image/fonts data and others. Taco:
Using macros is somewhat less efficient than doing the same stuff in compiled code, but the gain is not very big, because most of the TeX commands that are executed have to be executed anyway (parsing argument texts, defining \csnames for the options).
Anyway, if you want to have a look at what I did, the code is still on-line:
Thanks for the link. I like the idea very much, especially lists handling. \sgmlmode is also a jewel by the way.
I've learned to dislike the scan_keyword() stuff. It is a nightmare to fake these primitives in macros, and it is hard to jump over them in the output of \the.
I see, so that is the price...
The thing is: it shouldn't be hard to implement such a feature, *assuming* there was a clear functional specification. But ...
As all eTeX features, eeTeX primitives seems not providing things not doable (somehow) at all in pure TeX, but make things much smooooother. I agree that making user allowed to define macros executed with optional keywords \fruit type {orange} diameter=8cm just to get a sentence An orange is a fruit of $8cm$ in diameter. is not enough argument to make such a big change in TeX. But if we go deep into document (especially PDF document!) engineering a lack of such possibility becomes painful. These are *keywords* that make \pdfximage usable in advanced applications. These are *keywords* that make \pdfobj usable at all! If there are two properties of the \fruit, things are trivial, if there are 10 of them, we need to provide additional (probably namespace-wise) commands for fruit properties. In \fruit[key=val,...] convention we make the same silently (and we lose a chance to make \fruit expandable btw). 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. All the best, -- Pawe/l Jackowski P.Jackowski@gust.org.pl