develooper Front page | perl.perl5.porters | Postings from September 2011

Re: A summary of Chip patches and potential impact

Thread Previous | Thread Next
From:
Reverend Chip
Date:
September 8, 2011 14:26
Subject:
Re: A summary of Chip patches and potential impact
Message ID:
4E6932AC.6090407@gmail.com
On 9/5/2011 3:56 AM, Zefram wrote:
> The intention is that new code will use this type information
> semantically.  Then you run into trouble when such new code interacts
> with existing code that knows that there is no such type distinction.

Let's start with the obvious, using the Scalar::Util function names for
the purpose of discussion:

  1. Values generated through boolean operations return true for
isboolean().
  2. Numeric constants and values generated through arithmetic return
true for isnumber().  (no distinction for int/float)
  3. String constants and values generated through string manipluation
return true for isstring().
  4. Dualvars, references, globs, and undef return false for all the above.
  5. Incidental conversions do not affect these natures.
  6. Simple copying preserves these natures.

Defining this as "intentional" information is an error.  These
predicates do not say what you meant to do; they say what you *did*. 
They say *how* the values originated, not why.  This is *provenance*,
not intent.

Negative issues from provenance predicates can only arise when values
pass through machinery that does not preserve their original
provenance.  The cases where this *can* happen, *does* happen, and cause
*actual* problems that cause more work than they save are inevitably
going to be vanishingly small, because in practice XS code and
serialization systems retain the string/number dichotomy already; and
while full boolean support may require some additional coding, in the
meantime everything will work no worse than before, and boolean
preservation can easily be introduced when it would be helpful.

> Another, more specific, concern: there's lots of existing code whose
> job is to store a value and return it later.  Currently, if it finds
> it has a plain scalar then it can store its string and numeric parts,
> in any form, and later accurately reconstitute the scalar from them.

I don't think there is "lots" of such code that always stores both
string and number and always sets them both.  In fact I can't think of
any.  Such code would always generate dualvars.

> Given your new type distinctions, however, especially the boolean one,
> the existing code will not accurately reconstitute the new type flags,
> and so will not be accurately storing the scalar for the purposes of
> code in which the new type information is semantically significant.

I agree that Data::Dumper, Storable, and the like may need enhancement
if they are to preserve booleanness, while they already preserve
string/number nature.  But that's no biggy.  In the worse case
booleanness gets lost in translation and must either be ignored or
manually restored.  Such a limitation is not fatal to the feature, as it
is easily remedied and breaks nothing in the meantime.  And considering
that many non-Perl-specific serialization frameworks already have
special cases for booleanness (YAML, JSON, etc. etc.), core boolean
nature offers unification rather than trouble.  Don't omit the positive
aspects.

Other languages have true boolean types, and with good reason.  The
experiments have been run: booleans are good.  Edging in that direction
is a feature, not a bug.  And C++, for all its flaws, is an existence
proof that booleans can be integrated to good effect into a language
that lacked them.

>> And it seems like an obvious step toward running Perl
>> on systems where strings and numbers are very different.
> I don't see what you mean here.  Perl *is* the system here, and determines
> for itself how distinct strings and numbers are.

Perl on JVM.  Perl on JS.  Perl on C++.  Perl on LLVM, for that matter. 
These are our futures, and just a little more type identification will
be quite helpful in the transition.


Thread Previous | 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