5 ms·

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

• throwanem 10y ago
  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.
  • FreezerburnV 10y ago
    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 :)
    • labster 10y ago
      Well yeah, but who doesn't want to be rocking a space-cadet MacBook?
    • throwanem 10y ago
      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.
      • b2gills 10y ago
        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_operators.pm 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 }