Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re^2: Modernizing the Postmodern Language?

by LanX (Saint)
on Jun 30, 2020 at 00:02 UTC ( [id://11118687]=note: print w/replies, xml ) Need Help??


in reply to Re: Modernizing the Postmodern Language?
in thread Modernizing the Postmodern Language?

Sawyer gave two practically unrelated talks and you both are mixing them up.

One about Perl 7 and one about what he wants to call "Standard Perl" a subset with BNF language definition, hence statically parsable by tools like Guacamole.

He was clear about that "Standard Perl" is not related to "Perl 7"

> If bareword filehandles no longer exist in Perl 7, how do you refer to STDOUT, or more commonly, STDERR, as in print STDERR "oops: ..."? Or, for that matter, STDIN, as in <STDIN>?

They are excepted, kind of built-ins.

I recommend watching those talks on YouTube before speculating and spreading rumors.

And the user you are responding to is pretty unknown here and had only 2 posts so far, so I'd be really careful to rely on such sources.

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery

Replies are listed 'Best First'.
Re^3: Modernizing the Postmodern Language?
by WaywardCode (Sexton) on Jun 30, 2020 at 01:39 UTC

    The 1999 'postmodern' talk says: "Perl is humble. It doesn’t try to tell the programmer how to program. It lets the programmer decide what rules today, and what sucks. It doesn’t have any theoretical axes to grind." That's the Perl I want... not the Perl that says "your code will adhere to strict and warnings no matter what."

    I have not mixed up the "Guac" talk with the Perl7 talk, but I fear it has provided insight into what Sawyer thinks is good and not-so-good about Perl syntax, and I don't like what I heard. Especially on the eve of leading a set of breaking changes to the language, I don't like to hear the leader saying how much he never liked a lot of perl-unique quirks and then naming a severe subset "Standard Perl." Further, I prefer a leader with enough awareness to understand how confusing it will be to call something he produces "Standard Perl."

    Bareword filehandles are on the chopping block in the Perl 7 Announcement, and there it says except MAYBE the standard filehandles. I don't see how you can definitively tell people they are excepted like built-ins, unless you have more information. Strict and warnings are also discussed in the Perl 7 announcement. I did not mix anything up there.

    It is true I do not spend a lot of time participating on forums--my other post here was in 2016--, if that disqualifies my thoughts here so be it.

      G'day WaywardCode,

      '... "your code will adhere to strict and warnings no matter what."'

      My general recommendation is that you should start all code with those two pragmata. I see not having to always type them as a good thing.

      Having said that, the article to which you linked has a number of examples of no. I'm not aware of any reason why you couldn't use that on the rare occasions that you don't want those pragmata.

      I would strongly suggest that you only turn off parts of the functionality in a limited lexical scope. Perhaps something like:

      my @punctuation_chars; { no warnings 'qw'; @punctuation_chars = qw{. , ; :}; }

      — Ken

        My general recommendation is that you should start all code with those two pragmata.

        Before I am too misunderstood, let me be clear that I agree with the recommendation. I disagree with flipping the defaults that have been in place for decades and telling people code which doesn't work under the new defaults is bad code.

        Forget strict, look at what they are proposing with changing the syntax for prototypes. Are you telling me it's impossible to add signatures to the language without changing prototypes? I don't buy that. It might not come out as pretty, but for a language as old as perl, compatible is worth more than pretty. It boggles my mind that they call out postfix dereferencing as a benefit of perl7 in the p7 announcement post, since that doesn't need any feature flags in perl today:

        perl -e '$x = [1,2,3]; print $x->@*'

        ...which makes it a great example of how you can innovate in the language while respecting what it already is.

      > your code will adhere to strict and warnings no matter what."

      Again, they said that no strict and no warnings are still possible.

      The same for use v5.10.0

      So no "no matter what."

      If Perl 7 defaults help reducing the copy and paste boilerplate from Perl 4 I'm full for it.

      Guacamole is Sawyers private project, it'll have to prove itself.

      Disclaimer: I'm not involved in the decision making and have no behind the scene insight.

      Just interested in a fair and sober discussion.

      > if that disqualifies my thoughts here so be it.

      It doesn't disqualify you.

      One has to be aware that this board is full of trolls and sockpuppets.

      Considering the post history helps.

      You are speculating about insights into the "leader's" mind and intentions, but we have no insight into yours.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery

        Again, they said that no strict and no warnings are still possible.

        Reverting the new defaults is possible for v7, but they explicitly said it would not necessarily be true for v8. If Perl resumes its pre-5 version pace, that's only a few years away. Even if reverting the defaults remains possible, the programs where strict and warnings are least convenient are 5-line throw-away programs run in implicit -n or -p loops, where turning them off or saying use vars qw// is just getting in the way for no benefit. For one-liners, it could mean the difference between using Perl and not bothering. I claim (and don't appear to be alone, looking at p5p), the better tradeoff is to put use v7 in a file and get all the new defaults. I already use use v5.20 or whatever in my longer scripts, so it seems totally natural, but I guess according to Sawyer almost nobody does this.

        Re-watching the p7 talk now, again, I really don't like how certain patterns are labelled "bad." The Perl I know does not get overly opinionated on how I write things. These talks bother me enough to crawl out of the woodwork and ask the Monks if I'm wrong to be concerned. Maybe I am wrong.

Re^3: Modernizing the Postmodern Language?
by dsheroh (Monsignor) on Jun 30, 2020 at 08:40 UTC
    He was clear about that "Standard Perl" is not related to "Perl 7"
    I think everyone in this discussion is aware that this is officially the case, but the fact is that they are unavoidably connected in that Perl 7 and Standard Perl are both being driven by the same person. Don't forget that, in the Guac talk, Sawyer's clarification on this point was prompted by the moderator cutting in to tell him that the chat was filling up with people saying "OMG! The pumpking wants to gut Perl!!!"

    So, yes, it is clear and correct that Standard Perl is not the plan for what Perl 7 (or 8, or any future official release) is meant to look like... but they are both the products of the same mind. To the extent that Standard Perl accurately represents Sawyer's concept of what the Platonic Ideal of Perl might look like, it also shows where he would like to see the language one day go, even if he knows that others would not agree with or accept those changes. (And note that I'm not saying it's a 100% accurate representation of Sawyer's "Ideal Perl", but there is almost certainly some high degree of similarity between the two.)

    It's like a politician or a corporate leader expressing a personal opinion on a controversial topic. It's not the official position of their party or employer, but, despite that, it still reflects on the party/employer and (IMO, rightly) creates an impression that the party/employer at least accepts those views and may wish to unofficially further them, even if it doesn't openly endorse them.

      So what?

      Many pumpkins mused about function signatures in the past and nothing happened in 20 years.

      And the history of Perl has a long list of "pumpkins" who resigned.

      We should be glad to have someone who does the job and has the guts to offer visions.

      A BNF parsable Perl which can be enforced by pragma is a quality in itself many people want.

      Let history decide, not polemics.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery

Re^3: Modernizing the Postmodern Language?
by jcb (Parson) on Jun 30, 2020 at 02:17 UTC
    They are excepted, kind of built-ins.

    That is really a huge wart, far worse than general bareword filehandles could ever be. You still have the syntax cases, except now they are special cases instead of instances of a general rule.

    And the user you are responding to is pretty unknown here and had only 2 posts so far, so I'd be really careful to rely on such sources.

    Duly noted, which is one of the reasons I am in no particular rush: if Perl7 does turn into Perl6 all over again, I am confident that it will end similarly, with Perl5 carrying on.

      Perl 7 will run on the same engine, just with other default pragmas.

      I asked explicitely.

      Compatibility to CPAN is paramount, P7 will have a compatibility flag.

      No relation to Raku.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery

        If that is the case, then how can bareword filehandles be removed? Or are bareword filehandles supported in Perl7 but omitted from "Standard Perl" and our fellow monk WaywardCode was confused?

        Backwards compatibility is my largest concern. The idea that even modern Perl can still run the Perl1 testsuite is impressive, far better than most languages have done, and probably a big part of the cause for the failure of Perl6 as Perl. (How it will fare as Raku is yet to be seen.)

        Now that I think about it, "promoting" bareword filehandles to packages would solve the ambiguity in the IO syntax, at the price of requiring a full STASH for each global filehandle and some other internal changes, since *foo{IO} would refer to the nameless I/O slot in package foo instead of an I/O slot on a named GLOB foo. This is not so bad, since global filehandles should be rare and typically limited to main scripts, with =IO references being more common in modules and subroutines, although Symbol's geniosym probably would need to become a builtin XSUB. The idea is that a GV would no longer contain an I/O slot, instead associating an I/O slot to each stash.

        The package/filehandle conflict is one of the few actual problems with bareword filehandles in Perl, and I believe this change would solve that problem with minimal impact on backwards compatibility. I believe this could also allow barewords to always parse as package names, another ambiguity resolved if package names evaluate to themselves as strings.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (6)
As of 2024-03-28 15:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found