Set in Your Ways: Perl 6’s Setty and Baggy Types | Hacker News Reader

Set in Your Ways: Perl 6’s Setty and Baggy Types

perl6advent.wordpress.com

60 pointskumaranvpl34 comments

Every Perl6 article I read makes it even less likely that I'll ever use it.

It's so ugly, with so many arcane things to remember, with so many weird naming conventions that just don't make any sense to me.

> We intersected two sets with the ∩, U+2229 INTERSECTION, intersection operator and received a set that contains only the elements present in both original sets.

I'm not against having built-in Unicode operators, but the non-Unicode version should be the name of the character. What's the non-Unicode version of "∩"? Obviously it's "(&)"! Good thing there are only 57 of them to remember!

I tried to enter "∩" just now in Emacs: (ctrl-x, 8, enter, i, n, t, tab, r, tab, s, e, c, tab). It would have been shorter to just type "intersection"... And why is that called the "Texas" version?

What's the non-Unicode version of "∩"? Obviously it's "(&)"!

I find that pretty obvious, actually. After all

    A ∩ B = { x ∈ A & x ∈ B }

That at least explains where it comes from, but I'd still argue it won't be obvious to people at first.

And it's still kind of confusing. If the goal is to match math notation then wouldn't (^) or (+) make more sense?

    A ∩ B = { x ∈ A ∧ x ∈ B }

If the goal is to match math notation then wouldn't (^) or (+) make more sense?

Not necessarily. & is the ASCII symbol associated with logical 'and' that most programming languages have settled on, including Perl6, so for internal consistency, it makes sense to use it. Also note that the ampersand, while pretty rare, is sometimes used for that purpose in mahematical notation (https://en.wikipedia.org/wiki/List_of_logic_symbols).

> What's the non-Unicode version of "∩"? Obviously it's "(&)"!

That convention has decades of precedence in programming:

    int bitset_a = 0x01234567, bitset_b = 0x89ABCDEF;
    int bitset_c = bitset_a & bitset_b;

And at least a century in math.

There is a doc for entering unicode characters: https://docs.perl6.org/language/unicode_entry.html

It also has an Emacs section. For a more detailed explanation for Emacs see my blog post: https://blog.ciavash.name/2016/01/09/entering-perl6-unicode-...

    say 42 ∈ <42  55  1>;   # False; ∈ operator cares about object identity

As an outsider, this seems like a huge gotcha. I suppose the weirdest thing (after reading some docs) is why < > quotation is used as a set literal here. Would something like

    say 42 ∈ (42, 55, 1);

work as expected? Or what would be the canonical way of writing an Int (not IntStr) set literal?

    perl6 -e 'say 42 ∈ (42, 55, 1)'
    True

That works fine -- and probably better than the quote-words operator <>. ∈ works on anything list-like, not just set types.

The angle brackets are explicitly string operators. So the set contains the string "42" but not the number 42. Perl does generally have different operators for strings vs numbers, so that's something you'd be used to thinking about already. Probably not a huge gotcha.

Edit: these things are weird though. https://docs.perl6.org/type/IntStr

To clarify, it isn't being used as a set literal. It's a list passed to an operator that happily coerces your lists to sets.

Allomorphs are tricky things, but I think it was the right decision to treat them separately in collections.

`Set.new(42, 55, 1)` is the most formal way to create a new set, but Perl 6 provides `set(42, 55, 1)` as a shorthand.

I stared at

  .put for @wanted.combinations.grep: { $materials ≽ [⊎] |$^stuff-we-want };

and the preceding lines for some time, and then read the description, clicked through a few of the links on the different operators and read the explanations of those, and then I finally understood what was happening here. I worry, though, that at this point in my life I would either 1) never be able to remember all this stuff; 2) even if I could remember it, never be in a position where it would dawn on me that whatever I was trying to do was a good fit for it.

Yeah, as someone whose go to languages are C++, Scala and Ruby[1], it's awesome that Perl 6 does so much[2], but I think I'd have a hard time keeping track of it all.

[1] Meaning I like having lots of features in my toolbox.

[2] And, amazingly, Rakudo is a pretty compact executable compared to most other langs.

I really like all the built-in functionality. As long as the doc is good I can live with the complexity.

Consistency of inconsistency would be nice. For example, I don't see why Set "values" should ever be exposed anywhere, since the semantics of the collection type don't include them. Seems like a great big gotcha waiting to happen.

> Seems like a great big gotcha waiting to happen.

In Perl? Never!

Where are they, "exposed". The post just says the values are always true and that you don't really need to care about them.

From the post:

> Set types always have True as values, and since we don’t care about iterating over Pair objects in our loop, we use the keys [function] to get just the keys of the set: the email addresses.

The impression I took away from that was that you needed to make sure to pass keys(@set) rather than just @set in the operator, or else you'd get weirdness in the result. Having just installed Rakudo and fired up a REPL to find out for myself what'd happen, I find:

- that my understanding from the post was erroneous

- that there's some kind of weird set/string coercion going on that isn't replicable in the terms the REPL uses to describe it

- that the given examples do not reliably generalize

- that nothing which seems to make sense actually works

- that nothing which seems to work actually makes sense

- that I'm now bleeding slightly from both caruncles.

Having not closely followed the Perl 6 development process, I am very glad to see it has taken on board the frequently uttered and extremely well justified criticism of Perl 5 that it's not consistent enough, and that there are so many syntactic and semantic special cases that no one who doesn't heavily specialize in the language can use it very reliably.

What are your expectations for reliable generalization? What were you expecting to work, in what way, that didn't work as you expected?

The Rakudo REPL apparently doesn't save history outside a session by default, so I don't have the exact details of what I was trying to do. In attempting to recreate it, though, I did manage to discover that Perl 6 "sets" appear simply to be syntactic sugar around strings split on whitespace, except when they're not, sometimes. That's not necessarily a bad thing, but why call it a type? What is it actually giving me that I can't get without having to bind and learn to use a whole new keymap full of exciting Unicode characters that I'm not a mathematician and therefore will also need to learn to identify on sight?

I've never used a Unicode operators myself and there are no requirements to use Unicode characters. Every Unicode operator has a "Texas" counterpart in 100% ASCII. This was mentioned in the OP.

I think you are mistaking `<a b c d>` with a `Set`. `< >` is a shorthand for "give me a `List` of these words" (or in this case, characters). `<a b c d>.Set` would coerce you a `Set` from that list. The set operators coerce by default, so you can pass it a list of words without requiring you to coerce it yourself beforehand.

Yeah, I cottoned to that eventually - it's short(er)-hand for Perl 5's qw() construct. I guess Set is a method (coercer!) of...lists? List-shaped things? Sets seem list-shaped, although indexing doesn't work by any syntax I could find, and certainly not by any that an @ sigil should suggest. Can I call Set on a set? Does it do something weird if I do? And if I'm going to deal with this kind of high weirdness, why not just bite the bullet and go with Haskell or even Urbit? This just feels like it's trying to out-Ruby Ruby, and Ruby is Ruby enough already.

The OP had some snark to offer on the subject of "Texas" operators, and the documentation lists them by their Unicode glyphs. That they work I get. But I think it's reasonable to gather a sense of second-class citizenship from their presentation.

What "high weirdness"? Sets in most languages that have them do not support indexing, because they're usually understood to be unordered. Aside from that, there is a method to convert a list to a set. What are you confused about?

Yes, in mathematics sets are by definition unordered, so it would be strange to have a language that supported indexing of a set.

It's fun to answer questions that could be easily answered with a single invocation, but here goes: coercing a set ($set.Set) is a no-op.

my $set-of-sets = set $set;

The above will create a new set with $set as its only member.

I'm curious, did you read any documentation on sets and bags before experimenting, e.g., https://docs.perl6.org/language/setbagmix

Are things not working as described by that documentation?

I didn't know that the Advent calendar post I read had a prerequisite! That would've been a useful thing for someone to have mentioned.

Having read that documentation, I don't believe I saw anything inconsistent with it. I also really don't see what I'm getting here that I can't have in any language with basic collection types, and this is the only language I've ever run across that really wants me to buy new keycaps, which seems like a rather bold UI design choice.

While it might feel like the fancy unicode operators are encouraged in documentation or posts about Perl6, every fancy unicode has a corresponding operator in simple ASCII. The operator in question earlier in this thread '∈' is the same as using '(elem)' (including the parens). So '42 (elem) (12 42 56)' is the same as '42 ∈ (12 42 56)'.

No need for new keycaps :)

Well yeah, but who doesn't want to be rocking a space-cadet MacBook?

It's not that I can't extend Emacs to support typing those glyphs, or that I can't learn to type them without seeing the actual symbols on my keys. It's that I do not understand what justifies all this mental effort, when any language gives me the same capabilities in a fashion that, while slightly more verbose, is much easier actually to use.

The ability to perform native operations on collections is really nice, I agree. But Perl 6 isn't the only language that has it, either. From what I've seen today, it looks like Haskell without the rigor. Maybe that makes it easier to approach, but Perl 5 has long since taught me to mistrust such appealing shortcuts for the long-term cost they impose.

So are you complaining that Perl 6 allows Math majors to use the Unicode operators that they are used to, and that work the way they would expect?

Also all of the Set/Bag/Mix ASCII equivalents are fairly easy to remember or to guess once you know that they all have parens around them. ( as in guess how to spell it, and guess what it does )

  (elem) left value is an element of the right value
  (cont) left value contains the right value ( dual of previous )
  (|)    returns a superset of both sides ( or )
  (&)    returns a set of values that are on both sides ( and  )
  (-)    set that contains the values that are on the left but not the right ( minus )
  (^)    set that contains the values that are only on one side ( xor )

  (<=)   left value is a subset or equal to right value ( less than or equal to )
  (<)    left value is only a subset of right value ( less than )
  (>=)   (>)   duals of previous two

  (.)    multiset multiplication ( looks a bit like the Unicode version )

  (+)    Bag/Mix addition

  (<+)   left value has fewer or equal numbers than right value ( Bag less than or equal )
  (>+)   left value has more or equal numbers than right value ( Bag greater than or equal )


   < a B     > (<+) <a B B c> # True
   < a B B   > (<+) <a B B c> # True
   < a B B B > (<+) <a B B c> # False
   < a d     > (<+) <a B B c> # False

The ones with + all can be thought of as counting variations of the or equal operators.

The only one I would really complain about is the multiplication one, and there is nothing stopping someone from doing this:

  my &infix:< (*) > := &infix:< (.) >;

If you really don't like them, don't use them. I mean they are mostly wrappers around other functionality anyway https://github.com/rakudo/rakudo/blob/nom/src/core/set_opera...

  proto sub infix:<(elem)>($, $ --> Bool) is pure {*}
  multi sub infix:<(elem)>($a, Any $b --> Bool) {
      $a (elem) $b.Set(:view);
  }
  multi sub infix:<(elem)>($a, Set $b --> Bool) {
      $b.EXISTS-KEY($a); # internal method for implementing $b{ $a } :exists
  }

In general, [Perl operators] do what you want, unless you want consistency. — man perlfunc (of Perl5)

I thought I remembered hearing part of the idea with Perl 6 was that there'd be less of that. Apparently I have mistaken a forlorn hope for a vague memory.

those hyper operators...

One of the best punny titles I've ever heard. Well done. Really well done.

Reply on news.ycombinator.com