Вы ошиблись в середине. Важная часть - это то, с чем вызывается nqp::existskey: k.WHICH. Этот метод предназначен для типов значений, то есть неизменяемых типов, где значение, а не идентичность, определяет, должны ли две вещи быть одним и тем же (даже если они созданы дважды). Он возвращает строковое представление значения объекта, равного для двух вещей, которые должны быть равны. За <1>.WHICH вы получаете IntStr|1, а за 1.WHICH вы получаете только Int|1.

Как объясняется в документации Set, устанавливает идентичность объекта сравнения, как и _ 1_ оператор:

Внутри Set каждый элемент гарантированно уникален (в том смысле, что никакие два элемента не будут положительно сравниваться с оператором ===)

Идентичность объекта определяется методом .WHICH, как поясняет Тимотимо в своей отвечать.

Напишите свой список чисел, используя запятые

Как вы упомянули в своем ответе, ваш код работает, если вы пишете свои числа в виде простого списка, разделенного запятыми, а не с помощью конструкции <...>.

Вот почему:

4 ∈ set 1, 2, 3, 4 # True

Пустой числовой литерал в коде, такой как 4 слева от ∈, создает одно значение с числовым типом. (В данном случае это целое число Int.) Если конструктор set получает список похожих литералов справа, тогда все работает нормально.

<1 2 3 4> создает список двойных значений.

Различные конструкции <...> цитируют слова, переворачивают список буквальных элементов, разделенных пробелами внутри угловые скобки в выходной список значений.

Базовый вариант (qw<...>) выводит только строки. Использование его в вашем случае не работает:

4 ∈ set qw<1 2 3 4> # False

4 слева составляет одно числовое значение типа Int. Тем временем конструктор set получает список строк типа Str: ('1','2','3','4'). Оператор ∈ не находит Int в наборе, потому что все значения равны Str, поэтому возвращает False.

Двигаясь дальше, вариант huffmanized <...> выводит Strs, если элемент не распознается как число. Если элемент распознается как число, то выходное значение - двойное значение. Например, 1 становится IntStr.

Согласно документу IntStr может использоваться взаимозаменяемо, где можно использовать Str или Int. Но может ли это?

Ваш сценарий - яркий тому пример. В то время как 1 ∈ set 1,2,3 и <1> ∈ set <1 2 3> работают, 1 ∈ set <1 2 3> и <1> ∈ set 1, 2, 3 оба возвращают False.

Таким образом, похоже, что оператор ∈ не соответствует заявлению процитированного документа о взаимозаменяемости двойных значений.

Это может быть уже признано ошибкой в ​​∈ операции установки и / или других операциях. Даже если нет, этот острый край двойного значения конструктора списка <...> может в конечном итоге рассматриваться как достаточно болезненный, что Perl 6 необходимо изменить.

Думаю, это баг, но не в наборе. Другие ответы очень помогли разобраться в том, что было важным, а что нет.

Я использовал форму кавычек в угловых скобках. Форма цитатных слов должна быть эквивалентна цитируемой версии (то есть True в eqv). Вот пример документа:

<a b c> eqv ('a', 'b', 'c')

Но когда я пробую это со словом, состоящим только из цифр, это не работает:

 $ perl6
 > < a b 137 > eqv ( 'a', 'b', '137' )
 False

Но другие формы работают:

> qw/ a b 137 / eqv ( 'a', 'b', '137' )
True
> Q:w/ a b 137 / eqv ( 'a', 'b', '137' )
True

В кавычках угловых скобок используется IntStr:

> my @n = < a b 137 >
[a b 137]
> @n.perl
["a", "b", IntStr.new(137, "137")]

Без кавычек слово цифр выглядит как [Str]:

> ( 'a', 'b', '137' ).perl
("a", "b", "137")
> ( 'a', 'b', '137' )[*-1].perl
"137"
> ( 'a', 'b', '137' )[*-1].WHAT
(Str)
> my @n = ( 'a', 'b', '137' );
[a b 137]
> @n[*-1].WHAT
(Str)

Обычно вы видите ошибки такого рода, когда есть два пути кода для получения окончательного результата, а не общий код, который очень рано сходится к одному пути. Это то, что я бы искал, если бы хотел отследить это (но мне нужно поработать над книгой!)

Однако это подчеркивает, что вы должны быть очень осторожны с наборами. Даже если эта ошибка была исправлена, есть и другие, не связанные с ошибками способы eqv могут выйти из строя. Я бы все равно потерпел неудачу, потому что 4 как Int не равно «4» как Str. Я думаю, что такой уровень внимания к типам данных неадекватен в DWIMery. Это определенно то, что мне пришлось бы очень осторожно объяснять в классе и при этом наблюдать, как все на этом не ладят.

Как бы то ни было, я думаю, что результаты gist имеют тенденцию вводить в заблуждение из-за их чрезмерного упрощения, а иногда результаты perl недостаточно богаты (например, скрытие Str, что вынуждает меня .WHAT). Чем больше я их использую, тем менее полезными я считаю их.

Но знание того, что я напортачил еще до того, как я начал, спасло бы меня от этой спелеологии кода, которая в конечном итоге ничего не значила!

Просто чтобы добавить к другим ответам и указать на согласованность здесь между наборами и хешами объектов .

Хэш объекта объявлен как my %object-hash{Any}. Этот метод эффективно хеширует объекты .WHICH, аналогично тому, как наборы различают отдельные элементы.

Подстановка набора хешем объекта:

my %obj-hash{Any};

%obj-hash< 1 2 3 4 > = Any;
say "hash: ", %obj-hash.keys.perl;
say "4 is in hash: ", %obj-hash{4}:exists;
say "IntStr 4 is in hash: ", %obj-hash{ IntStr.new(4, "Four") }:exists;
say "IntStr(4,...) is 4: ", IntStr.new(4, "Four") == 4;
say "5 is in hash: ", %obj-hash{5}:exists;

дает результаты, аналогичные вашему исходному примеру:

hash: (IntStr.new(4, "4"), IntStr.new(1, "1"), IntStr.new(2, "2"), IntStr.new(3, "3")).Seq
4 is in hash: False
IntStr 4 is in hash: True
IntStr(4,...) is 4: True
5 is in hash: False