From @andk

git bisect

commit 38be3d0
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Sun Aug 4 11​:22​:03 2013 -0700

  Don’t let list const modification affect future retvals

diagnostics

http​://www.cpantesters.org/cpan/report/60ca6d08-fe27-11e2-9875-5209f2ff63fb

Also affected​: DANKOGAI/Data-Lock-1.02.tar.gz as in

http​://www.cpantesters.org/cpan/report/1d45d002-fe1a-11e2-b08a-12aaf1ff63fb

perl -V

Summary of my perl5 (revision 5 version 19 subversion 3) configuration​:
  Commit id​: 38be3d0
  Platform​:
  osname=linux, osvers=3.9-1-amd64, archname=x86_64-linux-ld
  uname='linux k83 3.9-1-amd64 #1 smp debian 3.9.8-1 x86_64 gnulinux '
  config_args='-Dprefix=/home/sand/src/perl/repoperls/installed-perls/perl/v5.19.2-276-g38be3d0/127e -Dmyhostname=k83 -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Uuseithreads -Duselongdouble -DDEBUGGING=-g'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=undef, usemultiplicity=undef
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=define, use64bitall=define, uselongdouble=define
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O2 -g',
  cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.8.1', gccosandvers=''
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t', lseeksize=8
  alignbytes=16, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
  libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
  perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
  libc=, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version='2.17'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl)​:
  Compile-time options​: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV
  PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_MALLOC_WRAP
  PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV
  PERL_USE_DEVEL USE_64_BIT_ALL USE_64_BIT_INT
  USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE
  USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LONG_DOUBLE
  USE_PERLIO USE_PERL_ATOF
  Built under linux
  Compiled at Aug 7 2013 05​:17​:32
  @​INC​:
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.2-276-g38be3d0/127e/lib/site_perl/5.19.3/x86_64-linux-ld
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.2-276-g38be3d0/127e/lib/site_perl/5.19.3
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.2-276-g38be3d0/127e/lib/5.19.3/x86_64-linux-ld
  /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.2-276-g38be3d0/127e/lib/5.19.3
  .

--
andreas

From @cpansprout

On Tue Aug 06 20​:42​:33 2013, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

git bisect
----------
commit 38be3d0
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Sun Aug 4 11​:22​:03 2013 -0700

Don’t let list const modification affect future retvals

diagnostics
-----------
http​://www.cpantesters.org/cpan/report/60ca6d08-fe27-11e2-9875-
5209f2ff63fb

Also affected​: DANKOGAI/Data-Lock-1.02.tar.gz as in

http​://www.cpantesters.org/cpan/report/1d45d002-fe1a-11e2-b08a-
12aaf1ff63fb

Oh no!

These two modules are using Internals​:: functions, so it is officially
‘their fault’.

To work around this, I would have to add *more* Internals​:: functions
for constant.pm to use. I hope I don’t have to do that.

--

Father Chrysostomos

The RT System itself - Status changed from 'new' to 'open'

From @Leont

On Wed, Aug 7, 2013 at 9​:53 AM, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

Oh no!

These two modules are using Internals​:: functions, so it is officially
‘their fault’.

If you ask me, some function to make stuff readonly should have been
made API somewhere a long time ago. Same goes for getting the refcount
I suppose (setting it is pure insanity).

Leon

From @ap

* Leon Timmermans <fawaka@​gmail.com> [2013-08-21 13​:00]​:

If you ask me, some function to make stuff readonly should have been
made API somewhere a long time ago. Same goes for getting the refcount
I suppose (setting it is pure insanity).

It’s easy enough to set it… so long as you aren’t trying to decrease it
anyway. ;-)

From @cpansprout

On Wed Aug 21 03​:56​:31 2013, LeonT wrote​:

On Wed, Aug 7, 2013 at 9​:53 AM, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

Oh no!

These two modules are using Internals​:: functions, so it is officially
‘their fault’.

If you ask me, some function to make stuff readonly should have been
made API somewhere

Suggestions?

a long time ago. Same goes for getting the refcount
I suppose (setting it is pure insanity).

You can use B for that.

--

Father Chrysostomos

From @demerphq

On 21 August 2013 17​:21, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

On Wed Aug 21 03​:56​:31 2013, LeonT wrote​:

On Wed, Aug 7, 2013 at 9​:53 AM, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

Oh no!

These two modules are using Internals​:: functions, so it is officially
‘their fault’.

If you ask me, some function to make stuff readonly should have been
made API somewhere

Suggestions?

Mauve. :-)

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

From @Leont

On Wed, Aug 21, 2013 at 5​:21 PM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

Suggestions?

Scalar​::Util comes to mind, even if it can be used on non-scalars.

You can use B for that.

I don't think that's really better than using Internals​::

Leon

From @nwc10

On Thu, Aug 22, 2013 at 12​:57​:22PM +0200, Leon Timmermans wrote​:

On Wed, Aug 21, 2013 at 5​:21 PM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

Suggestions?

Scalar​::Util comes to mind, even if it can be used on non-scalars.

Possibly there ought to be a restriction to using it only on scalars.

Setting the "read only" flag can mean different things on the other types.
It's (currently) used to mark restricted hashes, which aren't exactly
read-only.

av.c suggests that arrays honour it, at least partially. Note, I don't
trust arrays flagged READONLY to actually be immutable (given the
contortions of the source) but I haven't actually found an exception. Yet.

Also, Scalar​::Util already has a readonly() function to read it, but I'm
not sure what "it" is. In that, part of the frustration is that the flag
bit SVf_READONLY means a whole bunch of things, which might not always have
the semantics of "read only" that the programmer thought. It's not well
defined. Or at least, not well specified.

You can use B for that.

I don't think that's really better than using Internals​::

Devel​::Peek​::SvREFCNT

Nicholas Clark

From @cpansprout

On Thu Aug 22 04​:14​:44 2013, nicholas wrote​:

On Thu, Aug 22, 2013 at 12​:57​:22PM +0200, Leon Timmermans wrote​:

On Wed, Aug 21, 2013 at 5​:21 PM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

Suggestions?

Scalar​::Util comes to mind, even if it can be used on non-scalars.

Possibly there ought to be a restriction to using it only on scalars.

That wouldn’t help Const​::Fast, as the failures are precisely due to a
change in the way SvREADONLY(@​a,1) works, for the sake of constant.pm.

Setting the "read only" flag can mean different things on the other types.
It's (currently) used to mark restricted hashes, which aren't exactly
read-only.

av.c suggests that arrays honour it, at least partially. Note, I don't
trust arrays flagged READONLY to actually be immutable (given the
contortions of the source) but I haven't actually found an exception. Yet.

Also, Scalar​::Util already has a readonly() function to read it, but I'm
not sure what "it" is. In that, part of the frustration is that the flag
bit SVf_READONLY means a whole bunch of things, which might not always
have
the semantics of "read only" that the programmer thought. It's not well
defined. Or at least, not well specified.

Yeah, this whole area is a case in which people poke at the internals,
see what happens, go ‘Oh, neat!’, and then start writing tests and
depending on transient behaviour.

Until recently, perl would merrily modify read-only scalars at compile
time, so the read-only flag has not offered any real protection.

--

Father Chrysostomos

From @ap

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2013-08-22 17​:40]​:

On Thu Aug 22 04​:14​:44 2013, nicholas wrote​:

On Thu, Aug 22, 2013 at 12​:57​:22PM +0200, Leon Timmermans wrote​:

Scalar​::Util comes to mind, even if it can be used on non-scalars.

Possibly there ought to be a restriction to using it only on
scalars.

That wouldn’t help Const​::Fast, as the failures are precisely due to
a change in the way SvREADONLY(@​a,1) works, for the sake of
constant.pm.

I don’t think that changes Nicholas’ point, not at all really.

If that is what Const​::Fast requires then there needs to be a function
in… well unfortunately we have no corresponding Array​::Util, but maybe
it is time for such.

Because…

Yeah, this whole area is a case in which people poke at the internals,
see what happens, go ‘Oh, neat!’, and then start writing tests and
depending on transient behaviour.

… the only hope of ever getting out from under that mess is by offering
API based on semantics, not implementation, i.e. these functions should
be documented not as “sets the read-only flag” but as “makes the scalar
read-only”, and then likewise “makes the hash restricted” etc, and they
should do everything it takes to achieve whatever the docs say they do.

The point is that each such function should be named and documented
after the end it achieves, not the means it uses to provide it, which
should be of no concern or business to its user. Only that way will
there ever be any hope of reducing the level of intimacy of CPAN with
perl’s insides to some appropriate level.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

From @cpansprout

On Wed Aug 21 11​:00​:59 2013, demerphq wrote​:

On 21 August 2013 17​:21, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

On Wed Aug 21 03​:56​:31 2013, LeonT wrote​:

On Wed, Aug 7, 2013 at 9​:53 AM, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

Oh no!

These two modules are using Internals​:: functions, so it is
officially
‘their fault’.

If you ask me, some function to make stuff readonly should have been
made API somewhere

Suggestions?

Mauve. :-)

OK, let’s use this as an opportunity to discuss it. Where was the last
thread on this (the one in which you complained about my cryptic response)?

--

Father Chrysostomos

From @tonycoz

On Sat, Aug 24, 2013 at 07​:16​:13PM -0700, Father Chrysostomos via RT wrote​:

On Wed Aug 21 11​:00​:59 2013, demerphq wrote​:

On 21 August 2013 17​:21, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

On Wed Aug 21 03​:56​:31 2013, LeonT wrote​:

On Wed, Aug 7, 2013 at 9​:53 AM, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

Oh no!

These two modules are using Internals​:: functions, so it is
officially
‘their fault’.

If you ask me, some function to make stuff readonly should have been
made API somewhere

Suggestions?

Mauve. :-)

OK, let’s use this as an opportunity to discuss it. Where was the last
thread on this (the one in which you complained about my cryptic response)?

mauve was a placeholder namespace to expose documented internals.

On perl's which didn't expose those internals they could be
implemented as XS or pure perl, and so would be available on any perl
as​:

  use mauve qw(reftype);

which would use the internal or XS/PP implementation depending on what
was available.

This would allow us to expose functions which probably should be
exposed (like reftype perhaps) without cluttering the operator or
global namespace, and possibly allow for some optimizations
(eg. replacing the call with an operator.)

Unfortunately it turned into an annoying bikeshed over the name, which
AFAIK was never intended to be the final name, so it was dropped.

Tony

From @ap

* Tony Cook <tony@​develop-help.com> [2013-08-26 01​:45]​:

mauve was a placeholder namespace to expose documented internals.

On perl's which didn't expose those internals they could be
implemented as XS or pure perl, and so would be available on any perl
as​:

use mauve qw(reftype);

which would use the internal or XS/PP implementation depending on what
was available.

This would allow us to expose functions which probably should be
exposed (like reftype perhaps) without cluttering the operator or
global namespace, and possibly allow for some optimizations (eg.
replacing the call with an operator.)

Unfortunately it turned into an annoying bikeshed over the name, which
AFAIK was never intended to be the final name, so it was dropped.

It wasn’t the name alone, but yeah.

I think that describes the point of mauve poorly, though. The idea was
to provide core implementations of a number of functions mainly from
Scalar​::Util, which would not require loading a module (and since this
was a clean break these functions could also fix the niggly API design
problems of the Scalar​::Util functions), which Scalar​::Util would then
become a wrapper around (providing the old worse interface) where mauve
was available.

Yves had the first inkling here​:
http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTi=TCR8z+miH8T4j4Jzwq5ZmKh1mVSEuEbtQrSBE@​mail.gmail.com

He started the fire​:
http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTikHi8jbTshovEMQvdkROx8_JkrksaiqLpNDSDbB@​mail.gmail.com

Unfortunately then-pumpking RGS didn’t like it at all​:
http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTi=UHJ-1VMdZnh_KUrB=CTuageTErBGR1o728rGY@​mail.gmail.com

So it went into quarantine​:
http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=871v8twxr8.fsf@​tardis.home.perldition.org

And ended up being something people merely pined for…
http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=20110427071804.GC6609@​puppy
http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=CAOeq1c_Y=s6XeeP9TndE7RMqpcE60Yrinu5yzGO2YZ+DShfGCg@​mail.gmail.com

Someday…

--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

From @cpansprout

On Sun Aug 25 19​:44​:08 2013, aristotle wrote​:

* Tony Cook <tony@​develop-help.com> [2013-08-26 01​:45]​:

mauve was a placeholder namespace to expose documented internals.

On perl's which didn't expose those internals they could be
implemented as XS or pure perl, and so would be available on any
perl
as​:

use mauve qw(reftype);

which would use the internal or XS/PP implementation depending on
what
was available.

This would allow us to expose functions which probably should be
exposed (like reftype perhaps) without cluttering the operator or
global namespace, and possibly allow for some optimizations (eg.
replacing the call with an operator.)

Unfortunately it turned into an annoying bikeshed over the name,
which
AFAIK was never intended to be the final name, so it was dropped.

It wasn’t the name alone, but yeah.

I think that describes the point of mauve poorly, though. The idea was
to provide core implementations of a number of functions mainly from
Scalar​::Util, which would not require loading a module (and since this
was a clean break these functions could also fix the niggly API design
problems of the Scalar​::Util functions), which Scalar​::Util would then
become a wrapper around (providing the old worse interface) where
mauve
was available.

Yves had the first inkling here​:

http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTi=TCR8z+miH8T4j4Jzwq5ZmKh1mVSEuEbtQrSBE@​mail.gmail.com

He started the fire​:

http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTikHi8jbTshovEMQvdkROx8_JkrksaiqLpNDSDbB@​mail.gmail.com

Unfortunately then-pumpking RGS didn’t like it at all​:
http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTi=UHJ-
1VMdZnh_KUrB=CTuageTErBGR1o728rGY@​mail.gmail.com

So it went into quarantine​:

http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=871v8twxr8.fsf@​tardis.home.perldition.org

And ended up being something people merely pined for…

http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=20110427071804.GC6609@​puppy

http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=CAOeq1c_Y=s6XeeP9TndE7RMqpcE60Yrinu5yzGO2YZ+DShfGCg@​mail.gmail.com

Someday…

There was another thread last year on the topic, not just touching on
it. Ah, here it is​:

http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=CANgJU+VaLN6oitD5JJ91QiYO4fjkn9n4X3YrBV_WYKkfrygm_Q@​mail.gmail.com

--

Father Chrysostomos

From @xdg

On Wed, Aug 7, 2013 at 3​:53 AM, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

Oh no!

These two modules are using Internals​:: functions, so it is officially
‘their fault’.

To work around this, I would have to add *more* Internals​:: functions
for constant.pm to use. I hope I don’t have to do that.

I don't think constant.pm should have any priviledged status with
respect to Internals. If it can use Internals, then Internals is not
really Internal.

I agree with Aristotle when he said this​:

… the only hope of ever getting out from under that mess is by offering
API based on semantics, not implementation, i.e. these functions should
be documented not as “sets the read-only flag” but as “makes the scalar
read-only”, and then likewise “makes the hash restricted” etc, and they
should do everything it takes to achieve whatever the docs say they do.

The point is that each such function should be named and documented
after the end it achieves, not the means it uses to provide it, which
should be of no concern or business to its user. Only that way will
there ever be any hope of reducing the level of intimacy of CPAN with
perl’s insides to some appropriate level.

Frankly, I'd be pretty happen to have a "set_readonly" added to
Scalar​::Util (or mauve). 99% of the time I want a read-only it's a
scalar, anyway. If the semantics don't work well for arrays and
hashes, then let's not bother.

David

--
David Golden <xdg@​xdg.me>
Take back your inbox! → http​://www.bunchmail.com/
Twitter/IRC​: @​xdg

From @Leont

On Fri, Sep 20, 2013 at 10​:01 PM, David Golden <xdg@​xdg.me> wrote​:

On Wed, Aug 7, 2013 at 3​:53 AM, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

Oh no!

These two modules are using Internals​:: functions, so it is officially
‘their fault’.

To work around this, I would have to add *more* Internals​:: functions
for constant.pm to use. I hope I don’t have to do that.

I don't think constant.pm should have any priviledged status with
respect to Internals. If it can use Internals, then Internals is not
really Internal.

Yes, this.

If the semantics broke because internal reason that's one thing, but
breaking it because it's convenient in another module seems a bit unfair.

Leon

From @cpansprout

On Fri Sep 20 13​:02​:59 2013, xdg@​xdg.me wrote​:

On Wed, Aug 7, 2013 at 3​:53 AM, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

Oh no!

These two modules are using Internals​:: functions, so it is officially
‘their fault’.

To work around this, I would have to add *more* Internals​:: functions
for constant.pm to use. I hope I don’t have to do that.

I don't think constant.pm should have any priviledged status with
respect to Internals. If it can use Internals, then Internals is not
really Internal.

constant.pm is already special though, in that it uses (and depends on)
undocumented use of stash manipulation.

I agree with Aristotle when he said this​:

… the only hope of ever getting out from under that mess is by offering
API based on semantics, not implementation, i.e. these functions should
be documented not as “sets the read-only flag” but as “makes the scalar
read-only”, and then likewise “makes the hash restricted” etc, and they
should do everything it takes to achieve whatever the docs say they do.

The point is that each such function should be named and documented
after the end it achieves, not the means it uses to provide it, which
should be of no concern or business to its user. Only that way will
there ever be any hope of reducing the level of intimacy of CPAN with
perl’s insides to some appropriate level.

Frankly, I'd be pretty happen to have a "set_readonly" added to
Scalar​::Util (or mauve). 99% of the time I want a read-only it's a
scalar, anyway.

I have been thinking about this for a while. Since making something
read-only is not a common task (like blessed or refaddr), it probably
does not belong in libperl, prior art notwithstanding. Scalar​::Util is
a good place for it. I would call it make_readonly.

(But I do want to get mauve resolved for 5.20. I’ve been mentally
drafting a response to
<CANgJU+Vb=36TMZcqU7Ti70GV_=jUL86EhfZFFhcZKAFLy+3onQ@​mail.gmail.com>,
but it hasn’t materialised yet.)

If the semantics don't work well for arrays and
hashes, then let's not bother.

It’s precisely the array case that is now broken for Const​::Fast.

Someone suggested adding Array​::Util, like Hash​::Util. That may be the
correct approach.

On the other hand, we could cheat and allow Scalar​::Util​::make_readonly
to take an array.

I think I prefer the former, but I’m ambivalent.

--

Father Chrysostomos

From @andk

"Leon Timmermans via RT" <perlbug-followup@​perl.org> writes​:

If the semantics broke because internal reason that's one thing, but
breaking it because it's convenient in another module seems a bit
unfair.

I'm tempted to throw an ESTALLEDTOOLONG in, especially given that there
are 33 reverse dependencies [0] untested with blead since August 7.

--
andreas
[0] https://metacpan.org/requires/distribution/Const-Fast

From perl5-porters@perl.org

Andreas Koenig wrote​:

"Leon Timmermans via RT" <perlbug-followup@​perl.org> writes​:

If the semantics broke because internal reason that's one thing, but
breaking it because it's convenient in another module seems a bit
unfair.

Oddly, nobody complained when I broke autobox for the sake of
strict.pm.

I'm tempted to throw an ESTALLEDTOOLONG in, especially given that there
are 33 reverse dependencies [0] untested with blead since August 7.

But what does ESTALLEDTOOLONG mean?

The problem here is that nobody has commented on my proposed solu-
tions. I have a third solution up my sleeve that I plan to imple-
ment if nothing else. It may be controversial, but it will not step
on anybody's toes.

From @andk

Father Chrysostomos <sprout@​cpan.org> writes​:

I'm tempted to throw an ESTALLEDTOOLONG in, especially given that there
are 33 reverse dependencies [0] untested with blead since August 7.

But what does ESTALLEDTOOLONG mean?

Sorry, I just felt like making up a funny sounding term. Probably best
translation being Ping.

--
andreas

From @Leont

On Sun, Dec 22, 2013 at 2​:38 PM, Andreas Koenig <
andreas.koenig.7os6VVqR@​franz.ak.mind.de> wrote​:

"Leon Timmermans via RT" <perlbug-followup@​perl.org> writes​:

If the semantics broke because internal reason that's one thing, but
breaking it because it's convenient in another module seems a bit
unfair.

I'm tempted to throw an ESTALLEDTOOLONG in, especially given that there
are 33 reverse dependencies [0] untested with blead since August 7.

This is not stalled on technical grounds, but on a lack of decision.

Leon

From @demerphq

On 26 August 2013 01​:43, Tony Cook <tony@​develop-help.com> wrote​:

On Sat, Aug 24, 2013 at 07​:16​:13PM -0700, Father Chrysostomos via RT wrote​:

On Wed Aug 21 11​:00​:59 2013, demerphq wrote​:

On 21 August 2013 17​:21, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

On Wed Aug 21 03​:56​:31 2013, LeonT wrote​:

On Wed, Aug 7, 2013 at 9​:53 AM, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

Oh no!

These two modules are using Internals​:: functions, so it is
officially
‘their fault’.

If you ask me, some function to make stuff readonly should have been
made API somewhere

Suggestions?

Mauve. :-)

OK, let’s use this as an opportunity to discuss it. Where was the last
thread on this (the one in which you complained about my cryptic response)?

mauve was a placeholder namespace to expose documented internals.

On perl's which didn't expose those internals they could be
implemented as XS or pure perl, and so would be available on any perl
as​:

use mauve qw(reftype);

which would use the internal or XS/PP implementation depending on what
was available.

This would allow us to expose functions which probably should be
exposed (like reftype perhaps) without cluttering the operator or
global namespace, and possibly allow for some optimizations
(eg. replacing the call with an operator.)

Unfortunately it turned into an annoying bikeshed over the name, which
AFAIK was never intended to be the final name, so it was dropped.

Thanks, this is an excellent summary.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

From @demerphq

On 26 August 2013 04​:43, Aristotle Pagaltzis <pagaltzis@​gmx.de> wrote​:

* Tony Cook <tony@​develop-help.com> [2013-08-26 01​:45]​:

mauve was a placeholder namespace to expose documented internals.

On perl's which didn't expose those internals they could be
implemented as XS or pure perl, and so would be available on any perl
as​:

use mauve qw(reftype);

which would use the internal or XS/PP implementation depending on what
was available.

This would allow us to expose functions which probably should be
exposed (like reftype perhaps) without cluttering the operator or
global namespace, and possibly allow for some optimizations (eg.
replacing the call with an operator.)

Unfortunately it turned into an annoying bikeshed over the name, which
AFAIK was never intended to be the final name, so it was dropped.

It wasn’t the name alone, but yeah.

I think that describes the point of mauve poorly, though. The idea was
to provide core implementations of a number of functions mainly from
Scalar​::Util, which would not require loading a module (and since this
was a clean break these functions could also fix the niggly API design
problems of the Scalar​::Util functions), which Scalar​::Util would then
become a wrapper around (providing the old worse interface) where mauve
was available.

Yves had the first inkling here​:
http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTi=TCR8z+miH8T4j4Jzwq5ZmKh1mVSEuEbtQrSBE@​mail.gmail.com

He started the fire​:
http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTikHi8jbTshovEMQvdkROx8_JkrksaiqLpNDSDbB@​mail.gmail.com

Unfortunately then-pumpking RGS didn’t like it at all​:
http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTi=UHJ-1VMdZnh_KUrB=CTuageTErBGR1o728rGY@​mail.gmail.com

So it went into quarantine​:
http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=871v8twxr8.fsf@​tardis.home.perldition.org

And ended up being something people merely pined for…
http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=20110427071804.GC6609@​puppy
http​://www.nntp.perl.org/group/perl.perl5.porters/;msgid=CAOeq1c_Y=s6XeeP9TndE7RMqpcE60Yrinu5yzGO2YZ+DShfGCg@​mail.gmail.com

Someday…

Yeah, I still think this was a totally lost opportunity to move
forward with some of these issues.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

From @cpansprout

I have resolved this in commit 2c6c1df by finding another way to meet constant.pm’s needs.

--

Father Chrysostomos

@cpansprout - Status changed from 'open' to 'resolved'