def books = array(size) : array[Book];
expr : type
И много другое.
Для чего были введены такие различия? Почему при разработке nemerle на ограничились добавлением в существующий синтаксис C# ключевого слова val для констант, паттер-матчинга и макросов? Для чего эти различия практически во всех мелочах? Не это ли затрудняет продвижение языка в массы?
Или вот сейчас есть открытый Roslyn. Добавить туда эти 3 сущности и получится nemerle, нет?
Здравствуйте, Аноним, Вы писали:
А>из вики: А>C# А>Book[] books = new Book[size]; А>(type) expr
А>Nemerle: А>def books = array(size) : array[Book]; А>expr : type
А>И много другое. А>Для чего были введены такие различия? Почему при разработке nemerle на ограничились добавлением в существующий синтаксис C# ключевого слова val для констант, паттер-матчинга и макросов? Для чего эти различия практически во всех мелочах?
Для использования вывода типов такой синтаксис удобнее.
А "expr : type" — не приведение типа, а указание типа компилятору. http://rsdn.ru/forum/nemerle/4271787.1
Надо бы в FAQ — этот вопрос довольно часто возникает при первом знакомстве с языком.
А>Не это ли затрудняет продвижение языка в массы?
Точно не это
А>Или вот сейчас есть открытый Roslyn. Добавить туда эти 3 сущности и получится nemerle, нет?
VladD2 пытался в свое время — расскажет почему бросил и перешел на Nemerle.
Re: отличия nemerle от c#
От:
Аноним
Дата:
30.05.14 08:26
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Для чего были введены такие различия?
Потому что это не C#, в копировании C# смысла нет.
Здравствуйте, artelk, Вы писали:
А>>Или вот сейчас есть открытый Roslyn. Добавить туда эти 3 сущности и получится nemerle, нет? A>VladD2 пытался в свое время — расскажет почему бросил и перешел на Nemerle.
Всмысле пытался C# на стероидах сделать, задолго до Roslyn.
Re[2]: отличия nemerle от c#
От:
Аноним
Дата:
30.05.14 08:55
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Аноним, Вы писали:
А>>Для чего были введены такие различия?
А>Потому что это не C#, в копировании C# смысла нет.
вот Scala и, особенно, Groovy во многом копируют синтаксис Java. И порог вхождения у них, как мне кажется, ниже, чем у Nemerle
Re[3]: отличия nemerle от c#
От:
Аноним
Дата:
30.05.14 09:09
Оценка:
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, artelk, Вы писали:
А>>>Или вот сейчас есть открытый Roslyn. Добавить туда эти 3 сущности и получится nemerle, нет? A>>VladD2 пытался в свое время — расскажет почему бросил и перешел на Nemerle. A>Всмысле пытался C# на стероидах сделать, задолго до Roslyn.
Здравствуйте, Аноним, Вы писали:
А>вот Scala и, особенно, Groovy во многом копируют синтаксис Java.
Что-то не заметил, чтоб в Scala старались скопировать синтаксис. http://docs.scala-lang.org/tutorials/scala-for-java-programmers.html
А>И порог вхождения у них, как мне кажется, ниже, чем у Nemerle
Может у Groovy ниже, но у Scala врятли.
Здравствуйте, Аноним, Вы писали:
А>Или вот сейчас есть открытый Roslyn. Добавить туда эти 3 сущности и получится nemerle, нет?
Насчет макросов и проекта R#: http://www.rsdn.ru/forum/philosophy/1799455.1
'val' как аналог 'def' добавить раз плюнуть, однако без выражений просто бессмыслен.
Пример кода Nemerle:
def a = if(true) 1 else 2;
def b = match(x) { | A => 1 | B => 2 | _ => 3 };
В C# 'if' является утверждением (statement), а не выражением и посему не может так использоваться.
Получается нужен еще один 'if' который будет выражением, скажем как в Питоне: thenVal if condition else elseVal .
Ну и потом дойдет, что нужно отказаться от 'return' иначе не все будет выражением.
Продолжая дальше в функциональном духе потихоньку придем к примерно такому синтаксису
Здравствуйте, Аноним, Вы писали:
А>из вики: А>C# А>Book[] books = new Book[size]; А>(type) expr
А>Nemerle: А>def books = array(size) : array[Book]; А>expr : type
А>И много другое. А>Для чего были введены такие различия? Почему при разработке nemerle на ограничились добавлением в существующий синтаксис C# ключевого слова val для констант, паттер-матчинга и макросов? Для чего эти различия практически во всех мелочах? Не это ли затрудняет продвижение языка в массы? А>Или вот сейчас есть открытый Roslyn. Добавить туда эти 3 сущности и получится nemerle, нет?
Это связано с функциональным дизайном языка в первую очередь, expr : type выражение в функциональном стиле, когда результат слева передается дальше и так далее, как оператор |> для передачи значения слева в функцию справа, которая есть и в F# все это дает удобство при работе с выводом типов, потому что одна из основных фич Н это полноценный вывод типов из использования, поэтому все выражения обьявляются через def по умолчанию, название ключевого слова def из природы функциональных языков родителей Н, по стопам которых он пошел, ближе к лисп и scheme.
Поэтому сейчас только C# старается что то перенять у функциональных языков, как то лямбды, var обьявления через простенький вывод типов при инициализации, замыкания, но Н изначально был таким и в нем больше традиционного для функциональных языков а у C# больше похожего на C и языки общего назначения. Различия действительно обоснованы и привыкнуть к различию синтаксиса совсем не сложно, а через время понимаешь что синтаксис был выбран верно, просто попробуйте писать так и быстро привыкните к нему, если уж решили изучать Н то надо понимать что изучаете функциональный язык программирования и функциональный стиль программирования, сравнивать в этом случае с C# нельзя потому что он не функциональный язык, и то что Н похож на C# больше заслуга Н, что несмотря на многие фичи и функциональность язык походит и часто повторяет язык общего назначения.
Запись
def books = array(size) : array[Book];
выглядит более громоздко как будто, но на деле редко когда применяется пустой массив и с определением типа, проще написать def books = array(size); с выводом типа где то ниже, или сразу обьявить массив с нужными элементами array[1, 2, 3] и создавать массив и потом его изменять не в функциональном стиле, проще создавать неизменяемый список list или Enumerable и если надо преобразовать в массив, на деле массив реже применяется в Н, поскольку это изменяемый тип и нарушает функиональную чистоту.
expr : type
прямое указание типа тоже редко когда применяется, обычно везде работает вывод типов и прямое указание не нужно.
Здравствуйте, Аноним, Вы писали:
А>Для чего были введены такие различия? Почему при разработке nemerle на ограничились добавлением в существующий синтаксис C# ключевого слова val для констант, паттер-матчинга и макросов?
Кроме уже сказанного, еще одной причиной является что у разработчиков языка нет машины времени.
Когда создавался синтаксис Nemerle, в C# не было ни var, ни даже generic-ов. Когда в C# появился синтаксис для подобных вещей, он, естественно, не совпал с существующим синтаксисом Немерле.
Здравствуйте, CodingUnit, Вы писали:
CU>Здравствуйте, Аноним, Вы писали:
А>>из вики: А>>C# А>>Book[] books = new Book[size]; А>>(type) expr
А>>Nemerle: А>>def books = array(size) : array[Book]; А>>expr : type
CU>Это связано с функциональным дизайном языка в первую очередь, expr : type выражение в функциональном стиле, когда результат слева передается дальше и так далее
и не только, поскольку : это не приведение а подсказка компилятору о типе, потому что по умолчанию везде используется вывод типов, что дает и существенное сокращение кода. : применяется и при определениях def books : type = ... когда нужно подсказать что это за тип, применяется тоже редко, но так удобнее накладывается на обычный синтаксис обьявления с выводом типов. И далее в коде где надо подсказывать тип ':' пишется после, и может быть использоваться для мягкого преобразования типа, например к родителю, и совпадает с синтаксисом приведения полного :>, я так думаю из за этого разработчики сделали такой синтаксис.
А>И много другое. А>Для чего были введены такие различия? Почему при разработке nemerle на ограничились добавлением в существующий синтаксис C# ключевого слова val для констант, паттер-матчинга и макросов? Для чего эти различия практически во всех мелочах?
Здравствуйте, hi_octane, Вы писали: _>А квадратные скобки для типов, да, их надо при первой возможности заменить на треугольные.
Это конечно было бы хорошо, однако: есть проблемы
про то что однозначные случаи пусть компилятор разбирает сам. Тем более сейчас у нитры есть ещё выбор самой длинной корректно разбираемой последовательности.
А для реально неоднозначных случаев, вместо эвристики, пусть будет сообщение что выражение неоднозначное и программист разруливает через круглые скобки: F((G<A), (B>7)) и F((G<A,B>(7))) как вполне однозначные выражения. Ну и для совсем редких случаев есть ещё @ который подсказывает где оператор, а где что-то другое.
В любом случае с точностью до багов повторять самые стрёмные моменты [] и .[] вместо их исправления выглядит как-то стрёмно. И, кстати, из-за полностью изменяемого синтакиса нитры, все проблемы неоднозначности распространяются на [] точно также как и на <>.
Здравствуйте, hi_octane, Вы писали:
_>А для реально неоднозначных случаев, вместо эвристики, пусть будет сообщение что выражение неоднозначное и программист разруливает через круглые скобки: F((G<A), (B>7)) и F((G<A,B>(7))) как вполне однозначные выражения. Ну и для совсем редких случаев есть ещё @ который подсказывает где оператор, а где что-то другое.
Ошибка вместо эвристики это совсем другое дело
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, hi_octane, Вы писали:
_>>А для реально неоднозначных случаев, вместо эвристики, пусть будет сообщение что выражение неоднозначное и программист разруливает через круглые скобки: F((G<A), (B>7)) и F((G<A,B>(7))) как вполне однозначные выражения. Ну и для совсем редких случаев есть ещё @ который подсказывает где оператор, а где что-то другое. _NN>Ошибка вместо эвристики это совсем другое дело
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, _NN_, Вы писали:
_NN>>Здравствуйте, hi_octane, Вы писали:
_>>>А для реально неоднозначных случаев, вместо эвристики, пусть будет сообщение что выражение неоднозначное и программист разруливает через круглые скобки: F((G<A), (B>7)) и F((G<A,B>(7))) как вполне однозначные выражения. Ну и для совсем редких случаев есть ещё @ который подсказывает где оператор, а где что-то другое. _NN>>Ошибка вместо эвристики это совсем другое дело
А>Только человеку тоже надо это разобрать
В 99% случаев нет неоднозначностей и все выглядит как обычно.
Для одного процента будет выводится ошибка, и не нужно будет гадать что в итоге понял компилятор.
Здравствуйте, _NN_, Вы писали:
_>>А квадратные скобки для типов, да, их надо при первой возможности заменить на треугольные. _NN>Это конечно было бы хорошо, однако: есть проблемы
Интересно, а чего заглохла реализация-то?
Решение Влада
class MyClass<|T|> : IMyInterface<|T|>
— оно наиболее гармонирует с тем, чего просил народ: с одной стороны — "привычные уголки", с другой — нет неоднозначности с "больше-меньше". А палочки — их никто и не заметит — такое решение НАМНОГО более красиво, чем какая-то дурацкая точка ни к селу, ни к **опе. Чего не стали делать-то?
Здравствуйте, btn1, Вы писали:
B>- оно наиболее гармонирует с тем, чего просил народ: с одной стороны — "привычные уголки", с другой — нет неоднозначности с "больше-меньше". А палочки — их никто и не заметит — такое решение НАМНОГО более красиво, чем какая-то дурацкая точка ни к селу, ни к **опе. Чего не стали делать-то?
Здравствуйте, _NN_, Вы писали:
_NN>Почему тогда не обычные скобочки < > ?
Насколько я слышал даже из мира С++, "уголки" создали проблему неоднозначности в языке, которая конечно же решилась (эвристиками), но как легко догадаться, это КОСТЫЛЬ. В компиляторе не должно быть "эвристик", только если это не какой-то совсем хитрый случай совпадения символов для разных контекстов. Здесь мы МОЖЕМ контролировать синтаксис и можем избежать дополнительного напряга компилятора (читай, уменьшить время обработки), так почему бы этим не воспользоваться? Более того — уголки даже сохраняются(!), но сопровождаются дополнительными столбиками, чтобы вообще никаких неоднозначностей не было.
Увы, так получилось, что в ASCII весьма мало удобных символов для выражения синтаксиса, так что незачем капризничать и лучше попытаться решить проблему с тем, что есть (хотя я не против перехода в мир юникода с новыми символами).
— такое решение НАМНОГО более красиво, чем какая-то дурацкая точка ни к селу, ни к **опе. Чего не стали делать-то?
