Pawel Jackowski wrote:

Hi Hans!

thanks for response.

...

...

Hello,

I suppose the issue was discussed before but couldn't find that is archives.

Making high level macros in (pure) TeX encounters problem of optionality[...]

...

in the previosu century taco made some extensiong dealing with key/val parsing (and other kinds of parsing); at that time we did quite some testing with speed issues, and the price to pay was higher that the gain; keep in mind that in tex catcodes and expansion always kind of interfere in such things;

Indeed, to keep things consistent, parameter text should always be expanded before being swallowed by \macro... Anyway, pdfTeX handles that somehow, supporting both expansion and catcoding.

parsing keys as in \hrule ... is kind of special anyway: one can overload (repeat specs) but not all of them are treated the same; fuzzy optimizations and such; so there is not much reusable code there

...

ok, if you limit key/val parsing to 'strings' only (i.e. no expansion, no catcode support) then it can be faster, but at the same time it also becomes useless for everyday usage; as with more tex things, because tex is rather optimized, hard coded alternatives (extensions to the language) not always pay off; also consider implementation issues like namespacing, scope of keys, etc

...and parameters handling rules in such an extention would probably be faaaar away from TeX. But if tries has been made in previous century, meybe it's high time to repeat tests? In the previous century features such as decompressing/recompressing PNG in runtime didn't pay off either. If you don't consider it doable, I will reopen the request in the next century. -)

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); on the other hand, the bigger memory makes it possible to be a bit more spending that in the past, i.e. write less fuzzy code (much tex code is fuzzy because of speed and mem issues); btw, one reason for context being 'slow' was that it had all this key value etc stuff and used quite some hash and mem; recently there was a report of on the tex live list who mentioned latex being much slower than in the past and tacos answer to that was that it's not related to slower pdftex or so since context had not become slower: it was just that bigger (la)tex's take more time to initialize, etc etc and all packages become bigger; if you want to speed up macro packages think of what happens in there: even in a parameter driven package like context, the amount of expanded code (tracingall) with regards to k/v handling is small compared to messing around with boxes (esp when \copy is used) and saving/restoring as well as redundant passing around arguments (the #1 things) another think to keep in mind: when discussing things like reimplementing tex, one can be tricked into thinking that there should be fast methods for char handling, hyphenation, etc etc (i.e. influences design of for instance classes in oo like aproaches); however, in more modern macro package features, tex spends much time in manipulating boxes (lists) in the otr and it could be that modern programming languages provide features that would make such critical operations faster; so, the gain is in other areas (take pdftex: pdf inclusion is incredibly fast, simply because that piece is written in a different language/way); compare it to scripting languages: they excel in handling text simply because they're made with that in mind. Hans

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

On 2005-11-14 23:36:32 +0100, Hans Hagen wrote:

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);

I'm still dreaming about pdf dictionary handling in pdfTeX; this could also be used to handle kv-pairs. Best Martin -- http://www.tm.oneiros.de

On Tue, 15 Nov 2005, Hans Hagen wrote:

Martin wrote:

...

On 2005-11-14 23:36:32 +0100, Hans Hagen wrote:

...

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);

I'm still dreaming about pdf dictionary handling in pdfTeX; this could also be used to handle kv-pairs.

you mean access to dictionaries (involving parsing) ?

xpdf obviously has these features under the hood, accessible by pdftex. Problem is to get xpdf parsing a string instead of a file. Bernd Raichle told me a few months ago that C++ "string-streams" can be used in principle to feed a string into the parser like a file. But i didn't try it yet, have not much, if any, C++ experience. Regards, Hartmut