Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re^2: Recap: The Future of Perl 5

by Ovid (Cardinal)
on Aug 24, 2018 at 11:35 UTC ( #1221016=note: print w/replies, xml ) Need Help??


in reply to Re: Recap: The Future of Perl 5
in thread Recap: The Future of Perl 5

Provide an API which allows a type library module to define types such as my Str $x where Str isn't a package name ...

Again, that fails horribly, IMHO. For the shops which adopt that, every time I go into a shop, I have to discover how their implementation of "Str" is different from the implementation of "Str" at my last shop, which in turn is different from the implementation of "Str" I would expect in other languages. Core types that people expect should be in the core (and not in libraries I have to remember to load!). Further, their behavior should be as boring and predictable as possible. As for an extensible API? Sure, I can get behind that if the arguments which would invariably ensue are brief. Otherwise, the bike-shedding would stand a good chance of guaranteeing that nothing would get done.

Bundle a module with core which defines a bunch of predefined types. Perhaps automatically load it if a recent enough use VERSION line is given.

Again, if you have to remember to do a particular thing to get benefits, it hurts the Perl community. For example, use strict; use warnings; should have been the default a long time ago, with additional action taken to disable them. It's less common now, but we still have to fight to remind developers to enable strict. That's years of arguing over a basic issue that could have been spent more profitably writing code and developing the language.

Replies are listed 'Best First'.
Re^3: Recap: The Future of Perl 5
by tobyink (Canon) on Aug 24, 2018 at 12:06 UTC

    Even with something as simple as Str, if you put ten Perl developers in a room, I'd expect them to have eleven different opinions on how it should be implemented.

    my Str $x = $y;
    • If $y is undef, then $x should be "" because of type casting.
    • If $y is undef, then there should be an exception thrown because undef isn't a string.
    • If $y is an overloaded object, then $x should now be an overloaded object.
    • If $y is an overloaded object, then $x should now be the stringified version of that object.
    • If $y is an overloaded object, then there should be an exception thrown because an object isn't really a string and overloading sucks anyway.
    • Even if $y is a non-overloaded object, $x should now be the stringified version of that object.
    • If $y is 42 (no quote marks), then there should be an exception thrown because integers aren't a subset of strings dammit!
    • If $y is 42 (no quote marks), then $x should be "42" (with quotes) and poking around with B:: stuff you should be able to tell the difference between them.
    • A lot of these cases could be handled by using warnings instead of exceptions. It's basically the same kind of error as use warnings "numeric" anyway, and we're happy enough having those be non-fatal.
    • Empty strings are always an error in my application, so if $y is "", it should throw an exception, shut down the computer, and set the building on fire. (In all seriousness, I know of at least one case in Perl where empty strings are special-cased, treating them differently from non-empty strings.)
    • But dualvars! Waaaaaah!

      The point of optional, gradual typing is to offer optional type safety. If I say "String", it must be defined and have an appropriate string value. Thus, undef would cause an exception. I would suggest that any non-overloaded reference would also throw an exception (No more printing out ARRAY(0x7fecea803280)). However, if stringification is directly overloaded, we'd have to respect the intent because printing DateTime->now is intended to work. The integer 42 would need to stringify to 42 because even Java allows this as the one case of operator overloading because it's so damned useful.

      That being said, I could be smoking crack. And I'd want these to be exceptions, not warnings, because I find so many ways in which warnings can be overlooked.

        The point of optional, gradual typing is to offer optional type safety.

        This seems like a tricky feature in an allomorphic language like Perl, where intrinsics are polymorphic and operators are monomorphic.

        I would suggest that any non-overloaded reference would also throw an exception.

        I think there are cases where default stringification is desirable, and I suspect you'd have to go through each operator and each intrinsic to come up with a matrix of where it might be useful. This seems like a similar problem to smart match (though less so, because stringification for types should be a unary op, not a binary op).

      I'd be quite fine with eleven different opinions on how Str should be implemented. The Perl developers should then talk to each other, look for a consensus and make this the way it is done.

      It is the subtle differences between Perl's (CPAN) object systems which drives me nuts, not the individual behaviour of any of these systems. I can live just fine with any of them, but having more than one in a project, which is inevitable for bigger projects, hurts.

        The Perl developers should then talk to each other, look for a consensus and make this the way it is done.

        Agreed. And since there are already multiple competing modules to handle type constraints and OO in general any Perl programmer could happily ignore anything added to the language and continue to use their existing favourite module because TIMTOWTDI.

        having more than one in a project, which is inevitable for bigger projects, hurts.

        Ain't that the truth. It certainly looks like that particular horse has long since bolted, unfortunately.

Re^3: Recap: The Future of Perl 5
by doom (Deacon) on Aug 24, 2018 at 18:41 UTC

    Ovid:

    Again, if you have to remember to do a particular thing to get benefits, it hurts the Perl community. For example, use strict; use warnings; should have been the default a long time ago, with additional action taken to disable them.
    So, Joe SysAdmin does an upgrade one day, and finds half of the old perl scripts on the system are broken. This is not something you want to have happen, not when we're still fighting the fallout from the "perl is dead" smear campaign.

    I could see an argument that stuff like "use 5.10.0" should've implied strict and warnings also... or for that matter that cromatic's Modern::Perl should ship with the core library, it's a lot easier to type correctly (I had to double-check that you really need "5.10.0").

    Backwards compatibility is really and truly important, and it remains important-- it's one of the things that perl has always gotten right (and the new kids keep screwing up).

      use v5.16 and above does enable strict (though not warnings).

        5.12 in fact already does that.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1221016]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2020-10-29 12:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My favourite web site is:












    Results (270 votes). Check out past polls.

    Notices?