> This made my mind up: I do not think we should reinvent the wheel here.

This was just following up what Stefan seemed interested in.  It was just
an alternative to using the far simpler use case of DEFINED which was
merely if not DEFINED(foo) and bears little relation to C++ templates.
You do seem to understand that from below, but I wanted to mention it
more explicitly.

> Rather than focusing on improving the DEF, IF and include statements, we
> should look for an existing macro language for our uses (and rather
> deprecate DEF, IF and include than make them more powerful).
> [..]
> C has a clear seperation between the language and the preprocessor, with
> great success.

That's fine if someone actually does the integration work of running it from
the tool chain.  Keeping the Cython compiler about more typed files rather
than include-like generic file combination and about typed values/names
rather than token pasting is probably wise separation of concerns.  That
being said, until there is some drop-in replacement for DEF/IF/include,
why not round out the triplet with DEFINED as any replacement will likely
have that sort of feature?  Seems like a practical answer until you have
some more fully functional textual manipulation system integrated.  And
Pyrex has DEF/IF/include as well, so you may be stuck with at least only
deprecating them/providing them via a different mechanism unless Greg
shares your separation biases.  He seemed to have trouble getting rid of
for "from" and I suspect "include" would share this trait.

> (Still, anything which is already implemented is, well, already implemented
> and "free" in some sense.).

It's pretty simple and less work than this e-mail chain and decidedly
less work than any toolchain integration working on Unix, Windows, etc.

Best,
cb
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to