Хотелось бы получить небольшое прояснение по текущему статусу разработки Nemerle 2

1) Когда ориентировочно планируется начать разработку Nemerle 2?
2) Будет ли какой-то публичный анонс с Roadmap разработки языка?
3) Через сколько примерно можно ждать релиза? (Если вообще возможно ответить на такой вопрос)

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

F_Z>1) Когда ориентировочно планируется начать разработку Nemerle 2?

Сразу как завершим работу над подсистемой связывания и получим ее бэту. Ориентировочно в конце сентября.

F_Z>2) Будет ли какой-то публичный анонс с Roadmap разработки языка?

Ближе к делу напишим. Но надо понимать, что мы просто будем воспроизводить Nemerle на новой технологической базе и высоком качестве. Из нового будет только неограниченная синтаксическая расширяемость и использование фичь Нитры в макросах (типизация и т.п.).

F_Z>3) Через сколько примерно можно ждать релиза? (Если вообще возможно ответить на такой вопрос)

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

Основной сложностью, в разработке Немерле 2, будет разработка DSL–я типизации выражений. Это может занять от 3 месяцев (моя оценка) до года (т.е. оценка умноженная на 4).

Nemerle 2 будет вестись параллельно, как "тестовый" проект для Nitra.

Проект будет опенсорс, так что можете принять участие в его разработке сократив время его разработки.

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

VD>мы просто будем воспроизводить Nemerle на новой технологической базе и высоком качестве

В итоге оставляете все странности и рудименты или берёте за основу синтаксиса C#?

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

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

VD>>мы просто будем воспроизводить Nemerle на новой технологической базе и высоком качестве

K>В итоге оставляете все странности и рудименты или берёте за основу синтаксиса C#?

Не надо синтаксиса C#.

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

K>В итоге оставляете все странности и рудименты или берёте за основу синтаксиса C#?

Если взять за основу синтаксиса C#, то и получится C#. Причем со всеми странностями и рудиментами (ц).

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

ЗЫ

О каких странностях и рудиментах идет речь?

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

VD>О каких странностях и рудиментах идет речь?
Знаменитая

.[]

Но вообще вам работы с нитрой хватит....
так что н2 вы займетесь никогда

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

VD>>О каких странностях и рудиментах идет речь?
s22>Знаменитая
s22>

s22>.[]
s22>

Это косяк. Его мы обязательно устраним. Еще претензии есть? Или речь о косяках?

s22>Но вообще вам работы с нитрой хватит....
s22>так что н2 вы займетесь никогда

Nitra — это средство для создания таких языков как Nemrle. Я взялся за нее именно потому что понял, что реализовать Nemrle 2 (или его аналог) без подобного средства крайне сложно и под силу лишь мега-корпорациям (а, по факту не под силу и им).

Так что работа над Nitra это и есть работа над Nemrle 2, но не только. Реализуя фичи Nitra мы делаем реализацию и поддержку фичей Nemrle 2 тривиальной. Второе, пожалуй, даже важнее. Реализовать фичу еще можно, но вот поддерживать ее в понятном состоянии без Nitra крайне сложно (практика Nemrle 1.х это отлично доказала).

Более того Nitra позволяет нам относительно просто создавать не один язык, а целые семейства и даже их иерархии.

Кроме того, я надеюсь, что в разработке Nemrle 2 примут участие люди не входящие в команду Nitra. Мы и сами справимся, но помощь лишней не будет.

VD>Nemerle 2 будет вестись параллельно, как "тестовый" проект для Nitra.

То есть Ваша команда в JetBrains будет заниматься его разработкой официально, а не в свободное от основной работы время?

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

F_Z>То есть Ваша команда в JetBrains будет заниматься его разработкой официально, а не в свободное от основной работы время?

Ну, не то что бы JetBrains будет официально развивать Nemerle, но, да, мы будем работать над ним в рабочее время.

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

VD>Ну, не то что бы JetBrains будет официально развивать Nemerle, но, да, мы будем работать над ним в рабочее время.

Рад слышать, значит у языка есть будущее
А почему JetBrains не планирует развивать Nemerle официально? Как Kotlin, к примеру.
Ведь в мире .NET подобных аналогов нет и не предвидится в ближайшее время (да и не только в .NET, наверное).

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

F_Z>А почему JetBrains не планирует развивать Nemerle официально? Как Kotlin, к примеру.

Я думаю этот вопрос лучше задать JetBrains. Но не сейчас, а когда Nitra заработает и появится хотя бы альфа Nemerle 2.

Сейчас для менеджеров слишком мало данных для подобного планирования.

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

s22>>.[]
VD>Это косяк. Его мы обязательно устраним. Еще претензии есть?

*с задних рядов* Есть!
Нотация дженерик типов. В C# она записывается через "уголки". Предлагаю поддержать это и в Nemerle по причинам:
1. Немерле-сообщество будет расти в первую очередь из шарповодов (а на дотнете других и нет!). Им (и мне) привычнее "уголки". Безболезненный переход — приличная составляющая успеха.
2. "Уголки" удобны ещё и тем, что практически не пересекаются с логическими операциями "больше"/"меньше" — код легче читать.

Ещё не совсем нравится синтаксис конструкторов — он неочевиден:

def a = Class();

Понятно, что покопавшись в коде, можно найти, что Class — это класс и понять, что это конструктор, а не вызов функции, но это КОПАТЬСЯ и нужно избегать. Например, как-то так:

def a = @Class; // конструктор без параметров
@OtherClass(par1, par2).DoIt(); // конструируем и тут же вызываем метод

Ну и раз пошла такая пьянка, убрать when — он глуп. Все привыкли к if и опциональному else. А вот крайне часто встречающееся "if (!условие)" как раз и нужно заменить на "unless(условие)" — сразу бросается в глаза, что условие должно быть ложным. Круглые скобки вокруг условия — атавизм, зато можно ввести обязательные операторные {} (один фик они повсюду!), тогда получается вообще красота:

unless File.CanWrite {
    // задолбать ФС запросами
}

Условие выглядит чище и чётко ограничено лексемами.

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

VD>Основной сложностью, в разработке Немерле 2, будет разработка DSL–я типизации выражений.

Влад, а в чём вообще заключается сложность типизации? (спрашиваю, потому что пока не окунался в сложности)

Допустим, есть AST. В нём мы уже имеем наполовину разрешённые символы. Для простоты, пример:

МойКласс : КлассБатя
....
Метод {
   def пер = Функ();
}

МойКласс будет занесён в список известных локальных классов. КлассБатя ищется во всех списках, где могут быть классы: чужие сборки, локальные классы. Далее, "пер" — опять известное имя, неизвестна функция Функ. Так как в AST (для корректной программы) имя Функ уже лежит где-то в мемберах иерархии для МойКласс, то его остаётся тупо отыскать по спискам. Получается, что задача создателя нового языка — объяснить BINDюжнику, в каких списках искать конкретные элементы языка. А в чём тогда "глубина сложности"?

С уголками согласен, но остальное просто вредные советы. Подумай сам:

B>Ещё не совсем нравится синтаксис конструкторов — он неочевиден:

B>Понятно, что покопавшись в коде, можно найти, что Class — это класс и понять, что это конструктор, а не вызов функции, но это КОПАТЬСЯ и нужно избегать. Например, как-то так:

Сделай себе в IDE подсветку того что это именно конструктор и не надо никаких особых синтаксисов. Из-за GC любой метод может вернуть новый объект по желанию левой пятки и конструирование уже давно прёт со всех щелей там где не ждёшь (не веришь — поставь к решарперу аддон Heap Allocation Viewer и убедись). Выделение конструктора в отдельную сущность притопало ещё из того C++, где RAII не рулил и удалять надо было ручками.

B>Ну и раз пошла такая пьянка, убрать when — он глуп. Все привыкли к if и опциональному else. А вот крайне часто встречающееся "if (!условие)" как раз и нужно заменить на "unless(условие)" — сразу бросается в глаза, что условие должно быть ложным. Круглые скобки вокруг условия — атавизм, зато можно ввести обязательные операторные {} (один фик они повсюду!), тогда получается вообще красота:

when защищает от ошибок. unless сделай себе сам макрооператором (если его ещё нет).

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

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

s22>>>.[]
VD>>Это косяк. Его мы обязательно устраним. Еще претензии есть?

B>*с задних рядов* Есть!
B>Нотация дженерик типов. В C# она записывается через "уголки". Предлагаю поддержать это и в Nemerle по причинам:
B>1. Немерле-сообщество будет расти в первую очередь из шарповодов (а на дотнете других и нет!). Им (и мне) привычнее "уголки". Безболезненный переход — приличная составляющая успеха.
Уголки это про обобщения ?
Тут давно пришли к выводу, что их нужно вернуть, только это сейчас поломает весь код компилятора и все кто пользуется Nemerle 1

B>Ещё не совсем нравится синтаксис конструкторов — он неочевиден:

B>

B>def a = Class();
B>

Как раз тут это логично, потому как конструктор это такая же функция как и другая.
В Nemerle можно писать:

[Record] class A { public X : int {get;}}
def l = [1,2,3];
def listOfA = l.Map(A);

B>Ну и раз пошла такая пьянка, убрать when — он глуп. Все привыкли к if и опциональному else. А вот крайне часто встречающееся "if (!условие)" как раз и нужно заменить на "unless(условие)" — сразу бросается в глаза, что условие должно быть ложным. Круглые скобки вокруг условия — атавизм, зато можно ввести обязательные операторные {} (один фик они повсюду!), тогда получается вообще красота:

Тут либо if-else это выражение, либо огород.
Лучше будет выражением и не нужны всякие нечитаемые "?:".

def res = if(x) a else if(y) { WriteLine("Y"); b } else c;

unless есть и так.
Вот его код: https://github.com/rsdn/nemerle/blob/master/macros/core.n#L327

Чем плоха унификация типа/значения?

def f(a, A)
{
 (a*a):A
}


f(1,double)

Сразу отпадает проблема разных скобок.

Унификация вызова

def str(a):string
{
a.toString();
}

str(1);
1.str();

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

s22>Сразу отпадает проблема разных скобок.
Хотелось бы увидеть примеры до и после и чем после лучше чем до.
Можно конечно еще дальше пойти как в Haskell , там вон полная унификация и скобок даже нет

s22>Унификация вызова
s22>

s22>def str(a):string
s22>{
s22>a.toString();
s22>}

s22>str(1);
s22>1.str();

s22>

Речь о Uniform Function Call Syntax (UFCS) ?
В Nemerle все методы находятся в классах и нет понятия глобальных функций.
Поэтому и придумали методы расширения.

Или речь только для локальных функций ? Тогда особо это не так важно.

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

B>Влад, а в чём вообще заключается сложность типизации?

В том, что лобовые решения получаются слишком медленными, а сложные решения сложны для реализации.

B>Допустим, есть AST. В нём мы уже имеем наполовину разрешённые символы. Для простоты, пример:...

Пытаться понять сложность типизации на частных примитивных примерах — это все равно что пытаться понять сложность математики на примерах арифметики для первоклашек.

Чисто вычислительная сложность вырастает из того, что в Немерле есть перегрузки и неявные приведения типов. Это вызывает перемножение вариантов. Если попадается выражение с множеством вложенных друг в друга вызовов, то количество переборов может стать невероятно большим, а при простом решении легко получить экспоненциальный взрыв. Сюда же накладывается проблема отложенной типизации (которой нет в C#).

Кроме того мы хотим сделать не частное решение для Немерле 2, а общий фремворк типизации с помощью которого описать типизацию Немерле будет легко и просто. Это позволит точно так же просто описать и типизацию других языков, а так же расширений Немерле 2.

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

_NN>Хотелось бы увидеть примеры до и после и чем после лучше чем до.
_NN>Можно конечно еще дальше пойти как в Haskell , там вон полная унификация и скобок даже нет

прикольный пример

def a(x=1, y=double)///

def a(a,T)
{
 match(T)
{
| int => ////
| [A] => ////
/////
}
}

_NN>Речь о Uniform Function Call Syntax (UFCS) ?
_NN>В Nemerle все методы находятся в классах и нет понятия глобальных функций.
_NN>Поэтому и придумали методы расширения.
Скорее о С++17, не знал что есть в D.

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

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

_NN>>Хотелось бы увидеть примеры до и после и чем после лучше чем до.
_NN>>Можно конечно еще дальше пойти как в Haskell , там вон полная унификация и скобок даже нет

s22>прикольный пример
s22>

s22>def a(x=1, y=double)///

s22>def a(a,T)
s22>{
s22> match(T)
s22>{
s22>| int => ////
s22>| [A] => ////
s22>/////
s22>}
s22>}
s22>

Тут просто нужно научить match сопоставлять типы: http://rsdn.ru/forum/nemerle/3686394.flat#3686394

Автор: CodingUnit
Дата: 29.01.10

def a(x = 1, y = typeof(double))
{
 match(y)
 {
 | typeof(int) => ..
 | typeof(double) => ..
 | _ => ..
 }
}

_NN>>Речь о Uniform Function Call Syntax (UFCS) ?
_NN>>В Nemerle все методы находятся в классах и нет понятия глобальных функций.
_NN>>Поэтому и придумали методы расширения.
s22>Скорее о С++17, не знал что есть в D.