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

For 5.24: suggested incompatible changes

Thread Next
From:
Reini Urban
Date:
June 27, 2015 07:53
Subject:
For 5.24: suggested incompatible changes
Message ID:
558E5681.2090602@cpanel.net
For our cpanel internal perl variant we are planning to do the following
**incompatible changes**, which I'd like to see in 5.24
also.

experimental signatures
-----------------------
(should be easy to change, as signatures are experimental after all)

* @_ will be empty in a function with signature

The current signatures implementation is a desaster which needs to be
rewritten, and is experimental anyway. davem's OP_SIGNATURE branch is a
good start, it is just missing call-by-ref, types, named args and esp. a
proper ABI: omit @_ copying, use the values from the stack as with ops
and XS. This is 2x faster than the current call without signatures and
4x faster than zefram's implementation.
maybe even throw a warning on @_,$_[] in such bodies, but we don't do
that yet.

* parse types in signatures

that's a 6 line patch. currently I'm forced to use attributes for this
for backwards compat. This has it's own huge problems, but looks more
like in other gradually typed languages.
But using the perl6 syntax should be preferred here.

* no experimental::signatures

esp. parse prototypes and signatures from (...) without this
experimental pragma, there are no conflicts.

the illegalproto warning needs to go away then. an illegalproto is a
signature, and there can only be a signature parser error then.

* no empty bare $ signature

this clashes with prototypes, and is horrible backwards design which
should not be encouraged.

* automatic prototypes from signatures

when parsing a signature and no :prototype() attr is found, fill the
prototype with the information from the signature.


PERLIO_DEBUG only with DEBUGGING, use for all -D*
-------------------------------------------------

PerlIO_debug() is currently called even without DEBUGGING, making perlio
slower than it needs to be.

* our changes wrap PerlIO_debug into a new DEBUG_I(),
thus enable PERLIO_DEBUG only with DEBUGGING, and we use the debugio_fh
for all DEBUG_* macros. so we can seperate -D* tracing from STDERR.

the name can stay the same, as PERLIO_DEBUG=filename is already
established, and letting -D* write into this handle seems natural to us.

constant fold functions even without ()
--------------------------------------

* currently function bodies are only folded to a single expression when
the empty () prototype is present. nobody does this and it looks odd.
we allow constant folding of constant expressions even without the ()
prototype. we had this discussion a decade ago also.
there are a few failures in t/op/cproto.t which are bad tests.

* for the existing cv case, when a newCONSTSUB cannot be used, a dummy
XS sub instead (with the const_sv in the anyptr), the default prototype
for :method subs needs to be "$" then, not just "". This is arguably
just a bug.

Notes:
functions need to be inlined on more than just constant expressions.
simple expressions (like most non-constant one line methods) can easily
be spliced into the caller.

currently the use of attributes which are not parsed in toke but in
attributes forbid constant folding also. we did not change that.
Thus we had to add all our perl6 compatible function attributes (:pure,
:const, return types) to the lexer. But these are our new core
attributes anyway.
user-attributes still forbid constant folding of functions. this should
be documented.

we enable :const for all data, CV, SV, AV, HV, so we get constant
lexicals and much more to constant fold here and there.
those pad ops are converted to const ops.

I have a merge-upstream branch on github with some of those patches, the
enhanced signatures not.

Just for consideration:
-----------------------
I saw you were asking for ideas for more strictures without considering
the technical limitations.

I can add that I freed 2 stricture bits in $^H which we plan to use for
the following two new features:

  no magic;
  use strict 'names';

* no magic is also done with types, but some blocks would benefit from
our new type framework even without typed lexicals, esp. with inferred
types.
so no magic is our top priority.
you can see the benchmarks in my old 2012 compiler benchmark blog posts
and I also presented it at YAPC Kiev.

* use strict 'names' is to protect from no strict 'refs' abuse on
untrusted strings, to apply the parsing rules to such converted names.

the other security cases of TR-39, confusables, need to be solved with a
new file scoped pragma. This does not need to be lexical.

-- 
Reini

Working towards a true Modern Perl.
Slim, functional, unbloated, compile-time optimizable

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About