[NTG-pdftex] a dream about options

[Pawel Jackowski]

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:
>     
>     http://tex.aanhet.net/eetex/

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 at gust.org.pl