develooper Front page | perl.perl5.porters | Postings from February 2015


Thread Previous | Thread Next
February 24, 2015 16:05
Message ID:
(Note on my participation in p5p: following my depression-induced
withdrawal from the world last year, I'm still not routinely reading mail
again.  I'm reading some specific sources of mail, not including p5p,
nor including messages addressed directly to me.  I also occasionally
peruse general mail, so by chance may see something on p5p, and that is
the manner by which I have discovered this thread.)

Dave Mitchell wrote:
>The branch smoke-me/davem/op_signature, currently being smoked, adds
>a new op, OP_SIGNATURE to the core. The principal purpose of this
>op is to handle (most of) the work of assigning args to params on
>signature subs (e.g. sub foo ($a, $b, $c = 1) {...}).

While I like the performance win, I dislike this op type being so closely
tied to signatures.  Specifically, I dislike (a) that its behaviour
is very specific and a priori arbitrary, being precisely tailored to
what signatures do; (b) that it relies on only being called at the
very beginning of a sub; (c) that it is only generated by syntactic
signature parsing (and the non-default "my(...)=@_" special case); (d)
that the patch makes syntactic signature parsing reliant on this special
op; and (e) that deparsing signature syntax is tied to the special op.
On the whole it's violating the principle that syntactic signatures are
only *syntax*, and should not be semantically special.

Having signature parsing rely on generating only an OP_SIGNATURE causes
two obvious problems.  Firstly, it is likely to complicate whatever
plugin interface eventually gets added to signatures (to allow modules
to supply new kinds of item that can appear in a signature).  Secondly,
a limitation of the op implementation, on the number of parameters that
it can handle, translates into an inability of the signature parser to
handle more parameters, rather than merely limiting which signatures
get the full speed boost.

What I'd like to see is op types that have much wider applicability,
can be used in many circumstances, and are generated automatically (and
unconditionally) by the checkers of existing ordinary op types and by
the peephole optimiser.  The signature parser should continue to generate
the many ops that it currently does, blissfully unaware that the checkers
are collapsing some of the structures to optimised single ops as it goes.

For example, the op sequence corresponding to "@_ >= N+1 ? $_[N] :" is
frequently generated by signature code, and could be collapsed into a
single op (with the default-value op tree as a child) by newCONDOP().
This would benefit not just signatures but also anything else that
processes a subroutine argument in the same manner.  Collapsing a sequence
of argument assignments into one padrange-like op could be done by the
peephole optimiser.

The decision to deparse using signature syntax should be based on whether
the signature feature is lexically enabled at that point in the output
and the -x level, rather than purely on the op type.  The deparser on
your branch relies, for correct output, on the presence of a signature
op always matching up with whether the deparser has lexically enabled
signatures in its output, but I believe it will still actually be too late
in emitting the "use feature 'signatures';" line.  It's also incorrect
to tie the change in prototype syntax (short syntax vs attribute) to the
use of signature syntax: that too should be tied to whether the signature
feature has been enabled, because it is that feature flag that disables
the short prototype syntax.  (Mind you, the existing deparser *always*
uses short prototype syntax, so is also faulty.)

The CvHASSIG flag is a bad idea: it's exposing an internal implementation
detail, which has no legitimate uses as sub metadata, and when it's made
this easy there are going to be people who will misuse it.  The sub's
behaviour, including that derived from the signature, is already
adequately represented as the op tree.

The signature op is also not sufficiently internal for compatibility
concerns to be ignored.  Its addition means that code walkers need to
understand it, and non-core modules will have the option to generate it.
We shouldn't impose the former requirement without being satisfied that
we're going to stick with the signature op in pretty much this form.
We shouldn't offer the latter feature without either such satisfaction
or an "experimental" notice.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About