News for hackers. Stuff that matters.
Re:Four features that justify a new Unix shell by chubot on Friday October 23, 2020 @09:00PM (#24876010)
I think Perl needs a real pipeline syntax, among other things: http://www.oilshell.org/blog/2018/01/28.html#are-you-reinven...

That said, Oil is somewhat influenced by Perl: https://www.oilshell.org/release/0.8.3/doc/language-influenc...

Also note this part of the original blog post, Python/JS/Ruby vs Perl/PHP: http://www.oilshell.org/blog/2020/10/osh-features.html#oil-l...

I recently bought a copy of the Camel book and noticed the exact same thing that Steve Yegge pointed out here:

Perl's references are basically pointers. As in, C-style pointers. You know. Addresses. Machine addresses. What in the flip-flop are machine addresses doing in a "very high-level language (VHLL)", might you ask? Well, gosh, what they're doing is taking up about 30% of the space in all Perl documentation worldwide.

https://sites.google.com/site/steveyegge2/ancient-languages-...

This is really a huge, unnecessary wart in the language.

The other wart I pointed out in the post is that Perl 5 does dynamic parsing of its own code (parsing that depends on the value of variables), despite the book complaining about the same issue in shell. In contrast, Raku and Oil are statically parsed.

----

I have a lot of respect for Perl, but there's a reason that Raku exists (and again from the FAQ: Raku and Python 3 are both worse shell-like languages than their predecessors.)

Re:Four features that justify a new Unix shell by ryl00 on Friday October 23, 2020 @09:42PM (#24876212)
> Perl's references are basically pointers. ... This is really a huge, unnecessary wart in the language.

Call me crazy :), but I count this as a pro for perl! It makes thinking about data structures in perl very "regular" for me.. there's a few rules to learn, but then I find it simple to construct (or de-construct) nested data structures while applying those rules. As opposed to other scripting languages, where the difference between "value" and "reference" frequently seems to be more hidden from sight...

Re:Four features that justify a new Unix shell by lizmat on Monday October 26, 2020 @07:01AM (#24894808)
> In contrast, Raku and Oil are statically parsed.

I don't know about Oil, and if I understand your use of "statically parsed" correctly, Raku is not statically parsed. A "use" statement can affect how Raku parses source code from there on, see e.g. the OO::Monitors module that adds a "monitor" keyword.

But even simpler, adding an operator changes the grammar. For instance, adding a postfix ! operator for faculty, can be as simple as:

    sub postfix:<!>(\value) { [*] 1 .. value }
    say 5!   # 120
Re:Four features that justify a new Unix shell by chubot on Monday October 26, 2020 @05:08PM (#24901435)
OK interesting, I guess the question is if "use" requires running (not just parsing) arbitrary code? I guess if it's like Python's "import", it does.

Changing the grammar could still be considered static parsing, as long as the change doesn't depend on the values of variables at runtime, e.g. your argv array or something.

I recall Larry Wall saying that Perl 5 was at times confused about the language it was parsing, and the goal was to fix that in Perl 6. I don't have a lot of experience with it, but yeah that claim could be wrong, or at least un-nuanced.

Re:Four features that justify a new Unix shell by lizmat on Tuesday October 27, 2020 @08:11AM (#24906626)
The process of exporting symbols is done in an EXPORT subroutine that can be provided by the module developer. This subroutne is supposed to return a Map of symbol names and what they refer to. This Map can be constructed depending on external factors such as an argv array or an environment variable, although I have yet to see this in the wild.

So I guess one could say that Raku parsing is usually static, but it does not need to be.