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

__>В Nemerle есть макрос using-catch:


По мне так это на фиг не нужное извещение. Никогда не использовал и желания не возникает.

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

C>А try зачем нужен?

Затем же зачем нужны if, when, for и т.п. Для внятного синтаксического выделения начала некоторой конструкции. В данном случае защищенного блока.

Никогда не приходилось читать ряда вложенных тернарных (cond ? t : f) выражений С? if/else немного длиннее, но когда они вложены друг в друга, читать их в сто раз проще нежели тернарные операторы.

В Nemerle есть макрос using-catch:

using System;

class X : IDisposable
{
  public Dispose() : void {}
}

class P
{
 static Main() : void
 {
   using (x = X())
   {
    Console.WriteLine("A");
   }
   catch
   {
     | _ => Console.WriteLine("B");
   } 
 }
}

Однако генерируемый код Main эквивалентен:

def x = X();
try {  ... }
catch { ... }
finally { (x :> IDisposable).Dipose(); }

А не:

try
{
  using (x = X())
  {
   ...
  }
}
catch { ... }

Это может быть неочевидно. (Я как раз ожидал второе поведение)

Также нет способа выбрать куда ставить catch.
Аналогичная проблема возникнет если захотим реализовать using-finally.

Возможно ли придумать синтаксис с которым можно будет это решить красиво ?
Типа:

using (x = X()) { ... }
catch create { ... }
catch { ... }

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

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

__>>В Nemerle есть макрос using-catch:


VD>По мне так это на фиг не нужное извещение. Никогда не использовал и желания не возникает.

Можно и удалить.
Кто-то против ?

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

__>Можно и удалить.
__>Кто-то против ?

Мне инвариантно, я using-catch не использую. Возможно он используется где-то еще в библиотеках.

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

__>В Nemerle есть макрос using-catch:

В таком виде это выглядит как очень частный костыль. А что если catch использовать как оператор, без try?

EXPR catch EXPR|CATCH_BLOCK

В таком виде оно вполне органично впишется в язык наравне с ??. Логично ложится в концепцию "все есть выражение". Приоритет оператора видится довольно высоким.

Примеры:

def content = File.ReadAll("file.txt") catch "";

def result = (a / b) catch Math.NaN;

def val = cmd.ExecuteScalar() catch {_ is SqlException => throw InvalidSchemaException(cmd.CommandText)};

finally блок в виде выражения не очень вписывается, поэтому его сюда приплетать не нужно и использовать только в виде statement.

P.S. я знаю, что можно писать try File.ReadAll("file.txt") catch ""; и на данный момент овчинка выделки не стоит, но в Н2 можно подумать над этим.

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

Z>P.S. я знаю, что можно писать try File.ReadAll("file.txt") catch "";

Раз знаешь, то объясни нам, зачем нужна эта экономия на спичках?

Z>и на данный момент овчинка выделки не стоит, но в Н2 можно подумать над этим.

Там будет много куда более интересных вопросов. А этот не стоит выделки ни при каких условиях.

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

VD>Раз знаешь, то объясни нам, зачем нужна эта экономия на спичках?

А try зачем нужен?

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

Z>>P.S. я знаю, что можно писать try File.ReadAll("file.txt") catch "";

VD>Раз знаешь, то объясни нам, зачем нужна эта экономия на спичках?

Выразительность. В руби и перле, например, есть постфиксные формы if и unless.

action if condition

Без них тоже можно обойтись, только используются регулярно и выразительность повышают.

VD>Там будет много куда более интересных вопросов. А этот не стоит выделки ни при каких условиях.

Мое дело предложить Настаивать не буду, удобство тонкое и в N2 можно будет добавить самостоятельно.

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

Z>Выразительность. В руби и перле, например, есть постфиксные формы if и unless.

Z>action if condition

Z>Без них тоже можно обойтись, только используются регулярно и выразительность повышают.

Это пример здесь не уместен. Постфиксный if в Руби применим только к стейтментам (в немерловой терминалогии к void-выражениям). Их нельзя комбинировать. А вот выражения, к которым относится try/catah/finally, в

VD>>Там будет много куда более интересных вопросов. А этот не стоит выделки ни при каких условиях.

Z>Мое дело предложить Настаивать не буду, удобство тонкое и в N2 можно будет добавить самостоятельно.

Это и на Н1 можно добавить. Вопрос идет о включении в стандартную либу.

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

VD>Это и на Н1 можно добавить. Вопрос идет о включении в стандартную либу.

Учитывая, что в стдлибе есть вот это:
https://github.com/rsdn/nemerle/blob/master/macros/English.n

сложно быть против

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

VD>>Это и на Н1 можно добавить. Вопрос идет о включении в стандартную либу.

C>Учитывая, что в стдлибе есть вот это:
C>https://github.com/rsdn/nemerle/blob/master/macros/English.n

"Это" лежит в отдельном пространстве имен (Nemerle.English) и никому не мешает. А вот в общеиспользуемые пространства имен это вносить не надо.

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

Z>>Выразительность. В руби и перле, например, есть постфиксные формы if и unless.

VD>Это пример здесь не уместен. Постфиксный if в Руби применим только к стейтментам (в немерловой терминалогии к void-выражениям). Их нельзя комбинировать. А вот выражения, к которым относится try/catah/finally, в

Ну да, комбинировать можно и это будет выглядеть некрасиво. Однако это не остановило от введения оператора ??. Суть и смысл применения предложенного catch абсолютно та же.

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

Z>Ну да, комбинировать можно и это будет выглядеть некрасиво. Однако это не остановило от введения оператора ??. Суть и смысл применения предложенного catch абсолютно та же.

Вот это и есть тонкие особенности дизайна языка (его синтаксиса). Да, ?? в принципе можно комбинировать, но какой в этом смысл? Плюс, обычно в ?? оба выражения довольно короткие. С catch же все совсем не так.

Потом try / catch — это устоявшаяся конструкция. Возможность отказаться от скобок является естественным усовершенствованием идеи использования try / catch внутри выражения. Я бы сказал — это вымучено. Но какой смысл в детальнейшем скрещении синтаксиса? Мы хотим шокировать тех кто переходит с C#?

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

VD>Вот это и есть тонкие особенности дизайна языка (его синтаксиса). Да, ?? в принципе можно комбинировать, но какой в этом смысл?

Смысл может быть такой:

def result = searchPlaceOne() ?? searchPlaceTwo() ?? searchPlaceThree();

VD>Плюс, обычно в ?? оба выражения довольно короткие. С catch же все совсем не так.

Предлагается не полная отмена try, а альтернатива для коротких выражений.

VD>Потом try / catch — это устоявшаяся конструкция. Возможность отказаться от скобок является естественным усовершенствованием идеи использования try / catch внутри выражения. Я бы сказал — это вымучено. Но какой смысл в детальнейшем скрещении синтаксиса? Мы хотим шокировать тех кто переходит с C#?

Дело не в сокращении, дело в удобстве обработки исключения в одном выражении.

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

Z>Дело не в сокращении, дело в удобстве обработки исключения в одном выражении.

А что неудобного в более привычной для масс форме try expr catch hendler?

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

VD>А что неудобного в более привычной для масс форме try expr catch hendler?

Скажем так, во многих языках, особенно "динамических" (типа php, perl, ruby, python), есть целый класс постфиксных операторов управления.
Считается, что они придают выражениям ясность, потому что сначала идет важная часть (тело), а уже потом менее важная (условие).

Не знаю, насколько уж они удобные, ясные и интегрируемые в функциональный стиль, но есть причины добавить их как макросы в Nemerle (хоть и не в неймспейсах по умолчанию).
Во-первых, уже есть прецеденты, когда перенимались фичи из подобных языков, те же ?? и ?.
Во-вторых, в Немерле уже есть такие вещи, как #pragma indent и Nemerle.English, которые направлены на превращение Nemerle из C#-подобного в Python-подобный язык, и добавление постфиксных операторов в этом плане выглядит логичным.
В-третьих, это еще один неплохой способ показать крутость макросов Nemerle.
В-четвертых, это неплохое задание для человека, который хочет разобраться в макросах.

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

Тут, правда, есть технический момент. Я не уверен, может ли Nemerle одновременно поддерживать when (cond) { body } и body when (cond).

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

C>Скажем так, во многих языках, особенно "динамических" (типа php, perl, ruby, python), есть целый класс постфиксных операторов управления.
C>Считается, что они придают выражениям ясность, потому что сначала идет важная часть (тело), а уже потом менее важная (условие).

Это не совсем операторы. Скорее стэйтменты. Ну, да фиг бы сними.
Так что вы их не не предлагаете? Почти уверен, что в немерле можно без труда создать аналог if-из руби. Главное приоритеты правильно выставить.

C>Во-первых, уже есть прецеденты, когда перенимались фичи из подобных языков, те же ?? и ?.

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

C>Во-вторых, в Немерле уже есть такие вещи, как #pragma indent и Nemerle.English, которые направлены на превращение Nemerle из C#-подобного в Python-подобный язык, и добавление постфиксных операторов в этом плане выглядит логичным.

Казалось бы причем тут #pragma?

А Nemerle.English надо выбросить. Реально никем не используется. Какой-то дурак засунул свои эксперименты в публичную библиотеку и с тех пор они валяются в ней.

C>В-третьих, это еще один неплохой способ показать крутость макросов Nemerle.

А зачем нужен еще один никому не нужный способ?
В моем коде вообще try можно встретить раз в год. И он работает куда надежнее чем код маньяков натыкавших try по всему коду. Это обработка ошибок. Она должна быть централизована.

Язык не резиновый. В нем на фиг не нужно что-то по приколу или "шобы було" (с). Именно об этом говорят противники расширяемых языков.

Немерл очень демократичен. Ты можешь ввести почти любое расширение. Но это же налагает дополнительную ответственность в выборе того что нужно включать в стандартные библиотеки. Вот тут товарищу срочно нужен оператор := для объявления переменных (есть какой-то фатальный недостаток в def). Давай и его влепим.

Создавайте отдельный пакет. Кладите туда альтернативную библиотеку макросов и пихайте в нее что хотите. Кому захочется подключит ее и будет доволен.

C>В-четвертых, это неплохое задание для человека, который хочет разобраться в макросах.

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

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

C>Тут, правда, есть технический момент. Я не уверен, может ли Nemerle одновременно поддерживать when (cond) { body } и body when (cond).

Скорее всего — нет. Здесь на лицо явный конфликт. Н2 такое разрулил бы. Н1 может и спотыкнуться. Плюс еще вопрос в приоритете (точнее силе связывания) when. Но всегда можно взят другое ключевое слово.