Наткнулся на странную проблему связанную с списками. Она выявляется в виде match_failure_exception в неожиданном месте. Долго пытался понять почему вызов метода Iter на списке дает это исключение и понял что все дело в том, что если список создается с помощью складывания например так:

class Test
{
  data : list[int];

  Add(d : int) : void
  {
    data ::= d;
  }

  Add(lst : list[int]) : void
  {
    data=data+lst;
  }
}

то если список в классе был null, то NRE не будет выдано, список нормально создастся, но после когда перебирать его элементы, например так:

data.Iter(SomeFunc);

в конце будет выдано исключение match_failure потому что ему не нравится два варианта match в Iter:

public Iter[T] (l : list [T], f : T -> void) : void 
{
  match (l) 
  {
    | x :: xs => f (x); Iter (xs, f)
    | [] => ()
  }
}

на месте где список по идее должен быть пустым, он дает match_failure, это лечится или если переписать Iter с случаем
|_ => () или не делать складывания списка c null, тоже происходит и во всех остальных функциях работы со списками

По моему мнению это баг, если список null он просто должен интерпретироваться как пустой и создаваться на основе другого аргумента при складывании. Кто нибудь может помочь в поиске проблемы в компиляторе, известна ли доныне эта проблема?

Здравствуйте, CodingUnit, Вы писали:

CU>то если список в классе был null, то NRE не будет выдано, список нормально создастся, но после когда перебирать его элементы, например так:

Полагаю что это в операторе сложения, раз он пропускает null.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, CodingUnit, Вы писали:

CU>>то если список в классе был null, то NRE не будет выдано, список нормально создастся, но после когда перебирать его элементы, например так:

H>Полагаю что это в операторе сложения, раз он пропускает null.

В операторе сложения используется Append и RevAppend, но они почему то пропускают null, там везде используется синтаксис создания списка a :: tail, он наверное где то внутри компилятора находится, наверное там надо искать ошибку, я еще пока не знаю где это можно найти, может кто нибудь поправить, список все таки такая часто используемая вещь.

Здравствуйте, CodingUnit, Вы писали:

CU>В операторе сложения используется Append и RevAppend, но они почему то пропускают null, там везде используется синтаксис создания списка a :: tail, он наверное где то внутри компилятора находится, наверное там надо искать ошибку, я еще пока не знаю где это можно найти, может кто нибудь поправить, список все таки такая часто используемая вещь.
Тут есть два способа это поправить:
1)Кидать исключение.
2)Считать что null == [].
Думаю правильно кидать исключение.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, CodingUnit, Вы писали:

CU>>В операторе сложения используется Append и RevAppend, но они почему то пропускают null, там везде используется синтаксис создания списка a :: tail, он наверное где то внутри компилятора находится, наверное там надо искать ошибку, я еще пока не знаю где это можно найти, может кто нибудь поправить, список все таки такая часто используемая вещь.
WH>Тут есть два способа это поправить:
WH>1)Кидать исключение.
WH>2)Считать что null == [].
WH>Думаю правильно кидать исключение.

Если кидать каждый раз исключение, то придется постоянно проверять если список null, то присваивать [], если до сих пор вариант со сложением с null списком проходит, значит так задумали сами разработчики, только при этом вести себя он должен правильно, я бы был рад если бы он просто складывался и не давал потом глюков, тогда создавать их было бы проще.

---

от макросов до вариантов
и массой всяких преимуществ
благодаря nemerle-братству
программеров жизнь стала лучше

Здравствуйте, CodingUnit, Вы писали:

CU>Если кидать каждый раз исключение, то придется постоянно проверять если список null, то присваивать [], если до сих пор вариант со сложением с null

У меня в планах посмотреть что там наваял Klapaucius для новой стандартной библиотеки (но это после того как я разделаюсь с типизацией атрибутов).
Сейчас же нужно в проблемных методах добавить [NotNull] контракт на аргументы.

Здравствуйте, CodingUnit, Вы писали:

CU>Если кидать каждый раз исключение, то придется постоянно проверять если список null, то присваивать [], если до сих пор вариант со сложением с null списком проходит, значит так задумали сами разработчики, только при этом вести себя он должен правильно, я бы был рад если бы он просто складывался и не давал потом глюков, тогда создавать их было бы проще.

Все что нужно в твоем примере — это проинициализировать поле:

class Test
{
  data : list[int] = [];

  Add(d : int) : void
  {
    data ::= d;
  }

  Add(lst : list[int]) : void
  {
    data=data+lst;
  }
}

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, CodingUnit, Вы писали:

CU>>Если кидать каждый раз исключение, то придется постоянно проверять если список null, то присваивать [], если до сих пор вариант со сложением с null списком проходит, значит так задумали сами разработчики, только при этом вести себя он должен правильно, я бы был рад если бы он просто складывался и не давал потом глюков, тогда создавать их было бы проще.

VD>Все что нужно в твоем примере — это проинициализировать поле:
VD>

VD>class Test
VD>{
VD>  data : list[int] = [];

VD>  Add(d : int) : void
VD>  {
VD>    data ::= d;
VD>  }

VD>  Add(lst : list[int]) : void
VD>  {
VD>    data=data+lst;
VD>  }
VD>}
VD>

Хорошо, большинство считает что нужно инициализировать поле [] и кидать исключение при null, пусть будет так, но тогда надо добавить не только NotNull контракты, но и сделать проверку в операторе создания списка head :: tail, он тоже может присоединяться к null списку

Здравствуйте, CodingUnit, Вы писали:

CU>Хорошо, большинство считает что нужно инициализировать поле [] и кидать исключение при null, пусть будет так, но тогда надо добавить не только NotNull контракты, но и сделать проверку в операторе создания списка head :: tail, он тоже может присоединяться к null списку

Fork/Pull request в Github уже освоил? Если — да, то делай пул-реквест с изменениями. Если — нет, то осваивай. Теперь это самое важное умение.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, CodingUnit, Вы писали:

CU>>Хорошо, большинство считает что нужно инициализировать поле [] и кидать исключение при null, пусть будет так, но тогда надо добавить не только NotNull контракты, но и сделать проверку в операторе создания списка head :: tail, он тоже может присоединяться к null списку

VD>Fork/Pull request в Github уже освоил? Если — да, то делай пул-реквест с изменениями. Если — нет, то осваивай. Теперь это самое важное умение.

Github осваиваю, с контрактами понятно, но head :: tail синтаксис наверное где то глубоко в компиляторе, это я не знаю где делается. Хорошо бы кто нибудь из знающих пофиксил.

Здравствуйте, CodingUnit, Вы писали:

CU>Github осваиваю, с контрактами понятно, но head :: tail синтаксис наверное где то глубоко в компиляторе, это я не знаю где делается. Хорошо бы кто нибудь из знающих пофиксил.

Синтаксис тут ни при чем. Нужно добавить явный конструктор варианте list:

variant list[T]
{
  | Cons
  {
    public new this(value : T, [NotNull] tail : list[T])
    {
      this.value = value;
      this.tail = tail;
    }
  }
...
}

Здравствуйте, CodingUnit, Вы писали:

CU>Github осваиваю, с контрактами понятно, но head :: tail синтаксис наверное где то глубоко в компиляторе, это я не знаю где делается. Хорошо бы кто нибудь из знающих пофиксил.

Это называется глубоко в компиляторе ?

Здравствуйте, _nn_, Вы писали:

__>Здравствуйте, CodingUnit, Вы писали:

CU>>Github осваиваю, с контрактами понятно, но head :: tail синтаксис наверное где то глубоко в компиляторе, это я не знаю где делается. Хорошо бы кто нибудь из знающих пофиксил.

__>Это называется глубоко в компиляторе ?

Ну значит проще чем предполагалось, совместными командными усилиями