В ходе последних работ из подземелья вылезли новые фичи, какие то уже обсуждали, какие то нет, хотел все это обобщить и сделать маленький обзор, что знаю. Скоро будет полный релиз 1.1 где все это будет уже в обертке и надеюсь с ченджлистом, и обзором что было сделано. Так пока самые интересные фичи обрисую:

Основной список улучшений, по порядку появления:

1) исправлены горы багов для конвертации С# в Nemerle, для этого внедрены многие похожие фичи
2) поддержка слова sizeof для основных примитивных типов, включая decimal
3) сделана поддержка поведения partial как в C#
4) сделана возможность объединять строки с другими типами через +
5) полная поддержка параметров по умолчанию в квазицитатах
6) возможность избегать ключевого слова where в паттерн матчинге (для классов, интерфейсов, базовых вариантов)
7) улучшен макрос StructureEquality, для поддержки вариантов и избавлен от боксинга типов
8) поддержка маленьких букв для классов (всех типов кроме вариантов) в ПМ
9) исправлен баг при использовании лямбд в качестве параметров по умолчанию в локальных функциях

---

Хочется поговорить о них подробней:

1) Сначала хочется поговорить о конвертации C#. Влад во всю трудится чтобы один большой проект на C#, был переведен на Nemerle, там такие горы кода что было исправлено очень много багов и теперь поддержка C# на более новом уровне.

2) В связи с этим добавлен макрос sizeof поведение которого аналогично оператору sizeof для обычных типов

3)
Поведение partial теперь такое же как в C#
раньше такой код давал ошибки:

partial public class HU { }
partial class HU { } // E: joined partial classes `HU' must have compatible modifiers

теперь это возможно:

partial public class HU { }
partial class HU { } // It's OK. See 10.2.2 Modifiers of C# spec.

хотя такой по прежнему ошибка:

partial public class HU { } // H: part with incompatible modifiers
partial internal class HU { } // E: joined partial classes `HU' must have compatible modifiers

4) Интересная фича, на что многие жаловались что нельзя сложить строку с примитивным типом, например:

"ABC" + 3

хотя эта фича теряет цвет на фоне сплайс строк, но тем не менее она есть.

5) Раньше не очень хорошо работали квазицитаты с параметрами по умолчанию, сам не раз натыкался на это, теперь и создание квазицитат с параметрами по умолчанию и матчинг подобных цитат, работает как ожидается:

def parm = <[parameter: public $(name : usesite) : int = 0 ]>;

match (parm)
{
 | <[parameter: ..$attr $(n : name) : $ty = $deflt ]> => // do something
}
def parms = parm :: [];
def ty = typebuilder.Define(<[ public Func(..$parms) {} ]>);

6) Интересная фича позволяющая сильно сократить код, использующий ПМ, опускание слова where, о ней уже было немало говорено. На фоне вариантов, объявление классов могло быть очень нагруженным и мешало декларативности их описания, раньше, приходилось писать так:

| Class where (field = SubClass where (field2 = A, fieldb = C))) =>

теперь возможно так:

| Class(field = SubClass(A, C))) =>
| ISomeInterface(Property = a) => // можно тестировать свойства интерфейса

к возможным типам использующим этот синтаксис принадлежат interface, class, enum, variant (базовый класс), с ними работают все паттерны, конструктор, record и другие. Старый синтаксис для совместимости работает.

7) Влад поправил макрос StructureEquality который стал поддерживать варианты и стал более оптимизирован, ранее было использование боксинга при сравнении полей примитивных типов, теперь это исправлено.

8) Для полной поддержки различных типов в ПМ, была внесена возможность использования маленьких букв в паттерн матчинге, наряду с большими:

| A        => // как тип
| x        => // как переменная
| A(a, b)  => // как конструктор с присвоением двух полей переменным
| a(x, y)  => // здесь a также подразумевается тип, и x y поля
| A as var => // обычный as паттерн
| a as var => // а также тип
| x is A   => // is паттерн
| x is a   => // маленькие буквы работают

9) Исправлен досадный баг который исправил параметры по умолчанию в локальных функциях, например такой код давал ошибку:

def func(a, b = () => true)
{
}

func("123");
func("123");

это было поправлено.

Ну авторы соответствующих коммитов могут сделать если захотят более подробные описания, я как успел на боевых листках записал описания Влада что он сделал, со своими и других изменениями, с последней полевой почтой отправляю на форум. Как смог попытался донести, чтобы объединить все что сделано в некий список с разъяснениями. Буду рад если кому будет это полезно.

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

CU>4) сделана возможность объединять строки с другими типами через +
CU>4) Интересная фича, на что многие жаловались что нельзя сложить строку с примитивным типом, например:

Это только для C# или в N-коде тоже работает?? Если второе — то, ИМХО, зря, ничего хорошего в ней нет, тока неочевидные глюки появляются: WriteLine("Да смерти: " + this.Birthday + this.Age)

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

CU>>4) сделана возможность объединять строки с другими типами через +
CU>>4) Интересная фича, на что многие жаловались что нельзя сложить строку с примитивным типом, например:

J>Это только для C# или в N-коде тоже работает?? Если второе — то, ИМХО, зря, ничего хорошего в ней нет, тока неочевидные глюки появляются: WriteLine("Да смерти: " + this.Birthday + this.Age)

Врядли это можно было сделать только для C# кода. Парсер C# всего лишь строит аналогичный AST Nemerle.

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

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

CU>>4) сделана возможность объединять строки с другими типами через +
CU>>4) Интересная фича, на что многие жаловались что нельзя сложить строку с примитивным типом, например:

J>Это только для C# или в N-коде тоже работает?? Если второе — то, ИМХО, зря, ничего хорошего в ней нет, тока неочевидные глюки появляются: WriteLine("Да смерти: " + this.Birthday + this.Age)

Работает в N коде
Полностью согласен "фича" плоха для Nemerle.

Пусть в C# и остается, а в Nemerle этого не надо.

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

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

CU>>4) сделана возможность объединять строки с другими типами через +
CU>>4) Интересная фича, на что многие жаловались что нельзя сложить строку с примитивным типом, например:

J>Это только для C# или в N-коде тоже работает?? Если второе — то, ИМХО, зря, ничего хорошего в ней нет, тока неочевидные глюки появляются:

Это для N, но тут я мало что могу сказать, Влад это сделал для совместимости с C#, при переводе проекта, хотя вроде сам не жаловал подобные решения. Ну вопросы к нему, что он сам скажет...

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

J>Это только для C# или в N-коде тоже работает?? Если второе — то, ИМХО, зря, ничего хорошего в ней нет, тока неочевидные глюки появляются: WriteLine("Да смерти: " + this.Birthday + this.Age)

Чтобы сделать все красиво — т.е. только для C# необходима возможность работать с типизатором. В рамках N1 это сложно (для всех сложений необходимо генерировать обращение к макросу), видимо проще было захардкодить в компилятор.

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

H>Чтобы сделать все красиво — т.е. только для C# необходима возможность работать с типизатором. В рамках N1 это сложно (для всех сложений необходимо генерировать обращение к макросу), видимо проще было захардкодить в компилятор.
Я считаю что в данном случае лучше переделать на макрос.

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

J>>Это только для C# или в N-коде тоже работает?? Если второе — то, ИМХО, зря, ничего хорошего в ней нет, тока неочевидные глюки появляются: WriteLine("Да смерти: " + this.Birthday + this.Age)

_NN>Работает в N коде
_NN>Полностью согласен "фича" плоха для Nemerle.

_NN>Пусть в C# и остается, а в Nemerle этого не надо.

Это конечно мое имхо, но большого вреда я в этом не вижу. В немерле все равно так никто не пишет, все пользуются сплайсами, вероятность поиметь там проблемы минимальная. В смысле фича скорее вредная, чем полезная, но если избавиться от нее сложно — пусть живет, не критично, максимум warning давать, для C# проектов его можно отключить.

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

H>>Чтобы сделать все красиво — т.е. только для C# необходима возможность работать с типизатором. В рамках N1 это сложно (для всех сложений необходимо генерировать обращение к макросу), видимо проще было захардкодить в компилятор.
WH>Я считаю что в данном случае лучше переделать на макрос.

  macro @+?(expr1 : PExpr, expr2 : PExpr)
  {
    MyPlusImpl.DoTransform(Macros.ImplicitCTX(), expr1, expr2)
  }
  
  module MyPlusImpl
  {
    public DoTransform(typer : Typer, expr1 : PExpr, expr2 : PExpr) : PExpr
    {
      Macros.DefineCTX(typer);
      
      typer.DelayMacro(_ =>
      {
        def tExpr1 = typer.TypeExpr(expr1);
        def tExpr2 = typer.TypeExpr(expr2);
        match (tExpr1.Type.Hint, tExpr2.Type.Hint)
        {
        | (Some(ty1), Some(ty2)) =>
            def sType = <[ ttype: System.String ]>; 
            def res = match(ty1.Equals(sType), ty2.Equals(sType))
            {
                | (true, false) => <[ $expr1 + $expr2.ToString() ]>
                | (false, true) => <[ $expr1.ToString() + $expr2 ]>
                | _ => <[ $expr1 + $expr2 ]>
            }
            Some(res)
        | _ => None()
        }
      })
    }
  }
  
  //...
  WriteLine(1.23 +? " Hi!");

Просьба попинать

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

Z>Это конечно мое имхо, но большого вреда я в этом не вижу. В немерле все равно так никто не пишет, все пользуются сплайсами, вероятность поиметь там проблемы минимальная. В смысле фича скорее вредная, чем полезная, но если избавиться от нее сложно — пусть живет, не критично, максимум warning давать, для C# проектов его можно отключить.

Если это единственное решение, то предупреждение будет лучшим вариантом.

Хотя тут

Автор: artelk
Дата: 17.01.12

возможно предлагается решение этой проблемы.

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

Предлагаю: назвать это ~~ .

+? по аналогии с ?. , ассоциируется с чем-то:

a +? b => if (a != null) a + b else default(typeof(a + b))

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

_NN>Работает в N коде
_NN>Полностью согласен "фича" плоха для Nemerle.

_NN>Пусть в C# и остается, а в Nemerle этого не надо.

К сожалению, это невозможно. Максимум можно попытаться ворнинг прикрутить.

Но учитывая, что в шарпе от нее никто не страдает, не вижу в этом смысла.

Правильным подходом в изучении новых фич и закрытых багов является просмотр issues на GitHub-е.

Список новых фич
Список исправленных багов
Список баг и фич связанных с VS 2010 (пересекается с остальными спискам приведенным выше)

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

VD>Правильным подходом в изучении новых фич и закрытых багов является просмотр issues на GitHub-е.

Человеку за частую нужны простые фишки. А читать целый день исуе не так прикольно

А это сделали? http://www.rsdn.ru/forum/nemerle/4278101.1.aspx

Автор: Ka3a4oK
Дата: 20.05.11

Здравствуйте, Аноним, Вы писали:

А>Человеку за частую нужны простые фишки. А читать целый день исуе не так прикольно

Что там читать то? Пробежать глазами список и все.

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

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

_NN>Предлагаю: назвать это ~~ .

Либо я не понял смысл, либо одно из двух.
Какая разница, как этот макрос будет называться? Он же в пользовательском коде нигде не должен вызываться, это утилитарный макрос чисто для поддержки C# кода. А вызов макроса будет генериться пег-парсером, соответственно он даже не обязан быть оператором.

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

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

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

_NN>>Предлагаю: назвать это ~~ .

J>Либо я не понял смысл, либо одно из двух.
J>Какая разница, как этот макрос будет называться? Он же в пользовательском коде нигде не должен вызываться, это утилитарный макрос чисто для поддержки C# кода. А вызов макроса будет генериться пег-парсером, соответственно он даже не обязан быть оператором.

Подумалось, что макрос может быть полезен в Nemerle для автоматического вызова ToString() как альтернатива $"".

$"$(F(a))$(G(b))$(H(c))" <=> F(a) ~~ G(b) ~~ H(c)

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

KK>А это сделали? http://www.rsdn.ru/forum/nemerle/4278101.1.aspx

Автор: Ka3a4oK
Дата: 20.05.11

Сделали только то, что перечислено здесь

Автор: VladD2
Дата: 17.01.12

.

С отслеживанием переходов все по прежнему печально. Но как показала практика такого кода в проектах на шарпе не так много. В проекте IT (Булките) было всего два метода, которые было проще переписать.

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

_NN>Пусть в C# и остается, а в Nemerle этого не надо.

Сделать данную фичу качественно в виде макроса вряд ли получится. Дело в том, что операторы сами по себе влияют на вывод типов. И если откладывать вывод типов операторов, то куча кода не сможет вывестись.

Плюс отсутствие данной фичи в Н приводит к тому, что те кто только что перешли с Шарпа испытывают дискомфорт.

Учитывая, что я не слышал об ошибках вызванных таким поведением оператора + в шарпе, я решил не заморачиваться и реализовать фичу прямо в компиляторе Н.