On Thu, Sep 13, 2001 at 08:44:44AM +0100, Simon Cozens wrote:
> Aiiee. Yes, I appreciate what you're saying, but the other lessons
> from Perl 5 is that if you want to do that, you end up with either
> lots of unweildy code, or a nasty macro renaming. Which is it
> gonna be?
I don't really like the Perl 5 approach of lots of macros. I'd
rather have a short prefix attached to all symbols. par_foo()
rather than foo() in all cases. For very commonly used macros (the
equivalent of PUSHi()), you might relax this rule.
Look at the current source: Is it really going to be any harder to
always type par_string_length() rather than string_length(), or
Par_Allocate_Aligned() rather than Allocate_Aligned()? The symbol
names are long enough to begin with that an extra four characters
isn't going to make much difference.
Even a single character would do a lot to eliminate symbol clashes:
Pstring_length() and PAllocate_Aligned(), for example.
(Speaking of the above, someone authoritative may want to dictate
whether functions are Upper_Case or lower_case.)
Talking just about the opcode functions, however: Will code be
calling opcode functions directly very often? Perhaps I'm wrong,
but I'd think that ops being called outside the runops() loop will
be rare. In fact, if ops can be embedded into a switch statement
in runops() at compile time, there won't even be any assurance that
there ARE any op functions to call. Unwieldy op function names
shouldn't be a problem.
- Damien
