В статье Язык Nemerle Часть 3

Автор(ы): Чистяков Владислав Юрьевич
Дата: 25.07.2010
Неформальное введение в язык программирования Nemerle. В этой части, на базе примера «калькулятор», описываются типы данных variant и class.

читаем:

Обратите внимание на то, что в образце «переменная» может использоваться любое имя, начинающееся с маленькой буквы или подчеркивания (большую букву в образцах компилятор Nemerle рассматривает как имя типа).

Из этого следует, что Немерль имеет регистрозависимую семантику. Эта регистрозависимая семантика ложится на регистронезависимую семантику НЕТа. Естественно, эта несогласованность где-то должна вылезти.

Идентификатор с маленькой буквы в ПМ считается связанной переменной. Давайте сделаем вариант с маленькой буквы и попробуем его скормить ПМ.

  public variant V1
  {
    | field1
    | field2
  }

Опа! Немерль не пропускает и выдает нам ошибку:

variant options' names must start with capital letter

Интересно, эта фича известна в широких кругах немерлистов?

Итак, с вариантами фокус не прошел. А как с перичислениями? Заметьте, что вводить для перечислений внутренние правила Немерля бессмысленно, так как перечисление может быть импортировано. А там оно подчиняется правилам НЕТа, согласно которым исполнение программы не зависит от регистра букв идентификатора.

namespace Test1
{
  using MBox = System.Windows.Forms.MessageBox;

  public enum E1
  {
    | field1
    | field2
  }

  public module Lang
  {
    public Test(e: E1): string
    {
    | field1 => "field1"
    | field2 => "field2"
    }
    
    Main(): void
    {
      _ = MBox.Show(Test(E1.field1));
      _ = MBox.Show(Test(E1.field2));
    }
  }
}

Результатом исполнения программы будет вывод два раза "field1". Это говорит о том, что идентификатор field1 в ПМ понимается Немерлем как связанная переменная.

А теперь меняем буковку f на большую F:

namespace Test1
{
  using MBox = System.Windows.Forms.MessageBox;

  public enum E1
  {
    | Field1
    | Field2
  }

  public module Lang
  {
    public Test(e: E1): string
    {
    | Field1 => "Field1"
    | Field2 => "Field2"
    }
    
    Main(): void
    {
      _ = MBox.Show(Test(E1.Field1));
      _ = MBox.Show(Test(E1.Field2));
    }
  }
}

Получается вывод "Field1", "Field2". Теперь Немерль понимет Field1 как элемент перечисления.

Вот такие дела.

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

CE>Итак, с вариантами фокус не прошел. А как с перичислениями? Заметьте, что вводить для перечислений внутренние правила Немерля бессмысленно, так как перечисление может быть импортировано.
В .NET перечислению можно дать такое имя, которое вообще не будет идентификатором по правилам Nemerle и даже C#.
Или, например, в C# можно задать такое имя, которое невозможно использовать из VB.NET, и наоборот.

CE>А там оно подчиняется правилам НЕТа, согласно которым исполнение программы не зависит от регистра букв идентификатора.
Тут не исполнение, а компиляция программы зависит от регистра. А у .NET нет никаких правил на этот счет.

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

CE>

CE>Обратите внимание на то, что в образце «переменная» может использоваться любое имя, начинающееся с маленькой буквы или подчеркивания (большую букву в образцах компилятор Nemerle рассматривает как имя типа).

CE>Из этого следует, что Немерль имеет регистрозависимую семантику.

Вообще-то в цитате все сказано довольно однозначно. В паттерне "переменная" имя должно начинаться с маленькой буквы. Ригистро-звисимый немерл по умолчанию. Это наследие С.

CE>Эта регистрозависимая семантика ложится на регистронезависимую семантику НЕТа. Естественно, эта несогласованность где-то должна вылезти.

Nikov очень правильно заметил, что у "НЕТа" нет никакой семантики. В дотнете допустимы (да поправит меня nikov, если я ошибаюсь) любые юникодные символы. Этим, например, пользуются многие компиляторы для создания имен временных переменных и полей замыканий. Они могут иметь имена недопустимые с точки зрения C#.
Так что корректнее было бы говорить о соглашении об именовании конкретных языков (C#, C++, VB, ...).
Там где речь идет о классах — т.е. сущностных которые есть в C#, то по возможности принимаются его соглашения об именовании.

Что касается именования вариантов, то тут берутся традиции языков линейки ML. Сделано это чтобы не изобретать новых правил при работе с сопоставлением со образцом.

CE>Идентификатор с маленькой буквы в ПМ считается связанной переменной. Давайте сделаем вариант с маленькой буквы и попробуем его скормить ПМ.

CE>

CE>  public variant V1
CE>  {
CE>    | field1
CE>    | field2
CE>  }
CE>

CE>Опа! Немерль не пропускает и выдает нам ошибку:

CE>

CE>variant options' names must start with capital letter

Ага. Вот такие правила. И оно совпадает со всеми правилами форматирования кода используемыми для дотнета, где типы рекоментуется называть с большой буквы.

CE>Интересно, эта фича известна в широких кругах немерлистов?

Она описана в всех учебных пособиях (например, в Grokking Nemerle), плюс мимо компилятора не пройдешь. Он точно остановит. Так что все любители нестандартного форматирования об этом ограничении знать обязаны.

Ну, а возмущенных возгласов нет просто потому, что это требование совпадает с принципами форматирования кода принятыми в среде дотнет-программистов (да и не только).

CE>Итак, с вариантами фокус не прошел. А как с перичислениями? Заметьте, что вводить для перечислений внутренние правила Немерля бессмысленно, так как перечисление может быть импортировано. А там оно подчиняется правилам НЕТа, согласно которым исполнение программы не зависит от регистра букв идентификатора.

Еще раз. Нет никаких правил "НЕТа".
И таки, да для перечислений таких ограничений нет именно потому, что они могут быть импортированы откуда угодно. Но опять же практически везде значения перечислений так же описывается с большой буквы в следствии применения правил форматирования.

CE>

CE>namespace Test1
CE>{
CE>  using MBox = System.Windows.Forms.MessageBox;

CE>  public enum E1
CE>  {
CE>    | field1
CE>    | field2
CE>  }

CE>  public module Lang
CE>  {
CE>    public Test(e: E1): string
CE>    {
CE>    | field1 => "field1"
CE>    | field2 => "field2"
CE>    }
    
CE>    Main(): void
CE>    {
CE>      _ = MBox.Show(Test(E1.field1));
CE>      _ = MBox.Show(Test(E1.field2));
CE>    }
CE>  }
CE>}
CE>

CE>Результатом исполнения программы будет вывод два раза "field1". Это говорит о том, что идентификатор field1 в ПМ понимается Немерлем как связанная переменная.

Прежде всего результатом будет два предупреждения:

Main.n(24,9):Warning: N168: a value bound in pattern field1 was never used
Main.n(24,9):Warning: hint: replace name with '_' or prefix it like '_bar' to avoid the warning

Main.n(25,9):Warning: N168: a value bound in pattern field2 was never used
Main.n(25,9):Warning: this match clause is unused

Так что если не игнорировать предупреждения (а в немерле — это категорически не стоит делать), то совершить подобную ошибку случайно будет очень сложно.

Меж тем исправить код, так чтобы он работал как предполагается совсем не сложно. Нужно просто задать квалифицированное имя для полей перечисления:

public Test(e: E1): string
{
  | E1.field1 => "field1"
  | E1.field2 => "field2"
}

CE>А теперь меняем буковку f на большую F:...
CE>Получается вывод "Field1", "Field2". Теперь Немерль понимет Field1 как элемент перечисления.

И что характерно, в соответствии со спецификацией, по которой в паттернах с маленькой буквы производится связывание переменных.

Более того, насколько мне известно эти соглашения используются во всех клонах ML (к которым принадлежит и Nemerle). Например, F# так же придерживается этих соглашений. Если попытаться назвать вхождение Discriminated union с маленькой буквы, то получишь сообщение об ошибке: "error FS0053: Discriminated union cases and exception labels must be uppercase identifiers".

CE>Вот такие дела.

Ага. Век живи, век учись.

VD>Ага. Век живи, век учись.

Раскритиковали в пух и прах.