Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haskell to Perl 6

docs.perl6.org

Post reply on HN
Print view View original

111–120 of 136 posts

Re: Haskell to Perl 6

#111

Post by vram22 »

cwyers wrote: post #14
_delirium wrote: post #12

Earlier quoted context omitted.

I've never used Perl6, but it took me about 30 seconds to figure out what 'say' and 'gist' do from the linked docs? 'gist' prints a string representation of an object aimed at being human-readable at the expense of not necessarily being a complete representation (e.g. the doc page gives an example that an array has only its first 100 elements printed followed by a '...'). 'say' is a version of 'put' that does this fo…

So, I sort of took that away from it, but there's stuff in the gist page like: > The default gist method in Mu re-dispatches to the perl method for defined invocants, and returns the type name in parenthesis for type object invocants. Many built-in classes override the case of instances to something more specific that may truncate output. And I have no idea how anyone that isn't already fluent in Perl 6 is expected t…

Reading the docs a bit more and/or googling for terms like "perl6 mu" might have helped. I too might have not what Mu meant (in the context of Perl6, although I did know the original meaning), unless I had come across it in the docs or elsewhere.

But IMO, like others have said, it is not really that difficult to figure out what it means (if you know some OOP) (although some of the rarely-used words (e.g. "invocants") get in the way a bit.

Basically when I read your comment, I figured out that the default gist method (even the word "gist" is a clue) was something like a default-valued method (to print the representation of any object) that can be overridden on a case-by-case basis by any other object - something like Python's __str__() and __repr__ special methods, like others have said.

However, having read some of it, I'll have to agree with you that the Perl6 docs can do with some improvement (check out Phasers in the Perl 6 manual for an example of what I mean) - whereas, in contrast, the Perl 5 docs are considered by some (me too) to be good-to-excellent. But then Perl6 has been evolving for less time (yes, I know about the long time for the 1st stable release).

Re: Haskell to Perl 6

#112

Post by vram22 »

kbenson wrote: post #85
chombier wrote: post #45

Earlier quoted context omitted.

One can write pretty much the same code in python/c++11/whatnot and it also feels quite natural to read: for number in numbers: if number Do you have a better example where the Perl syntax would shine?

Note: This is all in the context of Perl 5. You can assume the following works with little or no changes in Perl 6, along with probably 3+ other new ways to do it (which is actually one of my peeves about Perl 6). There's a few things. Full word but lower precedence boolean operators (and, or, not) which allows for combining statements in a way that &&, || and ! doesn't always facilitate, but really shine in making b…

Wow, the fact that Larry Wall was a linguist and (along with many others, I'm sure) applied those skills (about the nuances of human languages) to the design of Perl, really shines through in this comment. Thanks.

Re: Haskell to Perl 6

#113

Post by vram22 »

kbenson wrote: post #89
ricardobeat wrote: post #86

Earlier quoted context omitted.

Lots of other languages have postfix conditionals. On the readable boolean ops, all the Perl people recommend shying away from them except for a few specific constructs (do or die, eval or do, etc), since the weaker precedence rules make it really easy to shoot yourself on the foot: $a = $b or $c; Where $a will never be assigned the value of $c.

> Lots of other languages have postfix conditionals. I didn't make a case as Perl being the only language, just that it's an interesting aspect of Perl. That said, I would be interested in what languages you are referring to. I haven't seen many. > On the readable boolean ops, all the Perl people recommend shying away from them except for a few specific constructs (do or die, eval or do, etc), since the weaker preced…

>I didn't make a case as Perl being the only language, just that it's an interesting aspect of Perl. That said, I would be interested in what languages you are referring to. I haven't seen many.

I'm not the one you replied to, but Python has got, not postfix conditionals, but what I might call infix ones, for lack of a better name. Here is a nested example:

Using nested conditional expressions to classify characters:

https://jugad2.blogspot.com/2017/04/using-nested-conditional...

Re: Haskell to Perl 6

#114

Post by vram22 »

Furiosity wrote: post #76
labster wrote: post #21

Earlier quoted context omitted.

Why would Perl repeat the same mistake as others, of trying to treat a programming language too much like a natural language? It's optimized to be read as a programming language, not anything else. Also, "cryptic charade" could be a good name for what all non-Perl 6 languages call "regular expressions". It would make an even better name for a prog rock band.

Perl (5 or 6) doesn't try to treat a programming language as a natural language. Instead it tries to allow the structure in which the author's brain defines the problem to be able to match the structure in which the code of the program defines the solution. It is linguistic in the sense that it tries to follow the normal flow of human language as a form of communication, allowing skills learned for human communicatio…

>In contrast to Perl5, Perl6 makes it far easier to avoid accidental spaghetti and does so without sacrificing any of the linguistic expressiveness that makes Perl generally so useful.

Can you give some examples of that point, w.r.t. Perl6?

Re: Haskell to Perl 6

#115

Post by raiph »

vram22 wrote: post #114
Furiosity wrote: post #76

Earlier quoted context omitted.

Perl (5 or 6) doesn't try to treat a programming language as a natural language. Instead it tries to allow the structure in which the author's brain defines the problem to be able to match the structure in which the code of the program defines the solution. It is linguistic in the sense that it tries to follow the normal flow of human language as a form of communication, allowing skills learned for human communicatio…

>In contrast to Perl5, Perl6 makes it far easier to avoid accidental spaghetti and does so without sacrificing any of the linguistic expressiveness that makes Perl generally so useful. Can you give some examples of that point, w.r.t. Perl6?

I'm not sure if I've nailed what the GP was speaking of or what you're looking for but anyway I do think the following is illustrative of the linguistic evolution P6 represents.

Earlier this year at perlmonks (perhaps the top resource along with stackoverflow for experienced perl folk answering questions) a poster wanted solutions to a fairly basic operation:[1]

> I need a function which will filter a nested hash, removing any fields I'm not interested in.

Their test data had a source that began:

    my $source = {
        f1 => 'garbage',
        f2 => 'more garbage',
        f3 => 'important data',
        f4 => {
            this => 'sub hash',
            is   => 'garbage'
        },
        f5 => {
            f6 => 'more important data',
and a filter that began:

    my $filter = {
        f3 => 1,
        f5 => {
            f6 => 1,
After a few days the person who asked the question summarized the community's P5 answers.[2]

The first one listed (slightly trimmed):

    #! /usr/bin/env perl

    use strict;
    use warnings;

    use Carp;

    use Deep::Hash::Utils qw(reach nest deepvalue);

    sub hash_filter_recursive {
      my $source = shift;
      my $filter = shift;

      my %output;

      foreach ( keys %$filter ) {
        if ( exists $source->{$_} ) {

          if ( ref $filter->{$_} eq 'HASH' ) {
            croak "bad filter: on '$_', expected HASH\n"
              unless ( ref $source->{$_} eq 'HASH' );

            $output{$_} = hash_filter_recursive( $source->{$_}, $filter->{$_} );
          }
          else {
            $output{$_} = $source->{$_};
          }

        }
      }

      return \%output;
    }
(This appears to include a modicum of input validation.)

Here was my P6 answer, including the call to invoke the routine (which I omitted from the P5):[3]

    sub infix: ($l, $r) { $l and $r };
    say $filter «landr» $source
Even though this uses a parallel operation which will one day optionally be automatically mapped to multiple cores to run faster, I'm pretty sure this is currently slower than the P5 solutions.

And I didn't bother with any validation that it was indeed being passed a nested hash.

But it makes a point. While P6 can typically do similar things to P5, it often turns out easier to do many things at a much higher level, which leads to less spaghetti.

----

[1] https://www.perlmonks.org/?node_id=1215517

[2] https://www.perlmonks.org/?node_id=1215736

[3] https://www.perlmonks.org/?node_id=1216274

Re: Haskell to Perl 6

#116

Post by xisukar »

lizmat wrote: post #109
xisukar wrote: post #107

Earlier quoted context omitted.

From https://docs.perl6.org/routine/contains , `contains` coerces its invocant to a string and searches for a substring starting from a certain position (index 0 by default): # Let's drop ` ` (quote-words constructor) and # use a more familiar array of strings: my @menu = 'hamburger', 'fries', 'milkshake'; # Let's look at the definition of the `Str` method in # the `List` class from which the `Array` class inherits:…

The ASCII equivalent of `∈` is `(elem)`.

You're totally right! I always get them confused. So `∈` is `(elem)` and `⊆` is `(Thanks for pointing it out!

Re: Haskell to Perl 6

#117

Post by ktpsns »

raiph wrote: post #96
ktpsns wrote: post #70

Actually Perl 6 comes off badly in this comparison. The Haskell expressions are almost always easier to read, understand, reproduce, and overall even shorter. Nevertheless it shows that Perl 6 can do real functional programming. Even if the syntax looks exceptional sometimes, even for people familiar with Perl 5.

It's not a comparison. It's not an appetizer for P6 or ways in which P6 comes off better than Haskell. It's not an overview or tutorial for learning P6 if you come from a Haskell background. It's for someone who has already decided they like P6, has learned the basics, and wants to tighten up their understanding of P6 as it relates to Haskell things they know. It deliberately picks things that are basic in Haskell ev…

You're certainly right, but that doesn't change my point that, by just looking at the code, Haskell seems to have the better solutions for the problems.

This conclusion is clearly unfair because the author tried to port simple Haskell solutions to Perl.

Re: Haskell to Perl 6

#118

Post by raiph »

xisukar wrote: post #108
raiph wrote: post #95

Earlier quoted context omitted.

> The examples vs Haskell are not helping me understand. Personally I don't think the added verbosity is helping in any way. It doesn't sound to me like you are the right audience for the document you're reading. Quoting from that page: > this should not be mistaken for a beginner tutorial or overview of Perl 6; it is intended as a technical reference for Perl 6 learners with a strong Haskell background. It is not wi…

> In P6, every type that's created using any of its type constructors is a sum type with two sub-types. > This includes types defined in the standard language such as Int. The sub-types are named D and U. > For example, to refer to Int's D sub-type, use `Int:D`. Probably your comment hints to this already in which case the following will be redundant but I wanted to mention them more explicitly. This is mainly for pe…

> Probably your comment hints to this already

Regardless, I'm glad you've written your comment to clarify. :)

I'd be delighted to hear about any of the several big or small mistakes I am about to make in the following.

Also an honest opinion about whether the following approach I take boils down to one that is complete gibberish, vaguely interesting but terribly complex, OK but meh, good but a bit abstract, enlightening, or something else. If you do let me know, please clarify whether you mean what you say for just you, or for what you think might be true for others that don't know P6 at all. TIA.

----

Like a lot of P6 stuff this basic aspect of its type system is both childishly simple but also so general, abstract, and high level, and comes at things from such a different angle than pretty much all other languages, that it can be difficult to explain.

Another attempt at what I was trying to get at in my second footnote in my GP comment...

----

A P6 type and its two standard sub-types are a simple and fun unification of the universal/existential "quantification" that our inner logician loves and the "article definiteness" distinction recognized by our linguistic side.

From https://en.wikipedia.org/wiki/Article_(grammar):

> The articles in English grammar are "the" and "a/an" ... In languages that employ articles, every common noun, with some exceptions, is expressed with a certain definiteness, definite or indefinite

From https://en.wikipedia.org/wiki/Quantifier_(logic):

> The two most common quantifiers mean "for all" [Universal] and "there exists" [Existential].

----

:D denotes a definite thing.

It is directly analogous to "the".

The value `42` is considered definite.

Definiteness implies that a thing actually exists. Its the linguistic analog of existential quantification.

Many coders talk about happy/sad path processing. :D is associated with the happy path, perhaps because it has no existential crisis. :D

----

:U is related to Universal quantification.

As a type, it is also related to "a". Quoting wikipedia:

> An indefinite article indicates that its noun is not a particular one identifiable to the listener.

:U corresponds to an indefinite thing, something that's only identifiable as a Universal, not a Definite thing.

:U is also associated with Undefined things, even if they are supposed to be undefined.

In the context of talk about happy/sad path processing, :U is associated with the Unhappy path, because it can denote a thing that should be definite but isn't.

----

As a value, a type name without a `:D` or `:U` smiley is the same as the type name with a `:U`.

As a type, a type name without a smiley is the same as the type name with a `:_`, where the `_` denotes either `D` or `U`.

Thus:

* `Int`, as a thing in of itself, is the same as an `Int:U`.

* `Int`, as a type of thing, denotes either an `Int:U` or an `Int:D`.

Re: Haskell to Perl 6

#119

Post by vram22 »

raiph wrote: post #115
vram22 wrote: post #114

Earlier quoted context omitted.

>In contrast to Perl5, Perl6 makes it far easier to avoid accidental spaghetti and does so without sacrificing any of the linguistic expressiveness that makes Perl generally so useful. Can you give some examples of that point, w.r.t. Perl6?

I'm not sure if I've nailed what the GP was speaking of or what you're looking for but anyway I do think the following is illustrative of the linguistic evolution P6 represents. Earlier this year at perlmonks (perhaps the top resource along with stackoverflow for experienced perl folk answering questions) a poster wanted solutions to a fairly basic operation:[1] > I need a function which will filter a nested hash, re…

Thanks for the reply. Definitely looks like P6 can work at a higher level ...

Re: Haskell to Perl 6

#120

Post by raiph »

ktpsns wrote: post #117
raiph wrote: post #96

Earlier quoted context omitted.

It's not a comparison. It's not an appetizer for P6 or ways in which P6 comes off better than Haskell. It's not an overview or tutorial for learning P6 if you come from a Haskell background. It's for someone who has already decided they like P6, has learned the basics, and wants to tighten up their understanding of P6 as it relates to Haskell things they know. It deliberately picks things that are basic in Haskell ev…

You're certainly right, but that doesn't change my point that, by just looking at the code, Haskell seems to have the better solutions for the problems. This conclusion is clearly unfair because the author tried to port simple Haskell solutions to Perl.

> You're certainly right, but that doesn't change my point that, by just looking at the code, Haskell seems to have the better solutions for the problems.

Sure. But that's an inevitable consequence of what the document aims to achieve.

The problems chosen were the ones for which Haskell had simpler solutions.

The point of the document was to help someone who is already motivated to learn P6 and knows Haskell to get to grips with P6.

If the point were to motivate someone who knows Haskell to want to learn P6 then the examples chosen would be ones for which the P6 solution is better than the Haskell one.

Post reply on HN