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

What does it mean to be a version? [was: Perl 5.16 and Beyond.]

Thread Previous | Thread Next
Aristotle Pagaltzis
September 14, 2011 09:16
What does it mean to be a version? [was: Perl 5.16 and Beyond.]
Message ID:
* Abigail <> [2011-09-13 15:25]:
> Here's an even simpler example:
>     use 5.18;
>     sub mylc {
>         lc $_ [0];
>     }
> Normally, I would document that as "mylc returns the lowercase
> of its argument".
> But that should now be documented as "mylc returns the 5.18
> lowercase version of its argument". After all, lc may change
> semantics in the future. (Of course, I'm just using 'lc' as an
> example here; it could be any other expression). And that would
> require people to not only know the semantics of the version of
> Perl they are using - but also the semantics of all versions
> since 5.14 up to the one they are working with.

* Dave Mitchell <> [2011-09-14 12:40]:
> I think the devil is in the detail. If, while running under 5.20,
>     use v5.16;
> is just about equivalent to
>     no feature 'list of features added in 5.18, 5.20';
> then I'd be happy with that.

This is how I read Jesse’s proposal. However, his slides are clearer
on that than the prose version he sent to p5p. See slides 127 ff.

    If you declare an old version, you get old syntax and semantics
    …at least to the best of our abilities
    Perfection is not possible
    We can get far closer than we do now
    Breaking existing code should be a last resort
    In limited circumstances we will break backward compatibility
    Some craziness can’t be fixed in an “optional” or lexical way

The last slide is the key here. The way that reads to me is that Jesse
means basically what you said. That would address Abigail’s concern.
Unless a `feature` the behaviour of `lc` in the meantime. I think
those things should be minted with great care.

But that brings me to another point.

I think Abigail’s issue arises because there is a conflation here.

It is one thing to say

    Run this program with semantics as close to 5.16 as possible

and quite another to say

    Parse this code the way 5.16 would have

Think about it. If a script was written to run under 5.16, you want to
keep all of it working as much like as on 5.16 as possible, even when
it loads modules written so they could also run on 5.42.

    If a program says it wants 5.16 then the operational semantics for
    all the code it loads should be 5.16, even if parts of the code
    were written to be compatible with 5.42.

It is perfectly acceptable and sane to mix together different pieces
of code that that expect to be parsed under different rules. I do not
see how it can be sane to mix together different units of compiled
code that have different semantics for different operations.

If you look at it that way, then the issue Abigail raised vanishes.

So I think there needs to be a separation between these meanings.

The first idea I had was `use v5.16` should mean something else at the
top-most scope of the program than it means in subordinate scopes.
I am reminded of how Perl 6 draws a distinction between modules and

However I’m not sure it’s a good idea to use the same mechanism for
both cases, but switching its meaning. We may need a mechanism other
than `use $VERSION` for that bit.

Aristotle Pagaltzis // <>

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