Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 15:21
Оценка: -3
Известно, что в Си-подобном синтаксисе круглые скобочки несколько перегружены смыслом. Это и средство для группировки выражений, и часть грамматики некоторых стандартных выражений вроде for, if и вызов функции, и приведение типов...
На мой взгляд это несколько снижает читабельность.

А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях. Например, вместо


for (x in y) 
  expr



было бы


for x in y do
  expr



Или вместо


if (x > y)
  expr
else
  expr



было бы


if x > y then
  expr
else
  expr



Само собой при сохранении остальной си-подобности.
Re: Про скобочки
От: Курилка Россия http://kirya.narod.ru/
Дата: 26.04.10 15:25
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

[cut]
ВВ>Само собой при сохранении остальной си-подобности.

И без фигурных скобок и с вытекающими их этого последствиями?
Re[2]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 15:26
Оценка:
Здравствуйте, Курилка, Вы писали:

К>[cut]

ВВ>>Само собой при сохранении остальной си-подобности.
К>И без фигурных скобок и с вытекающими их этого последствиями?

Нет, с фигурными. Фигурные скобки — тема отдельная, про них речи не было.
Re: Про скобочки
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 26.04.10 15:26
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях. Например, вместо


Так паскаль получится? Или Ada Но я только "за" :w
Re[2]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 15:32
Оценка:
Здравствуйте, Mystic, Вы писали:

ВВ>>А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях. Например, вместо

M>Так паскаль получится? Или Ada Но я только "за" :w

Паскаль получится, если фигурные скобочки заменить на begin/end

Но дело не в том, что там получится. Собственно, мне интересно, не является ли конструкция вида


for x in y do
  expr



более "чистой" с т.з. синтаксиса, чем


for (x in y)
  expr



Учитывая, что внутри for у нас может быть куча дополнительных скобочек.
Re[3]: Про скобочки
От: Курилка Россия http://kirya.narod.ru/
Дата: 26.04.10 15:37
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

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


К>>[cut]

ВВ>>>Само собой при сохранении остальной си-подобности.
К>>И без фигурных скобок и с вытекающими их этого последствиями?

ВВ>Нет, с фигурными. Фигурные скобки — тема отдельная, про них речи не было.


Ну мне в глаза бросается их отсутствие для си-подобного языка.
Re[3]: Про скобочки
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 26.04.10 15:41
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>более "чистой" с т.з. синтаксиса, чем


Непонятно, что значит "более чистой". Очень субьективное понятие. С точки зрения разбора скобочки нисколько не вредят. С точки зрения читабельности в случае сложного выражения всегда можно написать for(;), а уже внутри него разруливать. Так, кстати, я и поступаю в более-менее сложных случаях. Ну и скобочки по стилю написания лучше соответствуют всяким другим {, ++, ?:.

С другой стороны, что лично я готов пойти дальше, мне академичность Ada нравится куда больше.
Re[4]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 15:43
Оценка:
Здравствуйте, Курилка, Вы писали:

ВВ>>Нет, с фигурными. Фигурные скобки — тема отдельная, про них речи не было.

К>Ну мне в глаза бросается их отсутствие для си-подобного языка.

В конструкциях типа for/if скобочки всегда являлись необходимыми только если у нас несколько выражений.

Предполагается что синтаксис такой:

for x in y do 
  expr;

for x in y do  {
  expr1;
  expr2
}


В качестве альтернативного решения вспоминается Go, если я правильно понял его грамматику, где в подобных выражениях круглые скобочки являются необязательными, а вот фигурные — необходимы в любом случае:


for a < b {
    a *= 2
}
Re[4]: Про скобочки
От: Temoto  
Дата: 26.04.10 15:44
Оценка:
ВВ>>более "чистой" с т.з. синтаксиса, чем

M>Непонятно, что значит "более чистой". Очень субьективное понятие. С точки зрения разбора скобочки нисколько не вредят. С точки зрения читабельности в случае сложного выражения всегда можно написать for(;), а уже внутри него разруливать. Так, кстати, я и поступаю в более-менее сложных случаях. Ну и скобочки по стилю написания лучше соответствуют всяким другим {, ++, ?:.


M>С другой стороны, что лично я готов пойти дальше, мне академичность Ada нравится куда больше.


"академичность Ada" это что?
Re[4]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 15:44
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Непонятно, что значит "более чистой". Очень субьективное понятие. С точки зрения разбора скобочки нисколько не вредят. С точки зрения читабельности в случае сложного выражения всегда можно написать for(;), а уже внутри него разруливать. Так, кстати, я и поступаю в более-менее сложных случаях. Ну и скобочки по стилю написания лучше соответствуют всяким другим {, ++, ?:.


ОК, point taken.

M>С другой стороны, что лично я готов пойти дальше, мне академичность Ada нравится куда больше.


Дальше — это куда?
Re[5]: Про скобочки
От: Курилка Россия http://kirya.narod.ru/
Дата: 26.04.10 15:50
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


ВВ>>>Нет, с фигурными. Фигурные скобки — тема отдельная, про них речи не было.

К>>Ну мне в глаза бросается их отсутствие для си-подобного языка.

ВВ>В конструкциях типа for/if скобочки всегда являлись необходимыми только если у нас несколько выражений.

ВВ>В качестве альтернативного решения вспоминается Go, если я правильно понял его грамматику, где в подобных выражениях круглые скобочки являются необязательными, а вот фигурные — необходимы в любом случае

Довольно значительное число людей берут позицию авторов Go в качестве стандарта кодирования на других си-подобных языках, надеюсь, не надо рассказывать про возможные ошибки при неиспользовании фиг. скобок.
Re[5]: Про скобочки
От: Temoto  
Дата: 26.04.10 15:50
Оценка:
ВВ>В качестве альтернативного решения вспоминается Go, если я правильно понял его грамматику, где в подобных выражениях круглые скобочки являются необязательными, а вот фигурные — необходимы в любом случае:

Добавлю, что в Go некоторые решения, в частности синтаксические, сделаны с упором на сверхбыстрый парсинг и компиляцию. А это далеко не всегда самые приоритетные причины. Если рассматривать Go как пример синтаксиса, то нужно учесть, что без заморочек про скорость компиляции, его синтаксис был бы другим. Неизвестно насколько другим, правда.
Re[6]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 15:55
Оценка: +1
Здравствуйте, Курилка, Вы писали:

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


А многие не берут. И заставлять их использовать фигурные скобки на уровне грамматики несколько неправильно.
Писать скобки в случае одного выражения или не писать — это тема для отдельного флейма и вроде как такой флейм тут недавно был, смысла в его продолжении я не вижу.

Замечу только, что если, к примеру, из языка убрать разбиение на statements и expressions, то все уродство обязательных фигурных скобочек сразу же вылезет наружу:

var x = if cond then { y } else { z }

вместо

var x = if cond then y else z
Re[5]: Про скобочки
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 26.04.10 15:56
Оценка:
Здравствуйте, Temoto, Вы писали:

T>"академичность Ada" это что?


Несколько избыточный синтаксис, но проработанный таким образом, что ошибка/опечатка в одном символе почти никогда (кроме как в идентификаторах) не приводит к синтаксически правильной программе. Плюс возможность хорошей диагностики ошибок компиляции.
Re[5]: Про скобочки
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 26.04.10 15:57
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

M>>С другой стороны, что лично я готов пойти дальше, мне академичность Ada нравится куда больше.

ВВ>Дальше — это куда?

В сторону адского синтаксиса.
Re[6]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 15:59
Оценка:
Здравствуйте, Temoto, Вы писали:

T>Добавлю, что в Go некоторые решения, в частности синтаксические, сделаны с упором на сверхбыстрый парсинг и компиляцию. А это далеко не всегда самые приоритетные причины. Если рассматривать Go как пример синтаксиса, то нужно учесть, что без заморочек про скорость компиляции, его синтаксис был бы другим. Неизвестно насколько другим, правда.


У меня возникли другие мысли, глядя на "бесскобочные" if-ы и for-ы в Go, особенно если учесть, что язык все равно же Си-подобный, поэтому вышеприведенный пример на Go можно записать и так, и он будет полностью валиден:

for (a < b) {
    a *= 2
}


Не уверен, насколько это все влияет на скорость парсинга, мне кажется не самый это значительный момент

А вообще я его как пример синтаксиса не рассматриваю, пример в данном случае скорее ML. Ну, естественно, касательно круглых скобочек только.
Re[6]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 16:00
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, Воронков Василий, Вы писали:

M>>>С другой стороны, что лично я готов пойти дальше, мне академичность Ada нравится куда больше.
ВВ>>Дальше — это куда?
M>В сторону адского синтаксиса.

Т.е. begin/end и все такое?
Re[6]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 16:04
Оценка:
Здравствуйте, Mystic, Вы писали:

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

T>>"академичность Ada" это что?
M>Несколько избыточный синтаксис, но проработанный таким образом, что ошибка/опечатка в одном символе почти никогда (кроме как в идентификаторах)

...и кроме как при группировках/вызовах, которые, если я не ошибаюсь, в Ada так же выражаются через круглые скобочки.
Я вот, например, не припомню ошибок, связанных с неправильно расставленными {} — надо сказать, тут и авто-формат в редакторе помогает, — а вот при группировках внутри вызовов и проч. ошибочки были.
Re[7]: Про скобочки
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 26.04.10 16:21
Оценка: 10 (1)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Т.е. begin/end и все такое?


Да. Примерно так:

-- Пустая инструкция
null;

-- Присваивание
Result := Expression;

-- Блоки
Calculation_Of_Roots: -- Не обязательно
declare
  D: Float;
begin
  D := B*B - 4*a*C;
  exit Calculation_Of_Roots when D < 0;
  -- ...
end Calculation_Of_Roots; -- Если не указано имя блока, то можно не указывать

-- Условный оператор
if Something_Interesting then
  Do_Interesting_Job;
elsif Somethig_Groove
  Do_Groove_Job;
end if;

-- Выбор
case Letter is
  when 'a'..'z'| 'A'..'Z' => Put ("letter");
  when '0'..'9'           => Put ("digit! Value is"); Put (letter);
  when '''' | '"' | '`'   => Put ("quote mark");
  when '&'                => Put ("ampersand");
  when others             => Put ("something else");
end case;

-- Циклы
loop
  Inc_Counter;
end loop;

while I_am_alive loop
  Please_Kill_Me;
  exit when Reguest_Declined;
end loop;

for  I in Array'Range loop
  Process(Array[I]);
end loop;

Outer_Loop:
loop
  Do_Important_Job;
  loop
    Do_Important_Job;
    exit Outer_Loop when Am_I_Tired;
  end loop;
end loop Outer_Loop;

-- Исключения
declare
  Abort: exception;  
begin
  raise Abort;
exception
  when Abort => Put("Abort exception");
  when others => Put("General exeption");
end;
Re[5]: Про скобочки
От: FR  
Дата: 26.04.10 16:49
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Дальше — это куда?


В пределе питон
Re[6]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 16:53
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Дальше — это куда?
FR>В пределе питон

А там можно получить неправильную программу просто вставив лишний пробел
Re: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.10 17:16
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях. Например, вместо


Если рассматривать этот вопрос под углом зрения программиста привыкшего к сишному синтаксису, то несомненно отрицательно. Привычка есть привычка и без особых на то причин ее ломать не хочется.

Именно по этой причине немерле так легко дается сишникам, а F# — нет. Сематнически немерл как раз ближе к F# чем к C#, но синтаксис и многие другие детали (перегрузка, приведения типов и т.п.) мимикрируют под C#, что делает изучения языка "сишниками" значительно более простым занятием.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.10 17:17
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>В качестве альтернативного решения вспоминается Go, если я правильно понял его грамматику, где в подобных выражениях круглые скобочки являются необязательными, а вот фигурные — необходимы в любом случае:


Я бы предпочел с точностью на оборот.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.10 17:18
Оценка: 1 (1)
Здравствуйте, Курилка, Вы писали:

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


Над. И очень!

Я вот уже двадцать лет не пишу фигурные скобки так где это возможно и ни разу не нарывался на эти "последствия".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Про скобочки
От: _FRED_ Черногория
Дата: 26.04.10 17:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я вот уже двадцать лет не пишу фигурные скобки так где это возможно и ни разу не нарывался на эти "последствия".


Во-первых, откуда знаешь про "ни разу", может не все ошибки ещё нашёл
Во-вторых, я всегда ставлю все кавыки по причине, отличной от возможных ошибок из-за забытых скобок (да, бывают такие причины), хотя несколько раз такие ошибки (с забытыми скобками и сдвинутым текстом) встречал у много более опытных и не менее, чем я, скурпулёзных программистов
В-третьих, неужели ты действительно не веришь, что таких ошибок не может быть? А раз они могут быть, то чем плох такой способ борьбы с ними?
Help will always be given at Hogwarts to those who ask for it.
Re[2]: Про скобочки
От: _FRED_ Черногория
Дата: 26.04.10 17:56
Оценка:
Здравствуйте, Курилка, Вы писали:

ВВ>>Само собой при сохранении остальной си-подобности.


К>И без фигурных скобок и с вытекающими их этого последствиями?


А что могут быть за "последствия"?
Help will always be given at Hogwarts to those who ask for it.
Re[7]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.10 18:02
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Писать скобки в случае одного выражения или не писать — это тема для отдельного флейма и вроде как такой флейм тут недавно был, смысла в его продолжении я не вижу.


А можно ссылочку?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.10 18:10
Оценка: 1 (1) +1
Здравствуйте, _FRED_, Вы писали:

VD>>Я вот уже двадцать лет не пишу фигурные скобки так где это возможно и ни разу не нарывался на эти "последствия".


_FR>Во-первых, откуда знаешь про "ни разу", может не все ошибки ещё нашёл


Ну, я как-то думал, что трудно не заметить того, что нарвался на проблемы. Нет?

_FR>Во-вторых, я всегда ставлю все кавыки по причине, отличной от возможных ошибок из-за забытых скобок (да, бывают такие причины),


Что за "кавыки"? И как они влияют на скобки?

И что за проблемы? Ну, и почему я их ни разу в жизни не видел? Может быть для этого нужно использовать старые компиляторы и писать в ноотпэде?

_FR>хотя несколько раз такие ошибки (с забытыми скобками и сдвинутым текстом) встречал у много более опытных и не менее, чем я, скурпулёзных программистов


А IDE ты ты не встречал? Они обычно умеют показывать где проблемы с незакрытыми скобками.
И опять же причем тут не закрытые скобки и отсутствие скобок в тех местах где они не нужны?

_FR>В-третьих, неужели ты действительно не веришь, что таких ошибок не может быть? А раз они могут быть, то чем плох такой способ борьбы с ними?


Я не считаю, что проблемы — это предмет веры. Они или есть, или нет. Если у меня есть выражение:
when (a)
  b();

то проблем от того что я не поставлю скобки не будет. А вот сами скобки будут совершенно лишними. Их наличие и код сделает длиннее, и введет заблуждение (если код не примитивный), так как я уже не смогу однозначно сказать один оператор в этом when или два, просто неграмотно отформатирован.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 18:11
Оценка:
Здравствуйте, VladD2, Вы писали:

ВВ>>Писать скобки в случае одного выражения или не писать — это тема для отдельного флейма и вроде как такой флейм тут недавно был, смысла в его продолжении я не вижу.

VD>А можно ссылочку?

http://rsdn.ru/forum/flame.comp/3781310.1.aspx
Автор:
Дата: 20.04.10

enjoy
Re[2]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 18:19
Оценка:
Здравствуйте, VladD2, Вы писали:

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

ВВ>>А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях. Например, вместо
VD>Если рассматривать этот вопрос под углом зрения программиста привыкшего к сишному синтаксису, то несомненно отрицательно. Привычка есть привычка и без особых на то причин ее ломать не хочется.

Ох, не знаю. Если бы все так было просто с этими привычками, то люди бы никогда не разводились
Я вот замечаю, что меня начинают подзадалбывать все эти скобочки. А может быть, я не одинок?

VD>Именно по этой причине немерле так легко дается сишникам, а F# — нет. Сематнически немерл как раз ближе к F# чем к C#, но синтаксис и многие другие детали (перегрузка, приведения типов и т.п.) мимикрируют под C#, что делает изучения языка "сишниками" значительно более простым занятием.


Честно говоря, что не нравится в синтаксисе Немерле так это именно имитация сишного синтаксиса зачастую с нарушением привычной семантики. Например, взять операции инкремента/пост-инкремента ( хотя это макросы, наверное? ). Или те же фигурные скобочки:

match (expr) {
  | x => ...
  | _ => ...
}


В Си-подобных языках скобочки всегда задают лексический скоп, но в случае с match-ем — это не так. Скоп задается на уровне каждого вхождения матча, а не всего матча в целом.

С практической т.з. это все фигня, но... гм... с эстетической...
Re[7]: Про скобочки
От: FR  
Дата: 26.04.10 18:19
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>А там можно получить неправильную программу просто вставив лишний пробел


Пробел фигня, вот неправильный таб вообще может до смертоубийства довести
Re[9]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.10 18:21
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>>>Писать скобки в случае одного выражения или не писать — это тема для отдельного флейма и вроде как такой флейм тут недавно был, смысла в его продолжении я не вижу.

VD>>А можно ссылочку?

ВВ>http://rsdn.ru/forum/flame.comp/3781310.1.aspx
Автор:
Дата: 20.04.10

ВВ>enjoy

Ясно. Флэйм читаю очень редко. Потому и не видел. Ты уж говоря "тут" уточняй форум, плиз.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 18:25
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ясно. Флэйм читаю очень редко. Потому и не видел.


Как многие флеймы, оно имело более благородные корни — в данном случае форум С/C++.

VD>Ты уж говоря "тут" уточняй форум, плиз.


ОК
Re[9]: Про скобочки
От: _FRED_ Черногория
Дата: 26.04.10 18:25
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>>>Я вот уже двадцать лет не пишу фигурные скобки так где это возможно и ни разу не нарывался на эти "последствия".

_FR>>Во-первых, откуда знаешь про "ни разу", может не все ошибки ещё нашёл
VD>Ну, я как-то думал, что трудно не заметить того, что нарвался на проблемы. Нет?

Я такие "сюрпризы":
if(blablabla)
  aha();
  oxo();

находил и через несколько месяцев просле того, как они были закомичены

_FR>>Во-вторых, я всегда ставлю все кавыки по причине, отличной от возможных ошибок из-за забытых скобок (да, бывают такие причины),

VD>Что за "кавыки"? И как они влияют на скобки?
VD>И что за проблемы? Ну, и почему я их ни разу в жизни не видел? Может быть для этого нужно использовать старые компиляторы и писать в ноотпэде?

Ну вот абзацем выше пример привёл. Такие ошибки возникают, когда не всегда ставят операторные скобки.

_FR>>хотя несколько раз такие ошибки (с забытыми скобками и сдвинутым текстом) встречал у много более опытных и не менее, чем я, скурпулёзных программистов

VD>А IDE ты ты не встречал? Они обычно умеют показывать где проблемы с незакрытыми скобками.

Не знаю, как IDE может здесь помочь: я такие ошибки встречал в коде, набранном в MSVS от шестёрки и до две тыщи восемь.

VD>И опять же причем тут не закрытые скобки и отсутствие скобок в тех местах где они не нужны?


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

_FR>>В-третьих, неужели ты действительно не веришь, что таких ошибок не может быть? А раз они могут быть, то чем плох такой способ борьбы с ними?


VD>Я не считаю, что проблемы — это предмет веры. Они или есть, или нет. Если у меня есть выражение:

VD>when (a)
VD>  b();

VD>то проблем от того что я не поставлю скобки не будет. А вот сами скобки будут совершенно лишними. Их наличие и код сделает длиннее, и введет заблуждение (если код не примитивный), так как я уже не смогу однозначно сказать один оператор в этом when или два, просто неграмотно отформатирован.

Я вижу проблемы в том, что для того, что бы добавить внутрь условия какой-то код, надо ещё добавить скобки вокруг. Мне кажется, это усложняет исправление, а, значит, и поддержку кода, ибо один из [основных!] критериев поддерживаемости — это простота и безопасность внесения изменений.

То есть проблема не в статике, не в написанном, а в динамике, в том, что такой код немножко сложнее поддерживать\исправлять\расшироять\дописывать и переписывать. Всё-таки ветвления и прочие циклы не редки, особенно в алгоритмических кусках. И мне кажется, что чем меньше мазков придётся нанести на картину для её исправления, тем качественнее картина написана.
Help will always be given at Hogwarts to those who ask for it.
Re[10]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 18:29
Оценка: +1
Здравствуйте, _FRED_, Вы писали:

Может, вам просто почитать дискуссию тут:
http://rsdn.ru/forum/flame.comp/3781310.1.aspx
Автор:
Дата: 20.04.10


А то вы сейчас ее начинаете воспроизводить один-в-один. Читать иногда лучше, чем писать
Re[8]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 18:42
Оценка: +1 :)
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Воронков Василий, Вы писали:


ВВ>>А там можно получить неправильную программу просто вставив лишний пробел

FR>Пробел фигня, вот неправильный таб вообще может до смертоубийства довести

Тоже, кстати, поинт хороший. Им стоило бы вообще запретить табы, как это сделали в F# #light.

А то с помощью смеси табов и пробелов — да еще в зависимости от настроек редактора — в питоне можно такое натворить, что все эти рассуждения о лишней паре {} покажутся детской забавой.
Re[3]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.10 18:45
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Честно говоря, что не нравится в синтаксисе Немерле так это именно имитация сишного синтаксиса зачастую с нарушением привычной семантики.


Про семантику ты явно преувеличиваешь.

ВВ>Например, взять операции инкремента/пост-инкремента


Что за связь?

ВВ> ( хотя это макросы, наверное? ).


Ага, он.

ВВ>Или те же фигурные скобочки:


ВВ>
ВВ>match (expr) {
ВВ>  | x => ...
ВВ>  | _ => ...
ВВ>}
ВВ>


Ты же вроде про круглые говорил. Или ты решил все же тему махнуть?

Что до скобок в именно в операторе match, то у меня была идея сделать так чтобы фигурные скобки в match были не обязательными если все вхождения match-а (то что идет за =>) содержат ровно по одному выражению (не содержат точек с запятой или состоят из одного блока). Например:
def z = match (expr)
         | x => x + y
         | _ => f(expr);

или
def z = match (expr) | x => x + y | _ => f(expr);


ВВ>В Си-подобных языках скобочки всегда задают лексический скоп, но в случае с match-ем — это не так. Скоп задается на уровне каждого вхождения матча, а не всего матча в целом.


Почему же это не так? Скобки тоже задают лексический "скоп". Просто в нем нельзя объявлять переменные.
Ну, и нужно понимать, что язык все же гибридный, что дает ему не всегда следовать сишным догмам. Запомнить, что вхождение матча тоже создает скоп не так уж сложно. Зато это очень удобно. Скобки тут были бы совершенно лишними, по-моему.

ВВ>С практической т.з. это все фигня, но... гм... с эстетической...


Эстетическая точка зрения в коде — это что-то новое. Точнее она у каждого своя. Один не может терпеть лишних скобок, другой без них жить не может, третий считает мудаками тех кто ставит открывающую скобку на предыдущей строке, четвертый наоборот.

Я могу только утверждать две вещи:
1. Какой-то стиль нужен. И в одном проекте должен использоваться единый стиль. Следовательно о стиле в одном проекте нужно договариваться.
2. Я предпочитаю конкретный стиль и с большим неудовольствием перестраиваюсь на другой. Но понимаю, что не должно быть разного стиля в одном проекте и скрипя сердцем перестраиваюсь. Так я стал писать пробелы между именем операторов (таких как if, swith, match, ...) и открывающей скобкой. Ранее я это не делал. Между тем писать пробел перед именем функции я категорически не хочу, так как это ужасно ухудшает читаемость (начинают разделяться единые выражения, что плохо отражается на понимании кода).

Как стоит открывающая фигурная скобка мне не все равно. Я предпочитаю ставить ее на новой строке, так чтобы она была на том же уровне что закрывающая скобка того же уровня. Это удобнее при навигации по коду (люблю перпрыгивать по скобкам вперед-назад). Но в принципе спокойно читаю код и в других стилях.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 19:02
Оценка:
Здравствуйте, VladD2, Вы писали:

ВВ>>Например, взять операции инкремента/пост-инкремента

VD>Что за связь?

Ну они выглядят как аналогичные операции в Си, однако "работают" не так, т.е. семантика другая. Честно, мне сложно представить, зачем кому-то в функциональном языке потребовались такие макросы

ВВ>> ( хотя это макросы, наверное? ).


VD>Ага, он.


ВВ>>Или те же фигурные скобочки:


ВВ>>
ВВ>>match (expr) {
ВВ>>  | x => ...
ВВ>>  | _ => ...
ВВ>>}
ВВ>>


VD>Ты же вроде про круглые говорил. Или ты решил все же тему махнуть?


Ну раз вы начали тут про фигурные флеймить, то я-то чем хуже...

VD>Что до скобок в именно в операторе match, то у меня была идея сделать так чтобы фигурные скобки в match были не обязательными если все вхождения match-а (то что идет за =>) содержат ровно по одному выражению (не содержат точек с запятой или состоят из одного блока). Например:

VD>
VD>def z = match (expr)
VD>         | x => x + y
VD>         | _ => f(expr);
VD>

VD>или
VD>
VD>def z = match (expr) | x => x + y | _ => f(expr);
VD>


Мне лично понравился бы такой синтаксис:

match (expr)
| x => x + y
| _ => { expr1; expr2; }

Вроде как для образца _ у нас два выражения.
Я, видимо, что-то не понимаю в синтаксисе Немерле, но зачем в таком случае дополнительные фигурные скобки вокруг match, неясно.

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

ВВ>>В Си-подобных языках скобочки всегда задают лексический скоп, но в случае с match-ем — это не так. Скоп задается на уровне каждого вхождения матча, а не всего матча в целом.

VD>Почему же это не так? Скобки тоже задают лексический "скоп". Просто в нем нельзя объявлять переменные.

Ага, лексический скоп, в котором нельзя объявлять имена. Фишку понял

VD>Ну, и нужно понимать, что язык все же гибридный, что дает ему не всегда следовать сишным догмам. Запомнить, что вхождение матча тоже создает скоп не так уж сложно. Зато это очень удобно. Скобки тут были бы совершенно лишними, по-моему.


Для вхождения я никогда не предлагал скобки. В Си тоже скобки — не единственная конструкция которая задает скоп. for, например, тоже задает скоп, независимо от наличия или отсутствия скобок. Т.е. это-то ИМХО нормально.

ВВ>>С практической т.з. это все фигня, но... гм... с эстетической...

VD>Эстетическая точка зрения в коде — это что-то новое. Точнее она у каждого своя. Один не может терпеть лишних скобок, другой без них жить не может, третий считает мудаками тех кто ставит открывающую скобку на предыдущей строке, четвертый наоборот.

Это все верно, но "истина где-то рядом". Если большей части людей что-то неудобно или непривычно, то возможно это действительно плохо.
Re[10]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.10 19:11
Оценка: +1
Здравствуйте, _FRED_, Вы писали:

_FR>Я такие "сюрпризы":

_FR>
_FR>if(blablabla)
_FR>  aha();
_FR>  oxo();
_FR>

_FR>находил и через несколько месяцев просле того, как они были закомичены

Не, ну, возможно есть хроники которые ошибки месяцами выявлюят. У меня в худшем случае на сложную ошибку уходит 2-3 дня. И это точно не ошибки из разряда плохое форматирование.

Ну, и подобных проблемы я не видел еще ни разу.

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

Если же в форматировании кода нет системы, то код сразу же нужно признавать некорректным и без дополнительной проверки (с одновременным форматированием) не рассматривать. Точнее производить его верификацию и отладку.

_FR>Ну вот абзацем выше пример привёл. Такие ошибки возникают, когда не всегда ставят операторные скобки.


Где там ошибка то? Там черным по белому написано что код писал мудак не знающий о том, что такое форматирование кода. Лучшее что можно сделать с таким кодом — автоматически его переформатировать. Да и после этого к такому коду нужно относительно с большим подозрением. Ведь ламерсово оно не останавливается на форматирования. Форматирование — это только проявление ламерства.

VD>>А IDE ты ты не встречал? Они обычно умеют показывать где проблемы с незакрытыми скобками.


_FR>Не знаю, как IDE может здесь помочь: я такие ошибки встречал в коде, набранном в MSVS от шестёрки и до две тыщи восемь.


Возьми интеграцию C# MS VS начиная с 2001 и тупо отформатируй код через меню Edit\Advanced\Format Document и ты увидишь все проблемы с форматированием и скобками. Почти уверен, что IDEA и Eclips имеют такие же средства. Это только в твоих любимых языках это может быть проблемой (так как отступы в них что-то значат).

В С-подобных языках отступы, как и прочее форматирование (за исключением препроцессора) практически ничего не значат и нужны только для улучшения чтения.

VD>>И опять же причем тут не закрытые скобки и отсутствие скобок в тех местах где они не нужны?


_FR>Почему "закрытые"? Наверное, не "закрытые", а "забытые" — я это слово употребил, а "закрытые" вроде нет.


Термин не мой. Да и по фигу.

_FR> Не редко, когда скобки ставят не всегда, при добавлении выражения забывают доставить скобки и тогда случаются ошибки (смотри пример в начале сообщения).


Это. На дворе 21 век. Причем уже второе десятилетие. Любая добротная IDE это умела еще 10 лет назад.

Я помню, что когда писал на QuickC (в 1994 году), то имел проблему из-за забытой скобки. Но это было!!! 15 лет назад! Тогда IDE были полным фуфлом. Но сейчас?!...

_FR>Я вижу проблемы в том, что для того, что бы добавить внутрь условия какой-то код, надо ещё добавить скобки вокруг.


То есть проблема в том, что код нужно вводить только тогда это нужно? Супер! Аргумент из серии фиг оспоришь .

Опять же заведи себе IDE. Там есть такие фичи как снипеты. Можно просто выделить кусок кода и окружить его скобками. Хотя я как-то легко справляюсь вручную.

_FR>Мне кажется, это усложняет исправление, а, значит, и поддержку кода, ибо один из [основных!] критериев поддерживаемости — это простота и безопасность внесения изменений.


Ага — кажется.

А вообще, ты очень счастливый человек если самое сложное что тебе приходится испрвлять — это скобки. Я вот обычно часами сижу за отладчиком пытаясь понять ошибку в логике программы, а потом трачу от несколькоих секунд до нескольких минут на исправление всего кода, а не каких то там скобочек. Скобочки на этом форе не видно в микроскоп.

Да что уж там?! Я на табличное форматирование кода трачу в 100 раз больше времени чем на вписывание пары скобок. Я пока тебе отвечал, несколько скобок налепил уж если на то пошло.

_FR>То есть проблема не в статике, не в написанном, а в динамике, в том, что такой код немножко сложнее поддерживать\исправлять\расшироять\дописывать и переписывать.


Поддерживать сложно плохо написанный, и особенно, плохо спроектированный код. А есть в нем лишние скобки или нет — это вообще не проблема.

Если люди настолько не квалифицированный, что их неумение/не желание форматировать код приходится отлавливать вставкой лишних лексем, то вы на верном пути в мир ужасного кода.

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


Дык меньше их будет если не ставит лишние лексемы. Потом апелляция к тому, что сложно писать или менять код — это вообще полны лам. Тяжелее всего читать код! Все остальное фигня! И если я вижу бессмысленные вложенные скобки да еще и многоуровневые, то я начинаю упускать суть кода.

Казалось бы, причем тут Немерле? Но чем больше я пишу на этом языке тем реже у меня остается "сишных" if-ов, то есть if которые не возвращают выражение. Они конечно есть, но чаще как раз использую именно аналог сишного тернарного оператора "condition ? trueExpr : falseExpr". При этом вопросов о том писать лишние скобки или не писать даже не стоит. Ведь идиотизм писать так:
def x = if (condition) { a } else { b };
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.10 19:12
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Тоже, кстати, поинт хороший. Им стоило бы вообще запретить табы, как это сделали в F# #light.


Зачем запрещать? Достаточно не допускать их смеси в одном фале.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.10 19:30
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну они выглядят как аналогичные операции в Си, однако "работают" не так, т.е. семантика другая.


Это ты про ++? Чем же у них семантика другая? Разве что не возвращаю значения. Ну, дык это для безопасности. Хотя можно было бы итак и не преестраховываться. В Шарпе тоже не встречал проблем из-за них. Язык все же типобзеопасный, что сильно спасает от подобных бяк. Но значение то меняют по месту. Так что семантика очень близкая. По крайней мере код с их применением на немерле будет полностью идентичен сишному.

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


А где ты увидел функциональный язык? Это же не хаскель упершийся в одну парадигу.
Немерл — язык мультипарадигмынй. Он просто обязан писать в хорошем С-шном стиле. А как же этого достичь если нельзя написать классический сишный for:
for (mutable i = 0; i < 100; i++)
  ...



VD>>Ты же вроде про круглые говорил. Или ты решил все же тему махнуть?


ВВ>Ну раз вы начали тут про фигурные флеймить, то я-то чем хуже...


Мы вроде не с тобой начали.

ВВ>Мне лично понравился бы такой синтаксис:


ВВ>match (expr)

ВВ>| x => x + y
ВВ>| _ => { expr1; expr2; }

Это подразумевалось. Идя в том, что каждое вражение должно быть одним выражением, а не последовательностью. Блок — это тоже одно выражение содержащее последовательность.

В общем, жаль рук не хватает. А то реализовал бы. Иногда просто бесят эти скобки бесполезные.

ВВ>Вроде как для образца _ у нас два выражения.


Чё?

ВВ>Я, видимо, что-то не понимаю в синтаксисе Немерле, но зачем в таком случае дополнительные фигурные скобки вокруг match, неясно.


В каком в таком? В немерле каждое вхождение матча может содержать последовательность выражений. Следующий код корректен:
match (expr)
{
  | x => x + y
  | _ => expr1; expr2;
}


ВВ>Да, и раз уж речь зашла... Если было бы клево, если б сокращенный синтаксис для матча можно было бы использовать внутри любых функций, кол-во параметров которых больше нуля (а не только с одним параметром).


А это и так так.

Мы вот думали расширить это правило для методов без параметров (но экземплярных, т.е. где доступен this), чтобы можно было писать так:
public override ToString() : string
{
  | VariantOptionA(a) => $"VariantOptionA($a)"
  | VariantOptionB(b) => $"VariantOptionB($b)"
}

а не только как сейчас:
public override ToString() : string
{
  match (this)
  {
    | VariantOptionA(a) => $"VariantOptionA($a)"
    | VariantOptionB(b) => $"VariantOptionB($b)"
  }
}


ВВ>Ага, лексический скоп, в котором нельзя объявлять имена. Фишку понял


Ну, не где.

А чем это отличается от сишного switch-а? Как мне в С или C# объявить переменную внутри switch { тут } ?

ВВ>Для вхождения я никогда не предлагал скобки. В Си тоже скобки — не единственная конструкция которая задает скоп. for, например, тоже задает скоп, независимо от наличия или отсутствия скобок. Т.е. это-то ИМХО нормально.


Если быть точным, то именно в С for скопа не задает. Это так только в С++. Но, да согласен, есть отступления.

ВВ>Это все верно, но "истина где-то рядом". Если большей части людей что-то неудобно или непривычно, то возможно это действительно плохо.


А есть много людей которых чем-то не устраивает скоп в Немерле? Он даже Питонистов удовлетворяет, так как есть #pragma indent.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 20:01
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это ты про ++? Чем же у них семантика другая? Разве что не возвращаю значения. Ну, дык это для безопасности. Хотя можно было бы итак и не преестраховываться. В Шарпе тоже не встречал проблем из-за них. Язык все же типобзеопасный, что сильно спасает от подобных бяк. Но значение то меняют по месту. Так что семантика очень близкая. По крайней мере код с их применением на немерле будет полностью идентичен сишному.


В Си есть разница между пост и пре инкрементом, я об этом. А то как это сделано в Немерле — ну разница между ними просто теряет всякий смысл.
Я бы понял, если бы их вообще не было, а так получается, что "спец-эффект" оставили, а возвращаемое значение убрали.

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


VD>А где ты увидел функциональный язык? Это же не хаскель упершийся в одну парадигу.

VD>Немерл — язык мультипарадигмынй. Он просто обязан писать в хорошем С-шном стиле. А как же этого достичь если нельзя написать классический сишный for:

В хорошем Сишном стиле — это с кучей спец-эффектов, опираясь на порядок операций — в Немерле это будет уже сложно, ибо много конструкций не возвращают значение в отличие от Си.

VD>
VD>for (mutable i = 0; i < 100; i++)
VD>  ...
VD>

VD>

Ой, а оно надо, этот for?
Я вот думаю, вообще у себя открутить этот for, заменив его на конструкцию вида for x to y как в F#.
Вообще бы вам весь этот хлам засунуть в Nemerle.Imperative. А то break/continue/return именно там, а for почему-то нет.

VD>>>Ты же вроде про круглые говорил. Или ты решил все же тему махнуть?

ВВ>>Ну раз вы начали тут про фигурные флеймить, то я-то чем хуже...
VD>Мы вроде не с тобой начали.

А мне тоже хочется

ВВ>>Вроде как для образца _ у нас два выражения.

VD>Чё?

Э, я имел в виду, что в последнем вхождении после => два выражения в блоке {}.

ВВ>>Я, видимо, что-то не понимаю в синтаксисе Немерле, но зачем в таком случае дополнительные фигурные скобки вокруг match, неясно.

VD>В каком в таком? В немерле каждое вхождение матча может содержать последовательность выражений. Следующий код корректен:
VD>
VD>match (expr)
VD>{
VD>  | x => x + y
VD>  | _ => expr1; expr2;
VD>}
VD>


ОК. Теперь понятно.

ВВ>>Да, и раз уж речь зашла... Если было бы клево, если б сокращенный синтаксис для матча можно было бы использовать внутри любых функций, кол-во параметров которых больше нуля (а не только с одним параметром).


VD>А это и так так.


Не, я о том, чтобы можно было писать:

def func(x, y) { | (2, _) => ... | (3, 1) => ... }

Т.е. сам же где-то писал, что параметры функцию описываются через тюпл, так зачем ограничивать одним только параметром?
По-моему сразу видно, что именно в таком случае матчится.

VD>Мы вот думали расширить это правило для методов без параметров (но экземплярных, т.е. где доступен this), чтобы можно было писать


Это тоже было бы хорошо, но ИМХО менее очевидно.

VD>А чем это отличается от сишного switch-а? Как мне в С или C# объявить переменную внутри switch { тут } ?


Мда, убил наповал

ВВ>>Для вхождения я никогда не предлагал скобки. В Си тоже скобки — не единственная конструкция которая задает скоп. for, например, тоже задает скоп, независимо от наличия или отсутствия скобок. Т.е. это-то ИМХО нормально.

VD>Если быть точным, то именно в С for скопа не задает. Это так только в С++. Но, да согласен, есть отступления.

Разве в С99 не задает? Хотя по фиг в принципе.
Будем считать, что говоря С, я имею в виду C#

ВВ>>Это все верно, но "истина где-то рядом". Если большей части людей что-то неудобно или непривычно, то возможно это действительно плохо.

VD>А есть много людей которых чем-то не устраивает скоп в Немерле? Он даже Питонистов удовлетворяет, так как есть #pragma indent.

Да не, я не про Немерле. Мне просто интересен фидбек от программистов, привыкших к Си-подобному синтаксису — понравилось бы им, если бы круглых скобочек стало поменьше.
Re[7]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.10 21:21
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>В Си есть разница между пост и пре инкрементом, я об этом.


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

ВВ>А то как это сделано в Немерле — ну разница между ними просто теряет всякий смысл.


Именно. Но это же не другое поведение? Это же его ограничение. Причем намеренное.

ВВ>Я бы понял, если бы их вообще не было, а так получается, что "спец-эффект" оставили, а возвращаемое значение убрали.


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

ВВ>В хорошем Сишном стиле — это с кучей спец-эффектов, опираясь на порядок операций — в Немерле это будет уже сложно, ибо много конструкций не возвращают значение в отличие от Си.


Не в хорошем, а в плохом. Плохое и устраняли. Возможно чуть-чуть переборшили. В прочем, думаю, тут еще одна причина была. Насколько я понимаю, современный парсер немела не делает различий между постфиксными и префиксными формами унарных операторов. А это делает невозможным качественную реализацию С-шных операторов. Так что придется подождать Немерл 2 где это будет возможно и можно будет подменять реализацию стандартных макросов (явно и без отключения стандартной библиотеки макросов).

VD>>
VD>>for (mutable i = 0; i < 100; i++)
VD>>  ...
VD>>

VD>>

ВВ>Ой, а оно надо, этот for?


Кому-то надо. Особенно тем кто еще не слез с С-подобных языков.
По частоте применения for-а можно судить о стаже программирования на немерле . Дедушки им вообще не пользуюется .

ВВ>Я вот думаю, вообще у себя открутить этот for, заменив его на конструкцию вида for x to y как в F#.


Хозяин барин.

ВВ>Вообще бы вам весь этот хлам засунуть в Nemerle.Imperative. А то break/continue/return именно там, а for почему-то нет.


mutable тоже туба?

VD>>>>Ты же вроде про круглые говорил. Или ты решил все же тему махнуть?

ВВ>>>Ну раз вы начали тут про фигурные флеймить, то я-то чем хуже...
VD>>Мы вроде не с тобой начали.

ВВ>А мне тоже хочется




ВВ>>>Вроде как для образца _ у нас два выражения.

VD>>Чё?

ВВ>Э, я имел в виду, что в последнем вхождении после => два выражения в блоке {}.


Ну, так блок же одно выражение?

Хотя можно и его запретить. Дурное дело не хитрое.

ВВ>>>Да, и раз уж речь зашла... Если было бы клево, если б сокращенный синтаксис для матча можно было бы использовать внутри любых функций, кол-во параметров которых больше нуля (а не только с одним параметром).


VD>>А это и так так.


ВВ>Не, я о том, чтобы можно было писать:


ВВ>def func(x, y) { | (2, _) => ... | (3, 1) => ... }


Так оно и есть. Мог бы попробовать прежде чем писать.

VD>>Мы вот думали расширить это правило для методов без параметров (но экземплярных, т.е. где доступен this), чтобы можно было писать


ВВ>Это тоже было бы хорошо, но ИМХО менее очевидно.


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

VD>>А чем это отличается от сишного switch-а? Как мне в С или C# объявить переменную внутри switch { тут } ?


ВВ>Мда, убил наповал


Чем это?

ВВ>Разве в С99 не задает? Хотя по фиг в принципе.

ВВ>Будем считать, что говоря С, я имею в виду C#




ВВ>Да не, я не про Немерле. Мне просто интересен фидбек от программистов, привыкших к Си-подобному синтаксису — понравилось бы им, если бы круглых скобочек стало поменьше.


Ну, тут все очень просто. Сколько людей столько и мнений. Но если сделать как в С, то все поймут, а если сделать по другому, то сразу появится лагерь поклонников и недовольных.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Про скобки и одно выражение
От: SergeCpp Россия http://zoozahita.ru
Дата: 26.04.10 21:36
Оценка:
Здравствуйте, Воронков Василий!

ВВ>Писать скобки в случае одного выражения или не писать — это тема для отдельного флейма и вроде как такой флейм тут недавно был, смысла в его продолжении я не вижу.


В Visual Studio одно время (версия 5 и ещё 6 вроде) было нужно писать вот так:
for(;;)
{
    i++;
}

для прохода в отладчике по шагам несколько итераций; вот так:
for(;;)
    i++;

не получалось. Может, в новых версиях уже и можно.

Кстати, вот так:
for(;;) {
    i++;
}

тоже не получалось тогда, что и явилось одним из мотивов перехода на:
for(;;)
{
    i++;
}
http://zoozahita.ruБездомные животные Екатеринбурга ищут хозяев
Re[8]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 21:58
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Именно. Но это же не другое поведение? Это же его ограничение. Причем намеренное.

ВВ>>Я бы понял, если бы их вообще не было, а так получается, что "спец-эффект" оставили, а возвращаемое значение убрали.
VD>Дык сам оператор полезен, а возврат значения вызывает ошибки. В дизайн языка намеренно не вносились плохие или спорные решения.

Кстати, я никогда это не понимал. Все же просто, обычная последовательность операций, какая разница "в строчку" они записаны или "в столбик". Как и с оператором ассайнмента. Почему плохо то, что он возвращает значение?

ВВ>>В хорошем Сишном стиле — это с кучей спец-эффектов, опираясь на порядок операций — в Немерле это будет уже сложно, ибо много конструкций не возвращают значение в отличие от Си.


VD>Не в хорошем, а в плохом. Плохое и устраняли. Возможно чуть-чуть переборшили. В прочем, думаю, тут еще одна причина была. Насколько я понимаю, современный парсер немела не делает различий между постфиксными и префиксными формами унарных операторов. А это делает невозможным качественную реализацию С-шных операторов. Так что придется подождать Немерл 2 где это будет возможно и можно будет подменять реализацию стандартных макросов (явно и без отключения стандартной библиотеки макросов).


Интересно. А парсер врукопашную написан?

VD>Кому-то надо. Особенно тем кто еще не слез с С-подобных языков.

VD>По частоте применения for-а можно судить о стаже программирования на немерле . Дедушки им вообще не пользуюется .

Мне кажется for в таком виде изначально задумывался как некая универсальная конструкция для организации циклов. И даже в C# он особо и не нужен. Ну т.е. я пользуюсь for-ом, конечно, но это всегда строго перебор значений в некотором диапазоне, и все его навороты оказываются за бортом.
А в этом плане for/to на манер F# мне кажется более культурным, что ли, вариантом.

ВВ>>Вообще бы вам весь этот хлам засунуть в Nemerle.Imperative. А то break/continue/return именно там, а for почему-то нет.

VD>mutable тоже туба?

mutable не трожь
Он-то не мешает писать функциональный код, а вот вышеозначенное — конструкции для типичного императивного flow. Ими можно вообще не пользоваться. А вот мутабельными переменными вообще не пользоваться нельзя, все же Немерле не чистый язык.

ВВ>>def func(x, y) { | (2, _) => ... | (3, 1) => ... }

VD>Так оно и есть. Мог бы попробовать прежде чем писать.

О, круто
Непонятно, почему я считал, что параметр должен быть один. И в статье по Немерле у тебя написано, что несколько параметров интерпретируются как кортеж.
Видимо, я напутал с OCaml-ом.

VD>>>Мы вот думали расширить это правило для методов без параметров (но экземплярных, т.е. где доступен this), чтобы можно было писать


ВВ>>Это тоже было бы хорошо, но ИМХО менее очевидно.


VD>Очевидно то, что люди ожидают увидеть. Я уже раз пять слышал об этом. Плюс сам иногда не задумываясь писал так и получал облом от компилятора.


Хз, честно
С одной стороны, это логично. С другой — если бы я увидел такой код, то может и не сразу понял бы, что там match-ится.

VD>>>А чем это отличается от сишного switch-а? Как мне в С или C# объявить переменную внутри switch { тут } ?

ВВ>>Мда, убил наповал
VD>Чем это?

Ну, про switch я как-то забыл

ВВ>>Да не, я не про Немерле. Мне просто интересен фидбек от программистов, привыкших к Си-подобному синтаксису — понравилось бы им, если бы круглых скобочек стало поменьше.

VD>Ну, тут все очень просто. Сколько людей столько и мнений. Но если сделать как в С, то все поймут, а если сделать по другому, то сразу появится лагерь поклонников и недовольных.

Это верно. Стандартный выбор — сделать хорошо или привычно. А может быть, плохо или привычно. Тут уж как повезет.
Все же синтасис Си перегружен этой скобочностью, мне кажется. Тот же шарп воспроизводит его практически один-в-один (Немерле — в меньшей степени), и часто получается лес скобочек, причем с совершенно разной семантикой. И ведь в принципе можно же вполне уменьшить их количество
Re[8]: Про скобки и одно выражение
От: Воронков Василий Россия  
Дата: 26.04.10 22:01
Оценка:
Здравствуйте, SergeCpp, Вы писали:

Это, так сказать, language dependent мотивы. Например, на JavaScript я всегда использую нотацию K&R по той простой причине, что там есть зловредный механизм под названием semicolon insertion, который по сути препроцессит файлы и может вставить лишнего.
Речь о синтаксисе все же.
Re[9]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.10 22:58
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Кстати, я никогда это не понимал. Все же просто, обычная последовательность операций, какая разница "в строчку" они записаны или "в столбик". Как и с оператором ассайнмента. Почему плохо то, что он возвращает значение?


Ну, тут понимание или есть сразу, или его нет вообще .

Сайд-эффекты — это вам не неправильное форматирование. Незаметный ошибочный сайд-эффект можно искать очень долго.

ВВ>Интересно. А парсер врукопашную написан?


Да. Но в следующей версии планируется использовать PEG. Он должен обеспечить как беспрецедентную расширяемость, так так и требуемую гибкость (значительно большую чем есть сейчас).


ВВ>>>Вообще бы вам весь этот хлам засунуть в Nemerle.Imperative. А то break/continue/return именно там, а for почему-то нет.

VD>>mutable тоже туба?

ВВ>mutable не трожь


Не последовательно как-то.

ВВ>Он-то не мешает писать функциональный код, а вот вышеозначенное — конструкции для типичного императивного flow. Ими можно вообще не пользоваться. А вот мутабельными переменными вообще не пользоваться нельзя, все же Немерле не чистый язык.


mutable — это самая базовая императивная конструкция. Без него императив не возможен.

ВВ>Непонятно, почему я считал, что параметр должен быть один.


В психологии — это называют "ожидание худшего".

ВВ> И в статье по Немерле у тебя написано, что несколько параметров интерпретируются как кортеж.

ВВ>Видимо, я напутал с OCaml-ом.

А там не так?

ВВ>Это верно. Стандартный выбор — сделать хорошо или привычно. А может быть, плохо или привычно. Тут уж как повезет.


Ну, да. По этому я лично придерживаюсь очень простого правила. Привычное надо менять только тогда когда оно создает реальные проблемы (ощутимые и не обходимые другими путями). Вот сишное приведение типов, задание типов переменных спереди, четкое выделение операторов в виде стэйтментов, делегаты в качестве замены функциональных типов и многое другое — это явно плохое. И избежание повторения таких привычных вещей легко объяснимо, а значит правильно. А вот отказ от скобок и оператора for — не объяснимо и по сути не нужно. Это привычки людей. А людей не надо ломать об колено. Им еще ФП и МП учить. Пусть уж лучше они учат их в привычной среде.

ВВ>Все же синтасис Си перегружен этой скобочностью, мне кажется.


Вы еще Лисп не видели, коллега! (с)

ВВ> Тот же шарп воспроизводит его практически один-в-один (Немерле — в меньшей степени), и часто получается лес скобочек, причем с совершенно разной семантикой. И ведь в принципе можно же вполне уменьшить их количество


А жалобы есть от тех кто С-подобные языки пользует? Нет? Ну, а что тогда копья ломать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Про скобочки
От: Воронков Василий Россия  
Дата: 26.04.10 23:38
Оценка:
Здравствуйте, VladD2, Вы писали:

ВВ>>Кстати, я никогда это не понимал. Все же просто, обычная последовательность операций, какая разница "в строчку" они записаны или "в столбик". Как и с оператором ассайнмента. Почему плохо то, что он возвращает значение?

VD>Ну, тут понимание или есть сразу, или его нет вообще .
VD>Сайд-эффекты — это вам не неправильное форматирование. Незаметный ошибочный сайд-эффект можно искать очень долго.

Вот объясни мне как *возвращаемое значение* может привести к *незаметному* ошибочному сайд-эффекту?

ВВ>>Интересно. А парсер врукопашную написан?

VD>Да. Но в следующей версии планируется использовать PEG. Он должен обеспечить как беспрецедентную расширяемость, так так и требуемую гибкость (значительно большую чем есть сейчас).

Т.е. там можно составить расширяемое формальное описание грамматики?

ВВ>>mutable не трожь

VD>Не последовательно как-то.
VD>mutable — это самая базовая императивная конструкция. Без него императив не возможен.

Дык без него вообще писать затруднительно, в том-то и дело.
Немерле же не ставит цель убрать сайд-эффекты вообще.

ВВ>>Непонятно, почему я считал, что параметр должен быть один.

VD>В психологии — это называют "ожидание худшего".

А мне казалось, это называется "каша в голове".

ВВ>> И в статье по Немерле у тебя написано, что несколько параметров интерпретируются как кортеж.

ВВ>>Видимо, я напутал с OCaml-ом.
VD>А там не так?

AFAIR там есть ключевое слово function. Если с помощью него объявить функцию, то внутри нее можно использовать сокращенный паттерн-матчинг, но функция при этом будет принимать только один параметр, явно не указываемый.

ВВ>>Это верно. Стандартный выбор — сделать хорошо или привычно. А может быть, плохо или привычно. Тут уж как повезет.


VD>Ну, да. По этому я лично придерживаюсь очень простого правила. Привычное надо менять только тогда когда оно создает реальные проблемы (ощутимые и не обходимые другими путями). Вот сишное приведение типов, задание типов переменных спереди, четкое выделение операторов в виде стэйтментов, делегаты в качестве замены функциональных типов и многое другое — это явно плохое. И избежание повторения таких привычных вещей легко объяснимо, а значит правильно. А вот отказ от скобок и оператора for — не объяснимо и по сути не нужно. Это привычки людей. А людей не надо ломать об колено. Им еще ФП и МП учить. Пусть уж лучше они учат их в привычной среде.


Однако ж "странный синтаксис" не мешает тому же Питону пользоваться большой популярностью.

Вот Си-касты — плохо, согласен. А почему плохо? Невыразительный синтаксис, "сливается", не всегда и видно с первого взгляда, где тут приведение. Короче, скобочек много. И в данном случае ML-ный :> как раз альтернатива скобкам. Как do здесь:

for x in y do
  expr


ВВ>>Все же синтасис Си перегружен этой скобочностью, мне кажется.

VD>Вы еще Лисп не видели, коллега! (с)

В Лиспе скобочек много, но семантика их всегда одинакова. Разве нет?

ВВ>> Тот же шарп воспроизводит его практически один-в-один (Немерле — в меньшей степени), и часто получается лес скобочек, причем с совершенно разной семантикой. И ведь в принципе можно же вполне уменьшить их количество

VD>А жалобы есть от тех кто С-подобные языки пользует? Нет? Ну, а что тогда копья ломать?

А я не в счет?
Re[11]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.04.10 01:00
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

VD>>Сайд-эффекты — это вам не неправильное форматирование. Незаметный ошибочный сайд-эффект можно искать очень долго.


ВВ>Вот объясни мне как *возвращаемое значение* может привести к *незаметному* ошибочному сайд-эффекту?


Для не внимательных выделил лопату жирным.

ВВ>Т.е. там можно составить расширяемое формальное описание грамматики?


Да. И каждый макрос будет правилом такой грамматики. Причем маклос сможет использовать любые другие правила введенные другими макросами доступными к этому времени в скомпилированном виде (т.е. подключенные к проекту).

ВВ>Дык без него вообще писать затруднительно, в том-то и дело.


Ну, почему же? ФП доказанно полон по Тьюрингу. Не всегда эффективен, не всегда достаточно гибок, но писать можно что угодно.

ВВ>Немерле же не ставит цель убрать сайд-эффекты вообще.


Нет. По этому и паранойи с вносом цилка черти куда нет.

ВВ>Однако ж "странный синтаксис" не мешает тому же Питону пользоваться большой популярностью.


Он к этому шел (идет) где-то 15 (а то и больше) лет. И до сих пор не достиг поплярности даже C#-а.
Плюс — это скрипт который часто используют для "несерьёзных целей". Это позволило ему проникнуть в массы.

Короче, можешь попытать счастье. Может твой синтаксис (тет через 15) тоже проникнет в массы.

ВВ>Вот Си-касты — плохо, согласен. А почему плохо? Невыразительный синтаксис, "сливается", не всегда и видно с первого взгляда, где тут приведение. Короче, скобочек много. И в данном случае ML-ный :> как раз альтернатива скобкам. Как do здесь:


Дело не в скобочках. Дело в том, что это контекстно зависмая грамматика. В С/С++ чтобы отличить приведение от других выражений нужно знать тип выражения внутри скобок. В C# водится эвристика которая вызвает некоторые побочные эффекты. Ну, и человек тоже плохо эти эвристики съедает. Скобки же здесь не причем. В тех же кортежах тоже скобки используются, но проблем они не вызывают.

ВВ>В Лиспе скобочек много, но семантика их всегда одинакова. Разве нет?


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

VD>>А жалобы есть от тех кто С-подобные языки пользует? Нет? Ну, а что тогда копья ломать?


ВВ>А я не в счет?


Ах, ты. Да ты в счет. Итак счет 1 к скольки там?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Про скобочки
От: Undying Россия  
Дата: 27.04.10 03:34
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях. Например, вместо


Крайне отрицательно, читабельность резко ухудшится.
Re[9]: Про скобочки
От: Undying Россия  
Дата: 27.04.10 03:43
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я не считаю, что проблемы — это предмет веры. Они или есть, или нет. Если у меня есть выражение:

VD>
VD>when (a)
VD>  b();
VD>


В этом случае естественно скобочки не нужны. А вот уже в таком случае:

if (a)
{
  DevExpressHlp.ShowUserControlAsForm(new ScheduleEditor(dbConnection, typeBox, routeBox, jointBox,
    ref editScheduleId, markerIds, null, true));
}


или

if (a)
  DevExpressHlp.ShowUserControlAsForm(new ScheduleEditor(dbConnection, typeBox, routeBox, jointBox,
    ref editScheduleId, markerIds, null, true));


Со скобочками читается гораздо лучше, чем без них.
Re: Про скобочки
От: Undying Россия  
Дата: 27.04.10 03:47
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>
ВВ>for x in y do
ВВ>  expr
ВВ>


А, кстати, в чем выигрышь-то? Вместо двух скобочек появился один лишний пробел + "do".

ВВ>
ВВ>if x > y then
ВВ>  expr
ВВ>else
ВВ>  expr
ВВ>


Опять же вместо двух скобочек появилось аж пять символов — лишний пробел + "then".

Т.е. и лаконичность записи ухудшиться, и взгляду не за что будет цепляться. А выгода в чем?
Re: Про скобочки
От: night beast СССР  
Дата: 27.04.10 04:11
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Известно, что в Си-подобном синтаксисе круглые скобочки несколько перегружены смыслом. Это и средство для группировки выражений, и часть грамматики некоторых стандартных выражений вроде for, if и вызов функции, и приведение типов...

ВВ>На мой взгляд это несколько снижает читабельность.

ВВ>А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях. Например, вместо


ВВ>for (x in y) 
ВВ>  expr


ВВ>было бы


ВВ>for x in y do
ВВ>  expr


а как такой вариант:
for x in (y)
  exprs

?


ВВ>Или вместо


ВВ>if (x > y)
ВВ>  expr
ВВ>else
ВВ>  expr


ВВ>было бы


ВВ>if x > y then
ВВ>  expr
ВВ>else
ВВ>  expr


и
if ( x>y ) then (expr) else (expr);



ВВ>Само собой при сохранении остальной си-подобности.
Re[11]: Про скобочки
От: Undying Россия  
Дата: 27.04.10 04:28
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Не, ну, возможно есть хроники которые ошибки месяцами выявлюят. У меня в худшем случае на сложную ошибку уходит 2-3 дня. И это точно не ошибки из разряда плохое форматирование.


Причем здесь скорость выявления причин известной ошибки? На исправление ошибки программист может и пять минут тратить, только толку от этого немного, т.к. если ошибка не шибко часто встречающаяся (и тем более без исключения), то пользователи о ней могут сообщить программисту через несколько месяцев, а то и вообще никогда. И все это время периодически натыкаясь на эту ошибку пользователи будут думать, что им вместо нормальной программы подсунули какую-то криво работающую поделку.
Re: Про скобочки
От: Pavel Dvorkin Россия  
Дата: 27.04.10 05:07
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях. Например, вместо


И получился у тебя Паскаль — почти 1:1
With best regards
Pavel Dvorkin
Re[9]: Про скобочки
От: FR  
Дата: 27.04.10 06:28
Оценка:
Здравствуйте, Воронков Василий, Вы писали:


ВВ>>>def func(x, y) { | (2, _) => ... | (3, 1) => ... }

VD>>Так оно и есть. Мог бы попробовать прежде чем писать.

ВВ>О, круто

ВВ>Непонятно, почему я считал, что параметр должен быть один. И в статье по Немерле у тебя написано, что несколько параметров интерпретируются как кортеж.
ВВ>Видимо, я напутал с OCaml-ом.


let func = function
  | 2, _  -> 0
  | 3, 1  -> 1
  | x, y  -> x * y
Re[10]: Про скобочки
От: Воронков Василий Россия  
Дата: 27.04.10 09:37
Оценка:
Здравствуйте, FR, Вы писали:

FR>
FR>let func = function
FR>  | 2, _  -> 0
FR>  | 3, 1  -> 1
FR>  | x, y  -> x * y
FR>


Ну это все равно функция с одним параметром. Тип параметра — кортеж.
Re[8]: Про скобочки
От: Temoto  
Дата: 27.04.10 09:49
Оценка:
ВВ>>А там можно получить неправильную программу просто вставив лишний пробел

FR>Пробел фигня, вот неправильный таб вообще может до смертоубийства довести


В чём разница?
Re[11]: Про скобочки
От: FR  
Дата: 27.04.10 10:05
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну это все равно функция с одним параметром. Тип параметра — кортеж.


Это да, код аналогичен Немерлевскому, но в Немерли параметры преобразуются к кортежу, но с несколькими параметрами на OCaml
тоже несложно сделать:

let func x y = match x, y with
  | 2, _  -> 0
  | 3, 1  -> 1
  | x, y  -> x * y
Re[9]: Про скобочки
От: FR  
Дата: 27.04.10 10:07
Оценка:
Здравствуйте, Temoto, Вы писали:

T>В чём разница?


Сейчас уже ничем вроде, это я просто вспомнил веселый поиск ошибки на питоне кажется версии 2.2,
которая такие вещи не отлавливала и не выдавала ни варнингов ни ошибок.
Re: Про скобочки
От: DSblizzard Россия  
Дата: 27.04.10 10:22
Оценка:
Здравствуйте, Воронков Василий,

Я бы предпочел тот вариант, который короче (в данном случае — со скобками). Т. к. к синтаксису Си не прикипел, то читаемость обоих вариантов одинаковая.
Программировать сложно. Но не программировать еще сложнее.
Re[10]: Про скобочки
От: Temoto  
Дата: 27.04.10 10:30
Оценка:
T>>В чём разница?

FR>Сейчас уже ничем вроде, это я просто вспомнил веселый поиск ошибки на питоне кажется версии 2.2,

FR>которая такие вещи не отлавливала и не выдавала ни варнингов ни ошибок.

Какие вещи?

#   = пробел
# … = таб
def foo():
  def bar():
  …print "валидный таб"

  def zar():
  ……print 'валидный "лишний" таб'


Без -t даже варнинга не будет.
Re[9]: Про скобочки
От: Воронков Василий Россия  
Дата: 27.04.10 10:59
Оценка:
Здравствуйте, Temoto, Вы писали:

ВВ>>>А там можно получить неправильную программу просто вставив лишний пробел

FR>>Пробел фигня, вот неправильный таб вообще может до смертоубийства довести
T>В чём разница?

Дополнительная фишка таба в том, что его длина может отличаться в зависимости от настроек редактора.
Re[10]: Про скобочки
От: Temoto  
Дата: 27.04.10 11:04
Оценка:
ВВ>>>>А там можно получить неправильную программу просто вставив лишний пробел
FR>>>Пробел фигня, вот неправильный таб вообще может до смертоубийства довести
T>>В чём разница?

ВВ>Дополнительная фишка таба в том, что его длина может отличаться в зависимости от настроек редактора.


И ширина пробела тоже может отличаться, в зависимости от используемого шрифта. С другой стороны, все редакторы позволяют настроить ширину табов по вкусу. И самое главное: ну и пусть она отличается, что с того?

Ох, похоже я стролился на tab-space holy war, там вроде речь шла о том, что "неправильный таб" хуже лишнего пробела. Пытаюсь понять чем именно.
Re[12]: Про скобочки
От: Воронков Василий Россия  
Дата: 27.04.10 11:08
Оценка: +1
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Ну это все равно функция с одним параметром. Тип параметра — кортеж.
FR>Это да, код аналогичен Немерлевскому,

Не совсем. Все же в Немерле функция вида

def func(x, y) { | 2, _ -> 0 | _ -> ... }


Это функция с несколькими параметрами и для нее возможно частичное применение. Для функции, объявленной через function, — нет.

FR>но в Немерли параметры преобразуются к кортежу, но с несколькими параметрами на OCaml

FR>тоже несложно сделать:

Это понятно. Речь была про сокращенную запись.
Re[11]: Про скобочки
От: Воронков Василий Россия  
Дата: 27.04.10 11:13
Оценка:
Здравствуйте, Temoto, Вы писали:

T>И ширина пробела тоже может отличаться, в зависимости от используемого шрифта. С другой стороны, все редакторы позволяют настроить ширину табов по вкусу. И самое главное: ну и пусть она отличается, что с того?

T>Ох, похоже я стролился на tab-space holy war, там вроде речь шла о том, что "неправильный таб" хуже лишнего пробела. Пытаюсь понять чем именно.

Ширина таба == энное количество пробелов. Если ты форматируешь код пробелами, то он и у меня и у тебя будет выглядеть одинаково, какой бы шрифт ты не использовал. При смеси пробелов и табов у меня, допустим, все будет выглядеть нормально, а у тебя "поедет" форматирование.
Короче, неправильный пробел ты всегда можешь заметить, а неправильный таб — не факт. Только если включать в редакторе отображение табов и пробелов.
Re[12]: Про скобочки
От: Temoto  
Дата: 27.04.10 11:42
Оценка:
T>>И ширина пробела тоже может отличаться, в зависимости от используемого шрифта. С другой стороны, все редакторы позволяют настроить ширину табов по вкусу. И самое главное: ну и пусть она отличается, что с того?
T>>Ох, похоже я стролился на tab-space holy war, там вроде речь шла о том, что "неправильный таб" хуже лишнего пробела. Пытаюсь понять чем именно.

ВВ>Ширина таба == энное количество пробелов.


... в твоём (и моём редакторе). А в другом ширина таба задаётся в пикселях.

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


Текст не может выглядеть одинаково в разных шрифтах, Василий, ты чего. Всё равно что сказать, что веб-страницы будут выглядеть одинаково с разными CSS.

ВВ>При смеси пробелов и табов у меня, допустим, все будет выглядеть нормально, а у тебя "поедет" форматирование.

ВВ>Короче, неправильный пробел ты всегда можешь заметить, а неправильный таб — не факт. Только если включать в редакторе отображение табов и пробелов.

Понял твою позицию.
Re: Про скобочки
От: ShaggyOwl Россия http://www.rsdn.org
Дата: 27.04.10 11:44
Оценка:
Питоновский вариант вполне симпатичен
for x in y :
  expr


if x > y :
  expr
else :
  expr
Хорошо там, где мы есть! :)
Re[13]: Про скобочки
От: Воронков Василий Россия  
Дата: 27.04.10 12:13
Оценка:
Здравствуйте, Temoto, Вы писали:

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

T>Текст не может выглядеть одинаково в разных шрифтах, Василий, ты чего. Всё равно что сказать, что веб-страницы будут выглядеть одинаково с разными CSS.

Он выглядит одинаково в смысле, что он отформатирован одинаково. Если мы используем моноширинные шрифты, то код вида будет выглядеть одинаково независимо от "длины" пробела:

void SomeFunction(type param1,
                  type param2,
                  type param3);


Проблема табов тут в том, что если бы я стал форматировать таблично табами, то при разной ширине табов это форматирование поплывет.

А вообще я сам при форматировании использую табы
Re[11]: Про скобочки
От: FR  
Дата: 27.04.10 13:04
Оценка:
Здравствуйте, Temoto, Вы писали:


T>
T>#   = пробел
T># … = таб
T>def foo():
T>  def bar():
T>  …print "валидный таб"

T>  def zar():
T>  ……print 'валидный "лишний" таб'
T>


T>Без -t даже варнинга не будет.


А тут где ошибка?

То что у нас было мне мешает вспомнить склероз, но суть в том
что внешне выглядящий нормально код воспринимался интерпретатором
совсем по другому чем выглядел
Re[12]: Про скобочки
От: Temoto  
Дата: 27.04.10 13:21
Оценка:
T>>
T>>#   = пробел
T>># … = таб
T>>def foo():
T>>  def bar():
T>>  …print "валидный таб"

T>>  def zar():
T>>  ……print 'валидный "лишний" таб'
T>>


T>>Без -t даже варнинга не будет.


FR>А тут где ошибка?


Тут нет ошибки.

FR>То что у нас было мне мешает вспомнить склероз, но суть в том

FR>что внешне выглядящий нормально код воспринимался интерпретатором
FR>совсем по другому чем выглядел

Понятно. Это, наверное, потому что табы редактор не выделял.
Re: Про скобочки
От: Кэр  
Дата: 27.04.10 22:59
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях.


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

То есть в общем случае, правильное решение со скобочками — выбирать вариант, который может быть поддержан автоматически и иметь тулзу, которая не дает коммитить код не соответствующий стандартам. Тем самым поддерживая принцип "наименьшего удивления".
Re[2]: Про скобочки
От: Воронков Василий Россия  
Дата: 27.04.10 23:47
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>StyleCop в C# заставляет расставлять скобки везде. Так как на самом деле все равно ставить или нет в большинстве случаев (когда можно написать и так, и так) — то лучший вариант, который контролируется автоматически.

Кэр>То есть в общем случае, правильное решение со скобочками — выбирать вариант, который может быть поддержан автоматически и иметь тулзу, которая не дает коммитить код не соответствующий стандартам. Тем самым поддерживая принцип "наименьшего удивления".

Это ты к чему вообще?
Re[3]: Про скобочки
От: Кэр  
Дата: 28.04.10 01:12
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Это ты к чему вообще?


К тому что этот вопрос про скобочки — это вопрос стиля написания кода. А стиль кода должен быть просто однообразным в проекте. Если есть тулза, которая может это автоматически поддерживать — то нужно выбирать вариант, который эта тулза может поддерживать.
Re[2]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.04.10 03:47
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>То есть в общем случае, правильное решение со скобочками — выбирать вариант, который может быть поддержан автоматически и иметь тулзу, которая не дает коммитить код не соответствующий стандартам. Тем самым поддерживая принцип "наименьшего удивления".


Не приходило в голову, что "тулзу" можно подправить?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Про скобочки
От: Кэр  
Дата: 28.04.10 07:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Не приходило в голову, что "тулзу" можно подправить?


Конкретно здесь или в общем случае?

В случае с этими скобочками — вообще довольно все равно, как писать. Правило "скобочки должны быть всегда" — легко запомнить, легко применить, легко проверить автоматически.

В общем случае — опять же зачем? Куда эти инвестиции? Кто это будет тестировать и поддерживать в команде?
Re[2]: Про скобочки
От: Temoto  
Дата: 28.04.10 08:56
Оценка:
ВВ>>А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях.

Кэр>StyleCop в C# заставляет расставлять скобки везде. Так как на самом деле все равно ставить или нет в большинстве случаев (когда можно написать и так, и так) — то лучший вариант, который контролируется автоматически.


Кэр>То есть в общем случае, правильное решение со скобочками — выбирать вариант, который может быть поддержан автоматически и иметь тулзу, которая не дает коммитить код не соответствующий стандартам. Тем самым поддерживая принцип "наименьшего удивления".


Любой стиль может быть проверен автоматически.
Re[4]: Про скобочки
От: Воронков Василий Россия  
Дата: 28.04.10 10:45
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Это ты к чему вообще?
Кэр>К тому что этот вопрос про скобочки — это вопрос стиля написания кода. А стиль кода должен быть просто однообразным в проекте. Если есть тулза, которая может это автоматически поддерживать — то нужно выбирать вариант, который эта тулза может поддерживать.

Только я спрашивал не о стиле, а о грамматике.
Re[2]: Про скобочки
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 28.04.10 14:21
Оценка: +2
Здравствуйте, Кэр, Вы писали:

Кэр>StyleCop


StyleCop это нифига не аргумент. Там много очень странного есть, типа обязательного this.
... << RSDN@Home 1.2.0 alpha 4 rev. 1471 on Windows 7 6.1.7600.0>>
AVK Blog
Re[9]: Про скобочки
От: March_rabbit  
Дата: 28.04.10 14:39
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>Я вот уже двадцать лет не пишу фигурные скобки так где это возможно и ни разу не нарывался на эти "последствия".


_FR>>Во-первых, откуда знаешь про "ни разу", может не все ошибки ещё нашёл


VD>Ну, я как-то думал, что трудно не заметить того, что нарвался на проблемы. Нет?

ты один над программами работаешь? Не приходилось у себя чинить то, что на деле являлось последствием ошибки в чужом модуле? Ошибка есть, но стреляет так, что последствия всплывают в совсем другом коде. Бывало такое.....
Re[3]: Про скобочки
От: Кэр  
Дата: 28.04.10 17:10
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>StyleCop это нифига не аргумент. Там много очень странного есть, типа обязательного this.


StyleCop — это просто пример общей идеи.

А вообще после того, как я поставил вот это:
http://stylecopforresharper.codeplex.com/
и немного затвикал сам ReSharper (в частности, чтобы он тоже думал что this обязателен) — то все становится вполне удобно. Более того, когда масса кода написана именно в таком стиле — то привыкаешь к тому, что private поля идут сначала, что свойства идут после конструктора, что все будет прокомментировано — вполне удобно. Плагин StyleCop следит за стилем в реальном времени, поэтому код пишется сразу в нужном стиле. Нет мучительного момента, когда надо сделать 500 стилистических правок, только чтобы зачекинить код.
Re[10]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.04.10 17:14
Оценка:
Здравствуйте, March_rabbit, Вы писали:

M_>ты один над программами работаешь?


Нет. Частенько и большой командой. Хотя бывает и один.

M_> Не приходилось у себя чинить то, что на деле являлось последствием ошибки в чужом модуле?


Нет. Но приходилось откатывать кривые изменения других людей. Првада не часто. Раза три за всю жизнь.

M_> Ошибка есть, но стреляет так, что последствия всплывают в совсем другом коде. Бывало такое.....


И причем тут скобки? Не уж то от них такой эффект?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Про скобочки
От: Кэр  
Дата: 28.04.10 17:18
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Только я спрашивал не о стиле, а о грамматике.


Вопрос о грамматике нужно решать в контексте конкретного языка. Где-то подобное отсутствие скобочек и началие then или do — это жуткий кошмар при разбитии на токены. Где-то это будет легко и незаметно.
Так что вопрос на самом деле про стиль и кому как нравится. И именно этот вопрос обсуждается здесь и выше по ветке. И моя позиция — на самом деле нужно просто чтобы стилистические правила были простые и непротиворечивые. А привыкнуть можно к любому стилю. Ну и сама суть стиля кода — разработчики должны придерживаться этого стиля. Именно этого проще и лучше всего добиваться автоматизацией.
Re[6]: Про скобочки
От: Temoto  
Дата: 28.04.10 17:24
Оценка:
ВВ>>Только я спрашивал не о стиле, а о грамматике.

Кэр>Вопрос о грамматике нужно решать в контексте конкретного языка. Где-то подобное отсутствие скобочек и началие then или do — это жуткий кошмар при разбитии на токены. Где-то это будет легко и незаметно.

Кэр>Так что вопрос на самом деле про стиль и кому как нравится. И именно этот вопрос обсуждается здесь и выше по ветке. И моя позиция — на самом деле нужно просто чтобы стилистические правила были простые и непротиворечивые. А привыкнуть можно к любому стилю. Ну и сама суть стиля кода — разработчики должны придерживаться этого стиля. Именно этого проще и лучше всего добиваться автоматизацией.

Вот здесь я с ним согласен.

Видишь, Василий, опять нужна идея и от неё будет плясать грамматика.

<фантазия>
А ещё было бы круто иметь редактор, который просто не даёт писать грамматически/стиллистически неверный код. Не потому что он исправляет текст, а потому что он пишет код, то есть AST. Нужен AST редактор, вместо текстового. Тогда вопрос стиля отпадает сам собой, потому что стиль становится просто форматом сериализации аста на диск, то есть невидим для разработчиков и комилятора.
</фантазия>
Re[7]: Про скобочки
От: Воронков Василий Россия  
Дата: 28.04.10 18:29
Оценка:
Здравствуйте, Temoto, Вы писали:

T>Вот здесь я с ним согласен.


С ним — это с кем? С Кэром? Т.е. ты овечаешь на пост человека и говоришь о нем в третьем лице? Это мощный ход

T>Видишь, Василий, опять нужна идея и от неё будет плясать грамматика.


Идея простая — сделать синтаксис, легкий для восприятия. Но "легкий для восприятия" — понятие весьма субьективное. Меня последнее время начинают слегка доставать скобочки, но это видимо потому что я последнее время много вожусь с языками, где скобочек меньше, и на их фоне становятся весьма заметны некоторые недостатки Си-подобного синтаксиса.

Вопрос, если хочешь, — а можно ли сократить количество не скобочек даже, а их семантических значений в языке, не слишком навредив этим привычкам программистов?

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

А ты, кстати, свое мнение по поводу скобочек не высказал

T><фантазия>

T>А ещё было бы круто иметь редактор, который просто не даёт писать грамматически/стиллистически неверный код. Не потому что он исправляет текст, а потому что он пишет код, то есть AST. Нужен AST редактор, вместо текстового. Тогда вопрос стиля отпадает сам собой, потому что стиль становится просто форматом сериализации аста на диск, то есть невидим для разработчиков и комилятора.
T></фантазия>

На выбенете не писал?
Re[8]: Про скобочки
От: Temoto  
Дата: 28.04.10 20:32
Оценка:
T>>Вот здесь я с ним согласен.
ВВ>С ним — это с кем? С Кэром? Т.е. ты овечаешь на пост человека и говоришь о нем в третьем лице? Это мощный ход

С Кэром, да.

T>>Видишь, Василий, опять нужна идея и от неё будет плясать грамматика.


ВВ>Идея простая — сделать синтаксис, легкий для восприятия. Но "легкий для восприятия" — понятие весьма субьективное. Меня последнее время начинают слегка доставать скобочки, но это видимо потому что я последнее время много вожусь с языками, где скобочек меньше, и на их фоне становятся весьма заметны некоторые недостатки Си-подобного синтаксиса.


ВВ>Вопрос, если хочешь, — а можно ли сократить количество не скобочек даже, а их семантических значений в языке, не слишком навредив этим привычкам программистов?


Не навредив привычкам это не ко мне вопрос у меня всегда с такими вещами плохо было. Я не вижу ничего плохого в том, чтобы переучиться для использования нового инструмента *если это оправдано*.

Мы про фигурные скобки ведь? У них семантическое значение — границы блоков. Единственный способ, что я вижу чтоб убрать их, так это убрать понятие блоков. В эрланге, например, это сделано с помощью одного, завершающего блок символа '.' (ещё иногда ';', это не суть важно сейчас). По сути, там только закрывающая фигурная скобка.

ВВ>Вот Влад к примеру высказал тут вполне простую позицию. Лучше сделать привычно, чем непонятно как. И тут я пожалуй с ним соглашусь.


Чем непонятно как — конечно лучше.
А лучше привычно, чем лучше — это уже спорно. Потому что субъективно. Кто-то привычку поставит на первое место. Вообще есть какая-то первая реакция отторжения всего нового, непривычного, правда?

ВВ>А ты, кстати, свое мнение по поводу скобочек не высказал


Дык мы ж это вроде подробно обсудили в твоём первом треде про Ela. Я за минимализм.
Если про грамматику, то я бы скорее склонился к тому, что блоки должны быть явно выделены (то есть if cond { block }), но без лишних (а они все, как известно, лишние ) скобок. Одним словом, лучше чем layout (блоки через отступы) я не видел. Но (!) только потому что layout это, в каком-то ограниченном подмножестве, AST-редактор для бедных.

T>><фантазия>

T>>А ещё было бы круто иметь редактор, который просто не даёт писать грамматически/стиллистически неверный код. Не потому что он исправляет текст, а потому что он пишет код, то есть AST. Нужен AST редактор, вместо текстового. Тогда вопрос стиля отпадает сам собой, потому что стиль становится просто форматом сериализации аста на диск, то есть невидим для разработчиков и комилятора.
T>></фантазия>

ВВ>На выбенете не писал?


Не понял о чём речь. Скорее всего нет.
Re[9]: Про скобочки
От: Воронков Василий Россия  
Дата: 28.04.10 20:44
Оценка:
Здравствуйте, Temoto, Вы писали:

ВВ>>Вопрос, если хочешь, — а можно ли сократить количество не скобочек даже, а их семантических значений в языке, не слишком навредив этим привычкам программистов?

T>Не навредив привычкам это не ко мне вопрос у меня всегда с такими вещами плохо было. Я не вижу ничего плохого в том, чтобы переучиться для использования нового инструмента *если это оправдано*.

Я вообще тоже, как, собственно, и к изучению нового синтаксиса. Изучение синтаксиса в общем случае — задача от получаса до часа. И чего все из этого такой шум делают?
А привычка штука такая — если ее один раз сломать, то потом уже ломать ничего не придется.

T>Мы про фигурные скобки ведь? У них семантическое значение — границы блоков. Единственный способ, что я вижу чтоб убрать их, так это убрать понятие блоков. В эрланге, например, это сделано с помощью одного, завершающего блок символа '.' (ещё иногда ';', это не суть важно сейчас). По сути, там только закрывающая фигурная скобка.


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

ВВ>>Вот Влад к примеру высказал тут вполне простую позицию. Лучше сделать привычно, чем непонятно как. И тут я пожалуй с ним соглашусь.


T>Чем непонятно как — конечно лучше.

T>А лучше привычно, чем лучше — это уже спорно. Потому что субъективно. Кто-то привычку поставит на первое место. Вообще есть какая-то первая реакция отторжения всего нового, непривычного, правда?

Осталось только понять — "лучше" это как?

ВВ>>А ты, кстати, свое мнение по поводу скобочек не высказал

T>Дык мы ж это вроде подробно обсудили в твоём первом треде про Ela. Я за минимализм.

А что есть минимализм в данном случае? С точки зрения синтаксиса минимализм — это скобочки. Конструкция вида:

for (x in y) expr

"минимальнее" чем

for x in y do expr

Вторая у нас еще и дополнительное ключевое слово вводит. Аналогично и с if () или if ... then.

T>Если про грамматику, то я бы скорее склонился к тому, что блоки должны быть явно выделены (то есть if cond { block }), но без лишних (а они все, как известно, лишние ) скобок. Одним словом, лучше чем layout (блоки через отступы) я не видел. Но (!) только потому что layout это, в каком-то ограниченном подмножестве, AST-редактор для бедных.


Т.е. ты за то, как это сделано в Гоу?
Кстати, по-моему код вида:

if x then {
expr
}

выглядит и правда как-то не очень, смешивает напитки, что ли.

ВВ>>На выбенете не писал?

T>Не понял о чём речь. Скорее всего нет.

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

И ты знаешь, на практике оно как-то не очень нравится.
Re[10]: Про скобочки
От: Temoto  
Дата: 28.04.10 21:21
Оценка:
T>>Мы про фигурные скобки ведь? У них семантическое значение — границы блоков. Единственный способ, что я вижу чтоб убрать их, так это убрать понятие блоков. В эрланге, например, это сделано с помощью одного, завершающего блок символа '.' (ещё иногда ';', это не суть важно сейчас). По сути, там только закрывающая фигурная скобка.

ВВ>Вообще про круглые


Тогда всё просто вобще. Круглые можно просто убрать и всё нормально. Есть не один язык, где вокруг условного выражения в if нет круглых скобок и это не минус. В руби даже круглые скобки для вызова функции писать не надо и тоже нормально. То есть ответ на твой вопрос будет такой: круглые скобки можно просто убрать, язык не пострадает, потому что они (скобки) изначально были мусором, семантической нагрузки не несли.

Единственно, что из-за такой фигни в руби нельзя передать функцию в качестве аргумента куда-то. Лямбду можно, а чей-то метод нет. Но это комплексная беда двух факторов: call by value и энергичных вычислений.

ВВ>Но про фигурные тоже можно

ВВ>А с лексическими блоками я не понимаю, зачем их убирать. Хуже ведь будет. Эрланг не смотрел, там лексический скоп?

Вроде лексический, да. Но речь не о скопе, не о том как переменные замыкаются. Речь о том, что там вместо двух скобок вокруг блока есть одна скобка в конце.

ВВ>>>Вот Влад к примеру высказал тут вполне простую позицию. Лучше сделать привычно, чем непонятно как. И тут я пожалуй с ним соглашусь.


T>>Чем непонятно как — конечно лучше.

T>>А лучше привычно, чем лучше — это уже спорно. Потому что субъективно. Кто-то привычку поставит на первое место. Вообще есть какая-то первая реакция отторжения всего нового, непривычного, правда?

ВВ>Осталось только понять — "лучше" это как?


Я ж говорю — субъектвино. Вот я за минимализм до предела. Но семейство APL уже за пределом А кому-то привычно это "лучше". А кому-то "лучше" это невыразимая выразительность, тут лисп непобедим. Если б AST-редактор (который избавит лисп от скобок), то это будет ещё и самый минималистический синтаксис.

ВВ>>>А ты, кстати, свое мнение по поводу скобочек не высказал

T>>Дык мы ж это вроде подробно обсудили в твоём первом треде про Ela. Я за минимализм.

ВВ>А что есть минимализм в данном случае? С точки зрения синтаксиса минимализм — это скобочки. Конструкция вида:


ВВ>for (x in y) expr


ВВ>"минимальнее" чем


ВВ>for x in y do expr


ВВ>Вторая у нас еще и дополнительное ключевое слово вводит. Аналогично и с if () или if ... then.


Из двух предложенных вариантов — да, скобки меньше символов занимают. А более общее утверждение "с точки зрения синтаксиса минимализм — это скобочки" неверно, потому что существуют другие варианты. В двух словах: "ну так не вводите ключевое слово, блин".

Например:

for x in y: print x

a < b | print a
else | print b

T>>Если про грамматику, то я бы скорее склонился к тому, что блоки должны быть явно выделены (то есть if cond { block }), но без лишних (а они все, как известно, лишние ) скобок. Одним словом, лучше чем layout (блоки через отступы) я не видел. Но (!) только потому что layout это, в каком-то ограниченном подмножестве, AST-редактор для бедных.


ВВ>Т.е. ты за то, как это сделано в Гоу?

ВВ>Кстати, по-моему код вида:

ВВ>if x then {

ВВ> expr
ВВ>}

ВВ>выглядит и правда как-то не очень, смешивает напитки, что ли.


Согласен в том, что выглядит непривычно. Но, повторюсь, синтаксис Go специально заточен для скорости парсинга и компиляции. Это объясняет любое смешение напитков.

Layout в питоне, руби, хаскеле и немерле с каким-то импортом. Блоки через отступы, я же говорю.
if cond
expr

Но про явное выделение блоков — да, как в Go. Блок даже из одного предложения — всё равно явно выделен. Просто в Go он выделяется фигурными скобками и мне это не очень нравится.

ВВ>VB.NET, он же выбенет, он же васик и басик.

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

ВВ>И ты знаешь, на практике оно как-то не очень нравится.


Аа.. да-да, VB.NET не видел, видел VB6, VBA. Да, там есть некоторое навязывание формата. Регистр кейвордов и идентификаторов, например. И да, выглядит непривлекательно. Ну это такая идея, которую сложно сделать правильно. И я не уверен, что у создателей выбенета была именно такая идея. Может быть они просто похожи.
Re[11]: Про скобочки
От: Воронков Василий Россия  
Дата: 28.04.10 22:00
Оценка:
Здравствуйте, Temoto, Вы писали:

T>Тогда всё просто вобще. Круглые можно просто убрать и всё нормально. Есть не один язык, где вокруг условного выражения в if нет круглых скобок и это не минус. В руби даже круглые скобки для вызова функции писать не надо и тоже нормально. То есть ответ на твой вопрос будет такой: круглые скобки можно просто убрать, язык не пострадает, потому что они (скобки) изначально были мусором, семантической нагрузки не несли.


Просто ли? Как правило их нельзя "просто" убрать, нужно заменить чем-то. Это может быть ключевое слово, скобки другого вида, какие-нибудь новые знаки препинания. Например, в питоновском варианте:


if x :
  expr
else :
  expr



второе двоеточение после else нужно исключительно для "симметрии". По идее — оно тоже синтаксический мусор.
Т.е. в принципе, чем этот вариант лучше, чем:


if (x)
  expr
else
  expr



количеств символов — точно такое же. В плане "логичности" даже хуже.

T>Единственно, что из-за такой фигни в руби нельзя передать функцию в качестве аргумента куда-то. Лямбду можно, а чей-то метод нет. Но это комплексная беда двух факторов: call by value и энергичных вычислений.


Ну это называется — вместе с водой выплеснуть и ребенка. Нет никаких проблем с первоклассными функциями и энергичными вычислениями, просто последние требуют *явный* синтаксис вызова функций. Сие есть данность, а делать как в Руби — очевидно, не вариант.
Особенно учитывая, что Ela уверенно идет в сторону именно функциональщины.

Так что скобочки при вызове функции нужны, как ни крути. Плюс у меня еще на уровне AST параметры функции описываются как кортеж и в самом языке их сейчас можно рассматривать в виде кортежа. Например:

let func(x, y) = | 2, 1 -> ... | 3, 2 -> ...


А поэтому скобки вполне логичны, учитывая, что синтаксис создания кортежа — это (x, y).

ВВ>>Но про фигурные тоже можно

ВВ>>А с лексическими блоками я не понимаю, зачем их убирать. Хуже ведь будет. Эрланг не смотрел, там лексический скоп?
T>Вроде лексический, да. Но речь не о скопе, не о том как переменные замыкаются. Речь о том, что там вместо двух скобок вокруг блока есть одна скобка в конце.

А как тогда объявить вложенный блок?

T>Я ж говорю — субъектвино. Вот я за минимализм до предела. Но семейство APL уже за пределом А кому-то привычно это "лучше". А кому-то "лучше" это невыразимая выразительность, тут лисп непобедим. Если б AST-редактор (который избавит лисп от скобок), то это будет ещё и самый минималистический синтаксис.


Ну а где предел-то? Например, уже и так есть тернарный оператор ?: При желании его можно использовать как стейтмент.
Например, такая программа вполне валидна:

2 + 2 == 4 ?
  cout "Hey, this is bug!" :
  cout "Test passed"


Вот тебе синтаксис в котором ничего лишнего.
Нравится?

T>a < b | print a

T> else | print b

Странный пример. if убрал, else оставил.
Выглядит странно. | это вообще бинарный оператор. Да и в принципе такие символы в дефиците, для операторов нужны.

ВВ>>if x then {

ВВ>> expr
ВВ>>}
ВВ>>выглядит и правда как-то не очень, смешивает напитки, что ли.
T>Согласен в том, что выглядит непривычно. Но, повторюсь, синтаксис Go специально заточен для скорости парсинга и компиляции. Это объясняет любое смешение напитков.

Ну то что я привел это не синтаксис Гоу. Если фигурные скобочки обязательны, то then не нужен.
Пример выше — это то, что получится, если скобочки убрать в одном месте, а в другом оставить — причем опциональные.

T>Layout в питоне, руби, хаскеле и немерле с каким-то импортом. Блоки через отступы, я же говорю.

T>if cond
T> expr

Эту фразу я не понял. Что значит "с каким-то импортом"?
Блоки через идентацию на мой взгляд решают часть проблем блоков через скобочки, но и свои вносят. Т.е. никак не могу я разглядеть в них лучшей альтернативы скобочкам. Равнозначную — еще может быть.
Плюс все равно нужен какой-то дополнительный механизм, чтобы разрешить выражения записывать "в строчку". Т.е. блоки через отступы несамодостаточны, в отличие от блоков через скобочки.

Мне был интересен простой момент — можно ли, взяв Си-подобный синтаксис, убрать из ряда продукций круглые скобочки, сохранив все остальное, и получить при этом что-то достаточно стройное и более удобное.
Судя по общей реакции складывается впечатление, что такой "гибридный" вариант явно не в фаворе. Т.е. можно попросту сделать другой синтаксис. Принципиально. Это-то я понимаю.

T>Аа.. да-да, VB.NET не видел, видел VB6, VBA. Да, там есть некоторое навязывание формата. Регистр кейвордов и идентификаторов, например. И да, выглядит непривлекательно. Ну это такая идея, которую сложно сделать правильно. И я не уверен, что у создателей выбенета была именно такая идея. Может быть они просто похожи.


Я не помню уже как было в VB6. Но в выбенете ты попросту не можешь отойти от стандартного форматирования. Идея, видимо, была в том, что человек не форматировал код, а писал его. Тебе редактор тупо не дает, например, отступ лишний сделать.
Я писал на VB.NET, меня такое поведение попросту раздражало. Все же, мне кажется, текст программы это все-таки текст. Его создание процесс все же довольно творческий. Правила — хорошо, но иногда имеет смысл и отойти от правил, если в данном конкретном случае так будет лучше. Излишне механизировать процесс я думаю не стоит. По крайней мере мы, наше поколение, еще не доросло до этого.
Re[12]: Про скобочки
От: Temoto  
Дата: 28.04.10 22:41
Оценка:
T>>Тогда всё просто вобще. Круглые можно просто убрать и всё нормально. Есть не один язык, где вокруг условного выражения в if нет круглых скобок и это не минус. В руби даже круглые скобки для вызова функции писать не надо и тоже нормально. То есть ответ на твой вопрос будет такой: круглые скобки можно просто убрать, язык не пострадает, потому что они (скобки) изначально были мусором, семантической нагрузки не несли.

ВВ>Просто ли? Как правило их нельзя "просто" убрать, нужно заменить чем-то. Это может быть ключевое слово, скобки другого вида, какие-нибудь новые знаки препинания. Например, в питоновском варианте:



ВВ>
ВВ>if x :
ВВ>  expr
ВВ>else :
ВВ>  expr
ВВ>



ВВ>второе двоеточение после else нужно исключительно для "симметрии". По идее — оно тоже синтаксический мусор.


И первое. В руби нет.

T>>Единственно, что из-за такой фигни в руби нельзя передать функцию в качестве аргумента куда-то. Лямбду можно, а чей-то метод нет. Но это комплексная беда двух факторов: call by value и энергичных вычислений.


ВВ>Ну это называется — вместе с водой выплеснуть и ребенка. Нет никаких проблем с первоклассными функциями и энергичными вычислениями, просто последние требуют *явный* синтаксис вызова функций. Сие есть данность, а делать как в Руби — очевидно, не вариант.

ВВ>Особенно учитывая, что Ela уверенно идет в сторону именно функциональщины.

ВВ>Так что скобочки при вызове функции нужны, как ни крути. Плюс у меня еще на уровне AST параметры функции описываются как кортеж и в самом языке их сейчас можно рассматривать в виде кортежа. Например:


ВВ>
ВВ>let func(x, y) = | 2, 1 -> ... | 3, 2 -> ...
ВВ>


ВВ>А поэтому скобки вполне логичны, учитывая, что синтаксис создания кортежа — это (x, y).


Если приплетать сюда кортеж *с конструктором: скобки*, то в каком-то смысле синтаксис вызова функции становаится "name" args, именно без скобок.

ВВ>>>Но про фигурные тоже можно

ВВ>>>А с лексическими блоками я не понимаю, зачем их убирать. Хуже ведь будет. Эрланг не смотрел, там лексический скоп?
T>>Вроде лексический, да. Но речь не о скопе, не о том как переменные замыкаются. Речь о том, что там вместо двух скобок вокруг блока есть одна скобка в конце.

ВВ>А как тогда объявить вложенный блок?


На ровном месте, как в си?

{ do1;
{ do2; do3; }
do4;
}

Такого, наверное, нет. А блоки со смыслом всегда имеют какой-то контекст: if/case/fun. Т.е. где-то заканчивается предыдущий грамматический терм и начинается блок.

T>>Я ж говорю — субъектвино. Вот я за минимализм до предела. Но семейство APL уже за пределом А кому-то привычно это "лучше". А кому-то "лучше" это невыразимая выразительность, тут лисп непобедим. Если б AST-редактор (который избавит лисп от скобок), то это будет ещё и самый минималистический синтаксис.


ВВ>Ну а где предел-то? Например, уже и так есть тернарный оператор ?: При желании его можно использовать как стейтмент.

ВВ>Например, такая программа вполне валидна:

ВВ>
ВВ>2 + 2 == 4 ?
ВВ>  cout "Hey, this is bug!" :
ВВ>  cout "Test passed"
ВВ>


ВВ>Вот тебе синтаксис в котором ничего лишнего.

ВВ>Нравится?

Ну кроме того, что он плохо читается да, ничо так, нормальный синтаксис. В качестве тренарного оператора условия мне больше нравится
expr1 "if" cond "else" expr2
, но это, наверное, дело вкуса.

T>>a < b | print a

T>> else | print b

ВВ>Странный пример. if убрал, else оставил.

ВВ>Выглядит странно. | это вообще бинарный оператор. Да и в принципе такие символы в дефиците, для операторов нужны.

| это бинарный оператор в некоторых языках. Пример странный, согласен. я над ним не долго думал
Тут дело не в if/else, а в том, что скобки гармонично убраны. (на мой взгляд)

ВВ>>>if x then {

ВВ>>> expr
ВВ>>>}
ВВ>>>выглядит и правда как-то не очень, смешивает напитки, что ли.
T>>Согласен в том, что выглядит непривычно. Но, повторюсь, синтаксис Go специально заточен для скорости парсинга и компиляции. Это объясняет любое смешение напитков.

ВВ>Ну то что я привел это не синтаксис Гоу. Если фигурные скобочки обязательны, то then не нужен.

ВВ>Пример выше — это то, что получится, если скобочки убрать в одном месте, а в другом оставить — причем опциональные.

T>>Layout в питоне, руби, хаскеле и немерле с каким-то импортом. Блоки через отступы, я же говорю.

T>>if cond
T>> expr

ВВ>Эту фразу я не понял. Что значит "с каким-то импортом"?


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

ВВ>Блоки через идентацию на мой взгляд решают часть проблем блоков через скобочки, но и свои вносят. Т.е. никак не могу я разглядеть в них лучшей альтернативы скобочкам. Равнозначную — еще может быть.

ВВ>Плюс все равно нужен какой-то дополнительный механизм, чтобы разрешить выражения записывать "в строчку". Т.е. блоки через отступы несамодостаточны, в отличие от блоков через скобочки.

Это да.

ВВ>Мне был интересен простой момент — можно ли, взяв Си-подобный синтаксис, убрать из ряда продукций круглые скобочки, сохранив все остальное, и получить при этом что-то достаточно стройное и более удобное.

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

Ну хакей, проехали с отступами. Убираем открывающую скобку, закрывающую скобку меняем на двоеточие, получаем что-то *достаточно* стройное и удобное.

Ты просто спросил, мол, а какое у меня мнение, моё мнение что всё остальное сохранять не надо.

T>>Аа.. да-да, VB.NET не видел, видел VB6, VBA. Да, там есть некоторое навязывание формата. Регистр кейвордов и идентификаторов, например. И да, выглядит непривлекательно. Ну это такая идея, которую сложно сделать правильно. И я не уверен, что у создателей выбенета была именно такая идея. Может быть они просто похожи.


ВВ>Я не помню уже как было в VB6. Но в выбенете ты попросту не можешь отойти от стандартного форматирования. Идея, видимо, была в том, что человек не форматировал код, а писал его. Тебе редактор тупо не дает, например, отступ лишний сделать.

ВВ>Я писал на VB.NET, меня такое поведение попросту раздражало. Все же, мне кажется, текст программы это все-таки текст. Его создание процесс все же довольно творческий. Правила — хорошо, но иногда имеет смысл и отойти от правил, если в данном конкретном случае так будет лучше. Излишне механизировать процесс я думаю не стоит. По крайней мере мы, наше поколение, еще не доросло до этого.

Может быть. А может реализация у них не самая удачная.
Re[13]: Про скобочки
От: Воронков Василий Россия  
Дата: 28.04.10 23:24
Оценка:
Здравствуйте, Temoto, Вы писали:

T>И первое. В руби нет.


Ну это уже более глубинный вопрос, так сказать. В языке, где можно записать две продукции Expr Expr (т.е. просто разделенные пробелом), и это не вызовет никаких конфликтов в грамматике, не нужны ни скобочки, ни точки с запятой. В Си-подобном синтаксисе это не так (а знаешь, почему? потому что он достаточно лаконичен на самом-то деле). Да и в большинстве синтаксисов это не так.

Банальный пример:

x
-x //здесь два выражения, или x - x?


Чуть менее банальный:

x
(x, y) //здесь создается кортеж или вызывается функция x?


Или

x
[y] //здесь создается список или это индексер?


Скажешь, синтаксис виноват? Возможно. Но есть единственный способ с этим бороться — вводить много *разных* синтаксических конструкций. Например, список создается через [], а обращение по индексу через !!. Функция вызывается через .() или кортеж создается через (| ) и так далее. А все унарные операторы писать в постфиксной нотации. Стоп. А у нас и так есть префиксные и постфиксные операторы? Ну тогда завернем их в скобки, делов-то
Казалось бы, в одном случае "пару скобочек" убрали, зато во всех остальных — нафигачили кучу других "знаков препинаний".

Так вот смотришь, и вроде уж с Сишного синтаксиса пыль пора сдувать, а не так уж он и плох

T>Если приплетать сюда кортеж *с конструктором: скобки*, то в каком-то смысле синтаксис вызова функции становаится "name" args, именно без скобок.


Ну да, можно и так сказать. Все правильно в общем. Т.е. явный вызов означает явную передачу параметров, все просто до слез. Причем любая функция всегда принимает хоть один параметр. Скажешь есть функции без параметров? А нету их. Есть вот такие:

func()

а () — это литерал для void. Т.е. даже такой код вполне валиден — let v = ()
Так что все вполне логично. Хочешь вызвать функцию — надо хоть что-то в нее передать.

Да и скобочки вокруг кортежей мне тоже нравятся. Неслучайно вот в последней редакции Ocaml их сделали обязательными.

А в "чистом" ФЯ функция (предполагается, что она должна быть детерминирована, конечно) без параметров, кстати, вообще равносильна значению, возвращаемому из этой функции. Т.е. проблемы такой вообще нет — передать функцию или вызвать функцию и передать значение, которое она вернула. Ибо для xxx -> unit это одно и то же.

Так что в принципе все и без ленивости решается, с самой что ни на есть strict evaluation.

ВВ>>>>Но про фигурные тоже можно

ВВ>>>>А с лексическими блоками я не понимаю, зачем их убирать. Хуже ведь будет. Эрланг не смотрел, там лексический скоп?
T>>>Вроде лексический, да. Но речь не о скопе, не о том как переменные замыкаются. Речь о том, что там вместо двух скобок вокруг блока есть одна скобка в конце.

ВВ>>А как тогда объявить вложенный блок?


T>На ровном месте, как в си?


T>{ do1;

T> { do2; do3; }
T> do4;
T>}

T>Такого, наверное, нет. А блоки со смыслом всегда имеют какой-то контекст: if/case/fun. Т.е. где-то заканчивается предыдущий грамматический терм и начинается блок.


Фишка "блока на ровном месте" в целом в том, что в языке по сути существует (ну если, слегка утрировать) один-единственный способ объявления блока. Т.е. грамматика if выглядит на самом деле как:

"if" "(" Expr ")" Expr

где Expr := ... | Block

А это тоже своего рода лаконичность.
Если от этого отказаться, что синтаксис начнет неизбежно распухать. Т.е. те самые конструкции "с контекстом" всегда будут требовать некоего явно блока, с явным же завершением.

T>Ну кроме того, что он плохо читается да, ничо так, нормальный синтаксис. В качестве тренарного оператора условия мне больше нравится

T>expr1 "if" cond "else" expr2
T>, но это, наверное, дело вкуса.

Ну вот, плохо читается. А почему? Слишком "подсократили" синтаксис? Ты же любишь говорить, что тебе нравятся синтаксисы "легкие", на грани вымирания. Вот тернарный оператор просто образец легкости.

ВВ>>Странный пример. if убрал, else оставил.

ВВ>>Выглядит странно. | это вообще бинарный оператор. Да и в принципе такие символы в дефиците, для операторов нужны.
T>| это бинарный оператор в некоторых языках. Пример странный, согласен. я над ним не долго думал
T>Тут дело не в if/else, а в том, что скобки гармонично убраны. (на мой взгляд)

Не вижу я тут гармонии. Вместо скобок добавлены черточки. Причем добавлены так, что их уже в качестве оператора не поюзаешь — а черточки ресурс весьма ценный Причем все же бросается в глаза тот факт, что в else | — черточка ну абсолютно лишняя. При таком подходе становится непонятно, чем же были плохи скобочки-то?

В изначальном варианте, что мне лично нравилось-то... Напомню:

for x in y do
  expr


Это синтаксис OCaml.
Скобочки плохи тем, что внутри скобочек могут быть другие скобочки и так далее. Получается, каша. Здесь уже у тебя четко выделены части выражения и, в отличие от черточки, редактор их подкрашивает, сразу видно, что где кончается и пр. В отличие от скобочек, когда зачастую хрен разберешь, какая где, и что там эта скобочка замыкает — только match braces спасает.

ВВ>>Эту фразу я не понял. Что значит "с каким-то импортом"?

T>Ну тут Влад писал, что в немерле можно что-то там заимпортить типа Nemerle.Indent и блоки будут выделяться отступами.

Ну там прагма есть специальная, как и в F# (#light), задает специальный режим синтаксиса. #ident вроде, не помню.

T>Ну хакей, проехали с отступами. Убираем открывающую скобку, закрывающую скобку меняем на двоеточие, получаем что-то *достаточно* стройное и удобное.


А если так:

if x :
  expr
else //двоеточия нет
  exp 

if x : {
  expr;
  expr
}
else
  expr


T>Ты просто спросил, мол, а какое у меня мнение, моё мнение что всё остальное сохранять не надо.


А что тогда вместо:
— для блоков (ну отступы, да?)
— для вызова функций
— для литералов кортежей
— для литералов списков
— для литералов массивов
— для литералов объектов
— для литералов функций
— для разделения выражений (вместо ; )
— для группировки выражений

T>Может быть. А может реализация у них не самая удачная.


Ну я другой не видел
Re[11]: Про скобочки
От: March_rabbit  
Дата: 29.04.10 10:45
Оценка:
Здравствуйте, VladD2, Вы писали:

M_>> Не приходилось у себя чинить то, что на деле являлось последствием ошибки в чужом модуле?


VD>Нет. Но приходилось откатывать кривые изменения других людей. Првада не часто. Раза три за всю жизнь.

везет.

M_>> Ошибка есть, но стреляет так, что последствия всплывают в совсем другом коде. Бывало такое.....

VD>И причем тут скобки? Не уж то от них такой эффект?
Это "еще одна возможность сделать ошибку". Которую легко заткнуть. Тем более непонятно, зачем ждать?
Re[10]: Про скобочки
От: March_rabbit  
Дата: 29.04.10 10:46
Оценка:
Здравствуйте, VladD2, Вы писали:

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


ВВ>>Тоже, кстати, поинт хороший. Им стоило бы вообще запретить табы, как это сделали в F# #light.


VD>Зачем запрещать? Достаточно не допускать их смеси в одном фале.

не всякий редактор покажет, что стоит имеено здесь — пробел или таб
Re[9]: Про скобочки
От: March_rabbit  
Дата: 29.04.10 10:48
Оценка:
Здравствуйте, Temoto, Вы писали:

ВВ>>>А там можно получить неправильную программу просто вставив лишний пробел


FR>>Пробел фигня, вот неправильный таб вообще может до смертоубийства довести


T>В чём разница?

разница в том, что разные редакторы ставят разное количество пробелов вместо таба. То есть, глазами смотришь — строки на одном уровне, запускаешь — код ведет себя черти как. Залез в коды — вот оно: таб и пробелы. Уж сколько раз такое было......
Re[14]: Про скобочки
От: Temoto  
Дата: 29.04.10 10:50
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


T>>И первое. В руби нет.


ВВ>Ну это уже более глубинный вопрос, так сказать. В языке, где можно записать две продукции Expr Expr (т.е. просто разделенные пробелом), и это не вызовет никаких конфликтов в грамматике, не нужны ни скобочки, ни точки с запятой. В Си-подобном синтаксисе это не так (а знаешь, почему? потому что он достаточно лаконичен на самом-то деле). Да и в большинстве синтаксисов это не так.


ВВ>Банальный пример:


ВВ>
ВВ>x
ВВ>-x //здесь два выражения, или x - x?
ВВ>


ВВ>Скажешь, синтаксис виноват? Возможно. Но есть единственный способ с этим бороться — вводить много *разных* синтаксических конструкций. Например, список создается через [], а обращение по индексу через !!. Функция вызывается через .() или кортеж создается через (| ) и так далее. А все унарные операторы писать в постфиксной нотации. Стоп. А у нас и так есть префиксные и постфиксные операторы? Ну тогда завернем их в скобки, делов-то

ВВ>Казалось бы, в одном случае "пару скобочек" убрали, зато во всех остальных — нафигачили кучу других "знаков препинаний".

ВВ>Так вот смотришь, и вроде уж с Сишного синтаксиса пыль пора сдувать, а не так уж он и плох


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

x — x это отдельный случай, кстати.

ВВ>А в "чистом" ФЯ функция (предполагается, что она должна быть детерминирована, конечно) без параметров, кстати, вообще равносильна значению, возвращаемому из этой функции. Т.е. проблемы такой вообще нет — передать функцию или вызвать функцию и передать значение, которое она вернула. Ибо для xxx -> unit это одно и то же.


ВВ>Так что в принципе все и без ленивости решается, с самой что ни на есть strict evaluation.


Хакей

ВВ>Фишка "блока на ровном месте" в целом в том, что в языке по сути существует (ну если, слегка утрировать) один-единственный способ объявления блока. Т.е. грамматика if выглядит на самом деле как:


ВВ>"if" "(" Expr ")" Expr


ВВ>где Expr := ... | Block


ВВ>А это тоже своего рода лаконичность.

ВВ>Если от этого отказаться, что синтаксис начнет неизбежно распухать. Т.е. те самые конструкции "с контекстом" всегда будут требовать некоего явно блока, с явным же завершением.

Я это всё понимаю тоже

T>>Ну кроме того, что он плохо читается да, ничо так, нормальный синтаксис. В качестве тренарного оператора условия мне больше нравится

T>>expr1 "if" cond "else" expr2
T>>, но это, наверное, дело вкуса.

ВВ>Ну вот, плохо читается. А почему? Слишком "подсократили" синтаксис? Ты же любишь говорить, что тебе нравятся синтаксисы "легкие", на грани вымирания. Вот тернарный оператор просто образец легкости.


Образец, да. Ну, видимо, он для меня эту грань перешёл.

ВВ>>>Странный пример. if убрал, else оставил.

ВВ>>>Выглядит странно. | это вообще бинарный оператор. Да и в принципе такие символы в дефиците, для операторов нужны.
T>>| это бинарный оператор в некоторых языках. Пример странный, согласен. я над ним не долго думал
T>>Тут дело не в if/else, а в том, что скобки гармонично убраны. (на мой взгляд)

ВВ>Не вижу я тут гармонии. Вместо скобок добавлены черточки. Причем добавлены так, что их уже в качестве оператора не поюзаешь — а черточки ресурс весьма ценный Причем все же бросается в глаза тот факт, что в else | — черточка ну абсолютно лишняя. При таком подходе становится непонятно, чем же были плохи скобочки-то?


Ну убери else. Скобки плохи тем, что имеют много смыслов. Это и оператор вызова функции, и группировка выражений, и в if/while/for специальный смысл имеют.

ВВ>В изначальном варианте, что мне лично нравилось-то... Напомню:


ВВ>
ВВ>for x in y do
ВВ>  expr
ВВ>


ВВ>Это синтаксис OCaml.

ВВ>Скобочки плохи тем, что внутри скобочек могут быть другие скобочки и так далее. Получается, каша. Здесь уже у тебя четко выделены части выражения и, в отличие от черточки, редактор их подкрашивает, сразу видно, что где кончается и пр. В отличие от скобочек, когда зачастую хрен разберешь, какая где, и что там эта скобочка замыкает — только match braces спасает.

Ну и неплохо вроде. Берёшь этот вариант?

T>>Ну хакей, проехали с отступами. Убираем открывающую скобку, закрывающую скобку меняем на двоеточие, получаем что-то *достаточно* стройное и удобное.


ВВ>А если так:


ВВ>
ВВ>if x :
ВВ>  expr
ВВ>else //двоеточия нет
ВВ>  exp 

ВВ>if x : {
ВВ>  expr;
ВВ>  expr
ВВ>}
ВВ>else
ВВ>  expr
ВВ>


if x {
stmt;
stmt;
} else {
stmt
}

T>>Ты просто спросил, мол, а какое у меня мнение, моё мнение что всё остальное сохранять не надо.


ВВ>А что тогда вместо:

ВВ>- для блоков (ну отступы, да?)

Отступы, да.

ВВ>- для вызова функций


Ничего. Пустой оператор. f x

ВВ>- для литералов кортежей


a, b

ВВ>- для литералов списков


list a, b

ВВ>- для литералов массивов


array a, b

ВВ>- для литералов объектов


{name: value, name: value}
или {name = value} тоже ничо.

ВВ>- для литералов функций


Это мы, вроде, подробно обсудили в прошлый раз.

ВВ>- для разделения выражений (вместо ; )


\n

ВВ>- для группировки выражений


Старые круглые добрые скобки.
Re[10]: Про скобочки
От: Temoto  
Дата: 29.04.10 10:52
Оценка:
ВВ>>>>А там можно получить неправильную программу просто вставив лишний пробел

FR>>>Пробел фигня, вот неправильный таб вообще может до смертоубийства довести


T>>В чём разница?

M_>разница в том, что разные редакторы ставят разное количество пробелов вместо таба. То есть, глазами смотришь — строки на одном уровне, запускаешь — код ведет себя черти как. Залез в коды — вот оно: таб и пробелы. Уж сколько раз такое было......

Ну так настройте редактор.

А то можно ещё не пользоваться потоками, потому что в Windows 3 они кооперативные. Смотришь, вроде все должны работать, залез в коды — вот он! кто-то забыл переключить контекст.
Re[15]: Про скобочки
От: Воронков Василий Россия  
Дата: 29.04.10 11:48
Оценка:
Здравствуйте, Temoto, Вы писали:

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


Разделение новой строкой это очень радикальное решение на самом деле. В вышеприведенных примерах конфликта тогда не будет попросту потому что выражения нельзя будет записывать на несколько строк. И получаем весь букет неудобств того же бейсика.

Причем скобочки (или их заменитель) как ни странно все равно будут нужны. Ибо не заставлять же людей всегда писать if/else на несколько строк.

T>x — x это отдельный случай, кстати.


Почему?

ВВ>>А это тоже своего рода лаконичность.

ВВ>>Если от этого отказаться, что синтаксис начнет неизбежно распухать. Т.е. те самые конструкции "с контекстом" всегда будут требовать некоего явно блока, с явным же завершением.
T>Я это всё понимаю тоже

Ну вот с учетом того, что все в языке есть expression, *обязательность* блока мне кажется не очень уместной. Тяжеловато будет выглядеть код, где с правой стороны от "=" тебе *придется* объявлять несколько блоков.

T>Ну убери else. Скобки плохи тем, что имеют много смыслов. Это и оператор вызова функции, и группировка выражений, и в if/while/for специальный смысл имеют.


Именно в этом и есть главная претензия к скобкам. ОК, убираем else:

if bar(arg) || foo(arg2, x::xs) : fooBar(x, arg::arg2) : barFoo(xs, arg2::arg)


Чет не очень. А тебе?

ВВ>>
ВВ>>for x in y do
ВВ>>  expr
ВВ>>

ВВ>>Это синтаксис OCaml.
T>Ну и неплохо вроде. Берёшь этот вариант?

Думаю. Для for выглядит неплохо. Для if — уже хуже. Плюс с фигурно-скобочностью все же сочетается не очень.

T>if x {

T> stmt;
T> stmt;
T>} else {
T> stmt
T>}

Не понял, т.е. {} обязательные? Или разделитель — это \n? А как мне в строчку if записать? (Не забываем, что if — это экспрешин).

T>>>Ты просто спросил, мол, а какое у меня мнение, моё мнение что всё остальное сохранять не надо.


ВВ>>- для вызова функций

T>Ничего. Пустой оператор. f x

Для вызова функции типа x -> void все равно потребуются скобочки — или какой другой (какой, кстати?) литерал для void.

ВВ>>- для литералов кортежей

T>a, b
ВВ>>- для литералов списков
T>list a, b
ВВ>>- для литералов массивов
T>array a, b

А запятая зачем?
Убери — и получится Лисп. При этом лаконичным такой синтаксис не назовешь. К тому же:

(array a, b).length

вместо

array[a, b].length

ВВ>>- для литералов объектов

T>{name: value, name: value}
T>или {name = value} тоже ничо.

Сейчас у меня так: (name: value)

ВВ>>- для разделения выражений (вместо ; )

T>\n

И вводить какой-нибудь значок типа вбшного "_", чтобы выражения можно было переносить на разные строчки? Или как?
А как мне записать выражение вида:

var res = (if (cond) exp1 else exp2) + (if ...
Re[15]: Про скобочки
От: Воронков Василий Россия  
Дата: 29.04.10 12:05
Оценка:
Здравствуйте, Temoto, Вы писали:

ВВ>>А что тогда вместо:

[skipped]

Собственно, тут на вскидку сразу возникают такие вопросы:

1. Какой литерал для пустого списка? (Ты же понимаешь, что [0, 1, 2] это сахар для 0::1::2::[])
2. Как вызвать функцию, передав в нее в качестве параметра *результат* вызова другой функции?
3. Как записать кортеж, элементами которого являются другие кортежи? Или кортежи и списки, списки и массивы?
4. Тот же вопрос про список и массив.
и т.д.

Не говоря уж о том, что запись вида:

f x y, z, k j

Мне кажется мало вменяемой, честно говоря. Вот, повторюсь, не случайно, мне кажется, скобочки для кортежей в OCaml сделали обязательными.
Re[12]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.04.10 12:26
Оценка: +2 -1
Здравствуйте, March_rabbit, Вы писали:

VD>>И причем тут скобки? Не уж то от них такой эффект?

M_>Это "еще одна возможность сделать ошибку". Которую легко заткнуть. Тем более непонятно, зачем ждать?

Ошибку уровня опечатки можно сделать везде и всегда. От этого никто не застрахован. Скобки тут ничего нового не привносят.

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

Я уверен, что оно того не стоит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Про скобочки
От: Temoto  
Дата: 29.04.10 12:36
Оценка:
T>>Никто не виноват, просто стейтменты новой строкой разделить и будет однозначная трактовка всех твоих примеров.

ВВ>Разделение новой строкой это очень радикальное решение на самом деле. В вышеприведенных примерах конфликта тогда не будет попросту потому что выражения нельзя будет записывать на несколько строк. И получаем весь букет неудобств того же бейсика.


Ну прям и нельзя. В том же бейсике есть специальный символ для этого: '_'. Будучи оставленным на конце строки он клеит следущую с этой строкой так, что выражение не рвётся. В питоне для этого используется обратный слеш.

ВВ>Причем скобочки (или их заменитель) как ни странно все равно будут нужны. Ибо не заставлять же людей всегда писать if/else на несколько строк.


Можно заставлять. Это тоже одна из вещей, которая на первый взгляд выглядит дико, а через неделю совсем по-домашнему.

T>>x — x это отдельный случай, кстати.


ВВ>Почему?


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

Я бы делал синтаксис унарного минуса таким: "-x" это он, а "- x" это правая часть от "y — x". То есть пробел обязателен вокруг нормальных операторов и обязательно без пробела после унарного минуса. Тогда "x — x" не вызывает ни визуальной неоднозначности, ни грамматической.

(тут я схитрил) на самом деле визуальную неоднозначность убирает левый операнд. "print — x" уже однозначно понятен только парсеру.

ВВ>>>А это тоже своего рода лаконичность.

ВВ>>>Если от этого отказаться, что синтаксис начнет неизбежно распухать. Т.е. те самые конструкции "с контекстом" всегда будут требовать некоего явно блока, с явным же завершением.
T>>Я это всё понимаю тоже

ВВ>Ну вот с учетом того, что все в языке есть expression, *обязательность* блока мне кажется не очень уместной. Тяжеловато будет выглядеть код, где с правой стороны от "=" тебе *придется* объявлять несколько блоков.


Я что-то не проследил логику. Ты не мог бы подробнее объяснить?

T>>Ну убери else. Скобки плохи тем, что имеют много смыслов. Это и оператор вызова функции, и группировка выражений, и в if/while/for специальный смысл имеют.


ВВ>Именно в этом и есть главная претензия к скобкам. ОК, убираем else:


ВВ>
ВВ>if bar(arg) || foo(arg2, x::xs) : fooBar(x, arg::arg2) : barFoo(xs, arg2::arg)
ВВ>


ВВ>Чет не очень. А тебе?


Да, чёт не фонтан.
А если второй ':' будет другим символом?

if bar(arg) || foo(arg2, x::xs)
: fooBar(x, arg::arg2)
_ barFoo(xs, arg2::arg)

?

ВВ>Думаю. Для for выглядит неплохо. Для if — уже хуже. Плюс с фигурно-скобочностью все же сочетается не очень.


Да ты же сам говорил (и я тоже согласен), что всё это "сочетается-несочетается" — привыкаешь очень быстро.

T>>if x {

T>> stmt;
T>> stmt;
T>>} else {
T>> stmt
T>>}

ВВ>Не понял, т.е. {} обязательные? Или разделитель — это \n? А как мне в строчку if записать? (Не забываем, что if — это экспрешин).


Да, обязательные. Собсно именно это я и говорил с самого начала про фигурные скобки. словами "Блоки выделять обязательно." Разделитель, в данном случае — ';'. Можно записать в одну строчку.

T>>>>Ты просто спросил, мол, а какое у меня мнение, моё мнение что всё остальное сохранять не надо.


ВВ>>>- для вызова функций

T>>Ничего. Пустой оператор. f x

ВВ>Для вызова функции типа x -> void все равно потребуются скобочки — или какой другой (какой, кстати?) литерал для void.


Либо f будет означать вызов этой функции и не потребуются.

Что такое void, для чего нужен?

ВВ>>>- для литералов кортежей

T>>a, b
ВВ>>>- для литералов списков
T>>list a, b
ВВ>>>- для литералов массивов
T>>array a, b

ВВ>А запятая зачем?

ВВ>Убери — и получится Лисп. При этом лаконичным такой синтаксис не назовешь. К тому же:

Запятая — инфиксный конструктор кортежа. Без неё получится лисп, да.

ВВ>(array a, b).length


ВВ>вместо


ВВ>array[a, b].length


Просто 2 вместо array[a, b].length ещё короче.
(я хочу сказать, что да, (array a, b).length это некрасиво, но не потому что синтаксис плох, а потому что пример неудачный)

ВВ>>>- для литералов объектов

T>>{name: value, name: value}
T>>или {name = value} тоже ничо.

ВВ>Сейчас у меня так: (name: value)


ВВ>>>- для разделения выражений (вместо ; )

T>>\n

ВВ>И вводить какой-нибудь значок типа вбшного "_", чтобы выражения можно было переносить на разные строчки? Или как?


Угу. Это, опять же, кажется стрёмным на первый взгляд. На самом деле, написать '_' один раз на 100-200 строк это гораздо дешевле и чище, чем писать ';' на каждой строке.

ВВ>А как мне записать выражение вида:


ВВ>var res = (if (cond) exp1 else exp2) + (if ...


Лучше всего — через промежуточные имена, *потому что* выражение *сложное*. Так будет читабельнее.
Но если очень хочется в строку, то почему бы и нет, вроде всё позволяет.
Re[11]: Про скобочки
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.04.10 12:45
Оценка:
Здравствуйте, March_rabbit, Вы писали:

VD>>Зачем запрещать? Достаточно не допускать их смеси в одном фале.

M_>не всякий редактор покажет, что стоит имеено здесь — пробел или таб

Не пользуйся "всякими" редакторами. Пользуйся полноценными. Кроме того, табы и пробелы должны контролироваться компилятором.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Про скобочки
От: Воронков Василий Россия  
Дата: 29.04.10 13:42
Оценка:
Здравствуйте, Temoto, Вы писали:

T>Ну прям и нельзя. В том же бейсике есть специальный символ для этого: '_'. Будучи оставленным на конце строки он клеит следущую с этой строкой так, что выражение не рвётся. В питоне для этого используется обратный слеш.


Я писал на VB, и этот момент раздражал весьма сильно.
Руководствуясь твоей логикой — это ограничение, введенное, чтобы упростить жизнь компиляторо-писателям, а с т.з. языка оно никакого смысла не имеет.

T>>>x — x это отдельный случай, кстати.

ВВ>>Почему?
T>Потому что унарный минус это такая подлая штука, которая по определению — особый случай, потому что только для чисел, а языки программирования, вроде как не только про числа.

Ну только для чисел, и что? Какая разница? Из-за этого он создает ничуть не больше конфликтов, чем унарный оператор & (взять-значение — например, у lazy), который не только для чисел и конфликтует с бинарным &.

T>Я бы делал синтаксис унарного минуса таким: "-x" это он, а "- x" это правая часть от "y — x". То есть пробел обязателен вокруг нормальных операторов и обязательно без пробела после унарного минуса. Тогда "x — x" не вызывает ни визуальной неоднозначности, ни грамматической.


Угу, вставил лишний пробел и получил другую программу. Не нравится что-то.

T>(тут я схитрил) на самом деле визуальную неоднозначность убирает левый операнд. "print — x" уже однозначно понятен только парсеру.


print — x однозначно не будет понятен парсеру, в том-то и дело. Парсер парсит, он не знает, какой тип у переменных, какое у них значение и пр. Это компилятору придется "колдовать", пытаясь применить следующую эвристику:

Если для типа бинарная операция недопустима, то мы считаем, что у нас два независимых выражения, а минус — это унарная операция.

И это ты еще привел банальный пример, а в реальности случаи могут быть куда более сложными.
Ну и под занавес — вспоминаем, что в языке динамическая типизация и посылаем всю эту эвристику в одно место, ибо она попросту невозможна.

ВВ>>Ну вот с учетом того, что все в языке есть expression, *обязательность* блока мне кажется не очень уместной. Тяжеловато будет выглядеть код, где с правой стороны от "=" тебе *придется* объявлять несколько блоков.

T>Я что-то не проследил логику. Ты не мог бы подробнее объяснить?

Логика простая, представляем, что любое выражение может находиться справа от "=". Ты вот ниже предлагаешь сделать {} обязательными. Вот как это будет выглядеть:

var x = if cond { y } else { y2 }


вместо

var x = if (cond) y else y2


Мне второй вариант как-то больше нравится.

T>Да, чёт не фонтан.

T>А если второй ':' будет другим символом?

if bar(arg) || foo(arg2, x::xs) : fooBar(x, arg::arg2) _ barFoo(xs, arg2::arg)


Опять-таки — черточка ценный ресурс
Да и не могу сказать, что стало сильно лучше. Тогда уж сделать тернарный оператор с if вначале:

if bar(arg) || foo(arg2, x::xs) ? fooBar(x, arg::arg2) : barFoo(xs, arg2::arg)


ВВ>>>>- для вызова функций

T>>>Ничего. Пустой оператор. f x
ВВ>>Для вызова функции типа x -> void все равно потребуются скобочки — или какой другой (какой, кстати?) литерал для void.
T>Либо f будет означать вызов этой функции и не потребуются.

И получаем "проблему Руби" в полный рост?

T>Что такое void, для чего нужен?


void, он же unit (такой термин понятнее?). Я в предыдущем посте писал об этом. Вызов вида: func() можно рассматривать как funName arg, где () — это особые литерал для аргумента.
Собственно, явный void тут и нужен, чтобы сделать вызов явным.

ВВ>>А запятая зачем?

ВВ>>Убери — и получится Лисп. При этом лаконичным такой синтаксис не назовешь. К тому же:
T>Запятая — инфиксный конструктор кортежа. Без неё получится лисп, да.

Да и с ней некруто. Я спрашивал тут рядом — как например описать кортеж, элементами которого являются другие кортежи? Ответь, кстати, на тот пост

T>(я хочу сказать, что да, (array a, b).length это некрасиво, но не потому что синтаксис плох, а потому что пример неудачный)


Пример, конечно, высосан из пальца, но он показывает особенность такой литеральной записи. У нее нет четко оформленного "конца". А это может вызвать реальные проблемы.
Неслучайно ведь таких синтаксисов нет. И Хаскель твой любимый в этом плане куда более традиционен.

ВВ>>И вводить какой-нибудь значок типа вбшного "_", чтобы выражения можно было переносить на разные строчки? Или как?

T>Угу. Это, опять же, кажется стрёмным на первый взгляд. На самом деле, написать '_' один раз на 100-200 строк это гораздо дешевле и чище, чем писать ';' на каждой строке.

Так не бывает, не будет он у тебя один раз на 100-200 строк. Или же ты будешь писать в ВБ-стиле, так сказать. Т.е. в столбик. А все это приведет к очень сильному распуханию программы, объявлению кучу промежуточных переменных и пр. — мне вот такой код читать куда тяжелее, например.
; на каждой строке плохо, но с ним можно бороться. Есть два варианта.

1. (то, что реализовано) Точка с запятой является необязательной в том случае, если выражение является последним в блоке или же если оно следует сразу после выражением, которое заканчивается на }

Т.е. такой код валиден:

var x = {
    var tmp = 2;
    tmp * 2
 }

var y = 3


Как видишь, точка с запятой только одна.
Ну и конечно не придется писать откровенно redundant точки с запятой, как это приходится делать в C#. Например тут:

Вместо:

var f = x -> { x * x; };


будет просто

var f = x -> { x * x }



2. Убрать точку с запятой на фиг вообще. Ввести такой принцип — перед всеми "простыми" выражениями (т.е. теми, которые в обычных языках только и считаются за выражения) писать специальное ключевое слово. Например, do.
Говоря другими словами, у нас теперь все конструкции языка начинаются с ключевого слова. Вуаля, конфликтов нет. Ну делаем поблажку на то, что если у нас выражение одно-единственное в блоке, то do можно не писать:

let f = x -> x * x (* это нормально, do не нужен *)

let f2 = x -> { x * x } (* и тут тоже не нужен *)

let f3 = x -> {
  var tmp = 2
  do (x * x, tmp) (* а вот тут нужен *)
}

do f3(3)

do x = y

do -x


Проблема такого подхода — do никакого смысла не несет, это просто заплатка. Он пишется и в том случае, когда вычисленное значение не используется и в том случае, когда оно используется.
Но с другой стороны — количество таких do будет гораздо меньше чем кол-во точек с запятой. Собственно, если писать "правильно", то do придется указывать лишь у значений, который возвращаются из блоков или функций (как в пример с функцией f3).

T>Лучше всего — через промежуточные имена, *потому что* выражение *сложное*. Так будет читабельнее.

T>Но если очень хочется в строку, то почему бы и нет, вроде всё позволяет.
Нет, как же позволяет, ведь у нас \n вместо скобочек, следовательно:


var res = if cond exp /*первый конфликт*/ else expr + if ... /*второй конфликт*/
Re[18]: Про скобочки
От: Temoto  
Дата: 29.04.10 14:30
Оценка:
T>>Ну прям и нельзя. В том же бейсике есть специальный символ для этого: '_'. Будучи оставленным на конце строки он клеит следущую с этой строкой так, что выражение не рвётся. В питоне для этого используется обратный слеш.

ВВ>Я писал на VB, и этот момент раздражал весьма сильно.

ВВ>Руководствуясь твоей логикой — это ограничение, введенное, чтобы упростить жизнь компиляторо-писателям, а с т.з. языка оно никакого смысла не имеет.

Это костыль к неоднозначности "x \n + y". Полезной смысловой нагрузки, конечно, не имеет.

А кому он упрощает жизнь это субъективная штука. Повторюсь, лично мне гораздо приятнее один раз написать '\', чем сто раз ';'.

T>>>>x — x это отдельный случай, кстати.

ВВ>>>Почему?
T>>Потому что унарный минус это такая подлая штука, которая по определению — особый случай, потому что только для чисел, а языки программирования, вроде как не только про числа.

ВВ>Ну только для чисел, и что? Какая разница? Из-за этого он создает ничуть не больше конфликтов, чем унарный оператор & (взять-значение — например, у lazy), который не только для чисел и конфликтует с бинарным &.


Ну ладно, нет разницы. "x — x" не отдельный случай, если хочешь такую терминологию.
Когда я писал парсер, унарный минус у меня был проблемой, а унарного '&' просто не было в языке.

T>>Я бы делал синтаксис унарного минуса таким: "-x" это он, а "- x" это правая часть от "y — x". То есть пробел обязателен вокруг нормальных операторов и обязательно без пробела после унарного минуса. Тогда "x — x" не вызывает ни визуальной неоднозначности, ни грамматической.


ВВ>Угу, вставил лишний пробел и получил другую программу. Не нравится что-то.


Почему-то никого не смущает, что вставив лишний пробел в строковый литерал тоже получится другая программа, хотя в HTML такой "проблемы" нет. Но, хозяин — барин, конечно.

T>>(тут я схитрил) на самом деле визуальную неоднозначность убирает левый операнд. "print — x" уже однозначно понятен только парсеру.


ВВ>print — x однозначно не будет понятен парсеру, в том-то и дело. Парсер парсит, он не знает, какой тип у переменных, какое у них значение и пр. Это компилятору придется "колдовать", пытаясь применить следующую эвристику:


ВВ>Если для типа бинарная операция недопустима, то мы считаем, что у нас два независимых выражения, а минус — это унарная операция.


ВВ>И это ты еще привел банальный пример, а в реальности случаи могут быть куда более сложными.

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

Ладно, я ошибся словом, нужно было сказать "компилятор" вместо "парсер". Ощущение борьбы за термины опять.

ВВ>>>Ну вот с учетом того, что все в языке есть expression, *обязательность* блока мне кажется не очень уместной. Тяжеловато будет выглядеть код, где с правой стороны от "=" тебе *придется* объявлять несколько блоков.

T>>Я что-то не проследил логику. Ты не мог бы подробнее объяснить?

ВВ>Логика простая, представляем, что любое выражение может находиться справа от "=". Ты вот ниже предлагаешь сделать {} обязательными. Вот как это будет выглядеть:


ВВ>
ВВ>var x = if cond { y } else { y2 }
ВВ>


ВВ>вместо


ВВ>
ВВ>var x = if (cond) y else y2
ВВ>


ВВ>Мне второй вариант как-то больше нравится.


А мне больше нравится var x = y if cond else y2. Уже который раз ты сравниваешь два варианта: плохой, который я не предлагал и хороший, который предлагаешь ты.
Я предлагал выделять *блоки стейтментов*. А в 'if-выражении', на мой взгляд, блоки не нужны, там можно ограничиться одним выражением в каждой позиции.

T>>Да, чёт не фонтан.

T>>А если второй ':' будет другим символом?

ВВ>
ВВ>if bar(arg) || foo(arg2, x::xs) : fooBar(x, arg::arg2) _ barFoo(xs, arg2::arg)
ВВ>


ВВ>Опять-таки — черточка ценный ресурс

ВВ>Да и не могу сказать, что стало сильно лучше. Тогда уж сделать тернарный оператор с if вначале:

ВВ>
ВВ>if bar(arg) || foo(arg2, x::xs) ? fooBar(x, arg::arg2) : barFoo(xs, arg2::arg)
ВВ>


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

ВВ>>>>>- для вызова функций

T>>>>Ничего. Пустой оператор. f x
ВВ>>>Для вызова функции типа x -> void все равно потребуются скобочки — или какой другой (какой, кстати?) литерал для void.
T>>Либо f будет означать вызов этой функции и не потребуются.

ВВ>И получаем "проблему Руби" в полный рост?


Да. И это может быть вполне разумным компромиссом. Рубироидники от этой "проблемы" не плачут по ночам.

T>>Что такое void, для чего нужен?


ВВ>void, он же unit (такой термин понятнее?).


Нет, не понятнее, увы.

ВВ>Я в предыдущем посте писал об этом. Вызов вида: func() можно рассматривать как funName arg, где () — это особые литерал для аргумента.

ВВ>Собственно, явный void тут и нужен, чтобы сделать вызов явным.

Вызов функции без аргументов это единственное зачем нужен void?

ВВ>>>А запятая зачем?

ВВ>>>Убери — и получится Лисп. При этом лаконичным такой синтаксис не назовешь. К тому же:
T>>Запятая — инфиксный конструктор кортежа. Без неё получится лисп, да.

ВВ>Да и с ней некруто. Я спрашивал тут рядом — как например описать кортеж, элементами которого являются другие кортежи? Ответь, кстати, на тот пост


(извини, искать посты не охота)

Группировка выражений — скобки.

a, (b1, b2), c

T>>(я хочу сказать, что да, (array a, b).length это некрасиво, но не потому что синтаксис плох, а потому что пример неудачный)


ВВ>Пример, конечно, высосан из пальца, но он показывает особенность такой литеральной записи. У нее нет четко оформленного "конца". А это может вызвать реальные проблемы.

ВВ>Неслучайно ведь таких синтаксисов нет. И Хаскель твой любимый в этом плане куда более традиционен.

И мой любимый хацкель несовершенен. Я глубоко уважаю многие его качества, но не считаю, что он идеальный пример для подражания. (потому что кумиры/идеалы это вредно)

Если б у всего был чёткий конец, то не нужны были бы приоритеты операторов. Я хочу сказать, что может быть и не нужно стремиться к чётким концам.

Кстати, в Flow я не делал литералы для списков и массивов вообще.

array a, b это вызов функции array с одним аргументом: кортежем a, b. Она, в данном случае, является конструктором значения из другого значения. Своего рода каст.

ВВ>>>И вводить какой-нибудь значок типа вбшного "_", чтобы выражения можно было переносить на разные строчки? Или как?

T>>Угу. Это, опять же, кажется стрёмным на первый взгляд. На самом деле, написать '_' один раз на 100-200 строк это гораздо дешевле и чище, чем писать ';' на каждой строке.

ВВ>Так не бывает, не будет он у тебя один раз на 100-200 строк. Или же ты будешь писать в ВБ-стиле, так сказать. Т.е. в столбик. А все это приведет к очень сильному распуханию программы, объявлению кучу промежуточных переменных и пр. — мне вот такой код читать куда тяжелее, например.

ВВ>; на каждой строке плохо, но с ним можно бороться. Есть два варианта.

Ну наверное не бывает. А я могу посчитать кол-во обратных слешей в своих программах. В одном проекте было 2 '\' на 811 строк кода. Может быть оно там как-то в столбик, в неугодном стиле. Несколько людей читали и понимали, на вертикальность никто не ругался.

ВВ>1. (то, что реализовано) Точка с запятой является необязательной в том случае, если выражение является последним в блоке или же если оно следует сразу после выражением, которое заканчивается на }


ВВ>2. Убрать точку с запятой на фиг вообще. Ввести такой принцип — перед всеми "простыми" выражениями (т.е. теми, которые в обычных языках только и считаются за выражения) писать специальное ключевое слово. Например, do.

ВВ>Говоря другими словами, у нас теперь все конструкции языка начинаются с ключевого слова. Вуаля, конфликтов нет. Ну делаем поблажку на то, что если у нас выражение одно-единственное в блоке, то do можно не писать:

ВВ>Проблема такого подхода — do никакого смысла не несет, это просто заплатка. Он пишется и в том случае, когда вычисленное значение не используется и в том случае, когда оно используется.

ВВ>Но с другой стороны — количество таких do будет гораздо меньше чем кол-во точек с запятой. Собственно, если писать "правильно", то do придется указывать лишь у значений, который возвращаются из блоков или функций (как в пример с функцией f3).

Да, отсутствие смысла в do режет глаз. Такая же заплатка, как '_' или '\' только с другой стороны.

T>>Лучше всего — через промежуточные имена, *потому что* выражение *сложное*. Так будет читабельнее.

T>>Но если очень хочется в строку, то почему бы и нет, вроде всё позволяет.
ВВ>Нет, как же позволяет, ведь у нас \n вместо скобочек, следовательно:

Поправка: '\n' вместо ';', а не скобочек. Отступы вместо фигурных скобок *вокруг блоков*.

ВВ>
ВВ>var res = if cond exp /*первый конфликт*/ else expr + if ... /*второй конфликт*/
ВВ>


Я не вижу конфликта при такой грамматике:

if → "if" expr expr "else" expr
expr → atom | if | atom op atom | ...
atom → number | string | ...
op → "+" | "-" | ...
Re[19]: Про скобочки
От: Воронков Василий Россия  
Дата: 29.04.10 15:09
Оценка: +1
Здравствуйте, Temoto, Вы писали:

T>Ну ладно, нет разницы. "x — x" не отдельный случай, если хочешь такую терминологию.

T>Когда я писал парсер, унарный минус у меня был проблемой, а унарного '&' просто не было в языке.

А унарный плюс был?

T>>>Я бы делал синтаксис унарного минуса таким: "-x" это он, а "- x" это правая часть от "y — x". То есть пробел обязателен вокруг нормальных операторов и обязательно без пробела после унарного минуса. Тогда "x — x" не вызывает ни визуальной неоднозначности, ни грамматической.


ВВ>>Угу, вставил лишний пробел и получил другую программу. Не нравится что-то.


T>Почему-то никого не смущает, что вставив лишний пробел в строковый литерал тоже получится другая программа, хотя в HTML такой "проблемы" нет. Но, хозяин — барин, конечно.


Все эти варианты — довольно хитрая эвристика, которая по сути будет догадываться, как рассматривать то или иное выражение. А раз мы догадываемся, то будет и ошибаться. И программа будет работать не так, как "выглядит".
Аналогичная проблема есть у джава-скрипта с его алгоритмом автодополнения пропущенных ; который создает больше проблем решает.

Грамматика с обязательным ; хороша хотя бы тем, что она однозначна. Однозначностью жертвовать не хочется.

ВВ>>И это ты еще привел банальный пример, а в реальности случаи могут быть куда более сложными.

ВВ>>Ну и под занавес — вспоминаем, что в языке динамическая типизация и посылаем всю эту эвристику в одно место, ибо она попросту невозможна.
T>Ладно, я ошибся словом, нужно было сказать "компилятор" вместо "парсер". Ощущение борьбы за термины опять.

Это не борьба за термины. Неважно, кто занимается этой эвристикой — парсер или компилятор. Важно в данном случае то, что такая эвристика попросту невозможна в языке с динамической типизацией
Понимаешь — не термины виноваты, просто предложенный тобой вариант сделать нельзя.

Единственное, что можно — это уже в рантайме пытаться как-то определять смысл выражений, т.е. виртуальная машина вместо того, чтобы выполнять тупые pop-ы и nop-ы, будет эвристики делать. То, что производительность упадет ниже плинтуса это понятно сразу. Хотя даже еще не совсем понятно, как это вообще реализовать.

Наконец опять — мы *догадываемся* о том, что хотел пользователь. А может, он хотел из функции целое вычесть? Думал, что таким образом можно декаррирование сделать? Или просто переменные перепутал? А мы ему в ответ выполним какую-то хрень. По этому поводу опять бейсик вспоминается — если мы не уверены, что хотел программист, то давайте угадаем. На практике это создает больше проблем, чем решает.

На мой взгляд, если есть неоднозначность, то должна быть ошибка или по крайней мере ворнинг. Пример, который ты же сам привел, яркий пример такой неоднозначности.

T>А мне больше нравится var x = y if cond else y2. Уже который раз ты сравниваешь два варианта: плохой, который я не предлагал и хороший, который предлагаешь ты.


Ты же предлагал там где-то ниже сделать фигурные скобочки для блока if обязательными.
А var x = y if cond else y2 как будет выглядеть в качестве стейтмента?

cout "Hello, world!"  
  if cond 
  else 
cout "Goodbuy, world!"


? Что-то не то...

T>Я предлагал выделять *блоки стейтментов*. А в 'if-выражении', на мой взгляд, блоки не нужны, там можно ограничиться одним выражением в каждой позиции.


А если нужно несколько выражений внутри if?

T>Мне принципиально не нравится вся эта запись в одну строку. Слишком много смысла в одной строке. И она неминуемо будет очень длинной в реальном коде.


Я специально записываю все одну строку. Нравится или не нравится — другой вопрос. Но ты в своих примерах хитришь. Речь же идет о символах, с помощью которых можно заменить if/else. Ты же оформляешь свои примеры с разбиением на строки и фактически у тебя разделением логических частей выражения являются не эти диковинные закорючки, а перевод каретки. Потому и выглядит все хорошо.
А когда записываешь в одну строку — независимо от стилистических предпочтений, — то сразу видно, как оно там на самом-то деле.

ВВ>>>>>>- для вызова функций

T>>>>>Ничего. Пустой оператор. f x
ВВ>>>>Для вызова функции типа x -> void все равно потребуются скобочки — или какой другой (какой, кстати?) литерал для void.
T>>>Либо f будет означать вызов этой функции и не потребуются.
ВВ>>И получаем "проблему Руби" в полный рост?
T>Да. И это может быть вполне разумным компромиссом. Рубироидники от этой "проблемы" не плачут по ночам.

Компромиссом между чем и чем? Не делаем функции first class objects, чтобы избавиться от пары скобочек?
Честно, мне кажется, что это перебор. Да и совершенно неприемлимо для функционального языка.

T>>>Что такое void, для чего нужен?

ВВ>>void, он же unit (такой термин понятнее?).
T>Нет, не понятнее, увы.

unit — это то значение, которое в языках группы ML возвращают некоторые выражение. Например, let binding.

ВВ>>Я в предыдущем посте писал об этом. Вызов вида: func() можно рассматривать как funName arg, где () — это особые литерал для аргумента.

ВВ>>Собственно, явный void тут и нужен, чтобы сделать вызов явным.
T>Вызов функции без аргументов это единственное зачем нужен void?

В данном контексте — да.

T>(извини, искать посты не охота)

T>Группировка выражений — скобки.
T>a, (b1, b2), c

Ну т.е. экономия на скобочках в данном случае получается незначительной?

T>Кстати, в Flow я не делал литералы для списков и массивов вообще.

T>array a, b это вызов функции array с одним аргументом: кортежем a, b. Она, в данном случае, является конструктором значения из другого значения. Своего рода каст.

А пустой массив как создать?
А как, например, делать паттерн-матчинг по списку, если нет литерала списка?
Как к голове списка прибавить другое значение?

T>Да, отсутствие смысла в do режет глаз. Такая же заплатка, как '_' или '\' только с другой стороны.


А вариант с "не всегда обязательными" ; не решает проблему излишних точек с запятой?

T>Я не вижу конфликта при такой грамматике:

T>if → "if" expr expr "else" expr
T>expr → atom | if | atom op atom | ...
T>atom → number | string | ...
T>op → "+" | "-" | ...

По этой грамматике у тебя такое выражение невозможно: expr + expr. Т.е. на практике даже такое не будет работать: (2 + 3) + 4, потому что (2 + 3) — это не atom.
Т.е. это попросту не "боевая" грамматика.
И я уже говорил выше, что если грамматика языка позволяет записать expr expr без конфликтов, то круглые скобочки и точка с запятой автоматически идут в лес. Но с Си-подобной грамматикой это невозможно. Этого можно добиться если:

— Выкинуть пост и пре инкремент и декрементом на фиг
— Ввести постфиксную запись для унарных операторов или обязательные скобочки
— Сделать разный синтаксис вызова функции и создания кортежа
— Сделать разный синтаксис для литерала списка и индексера
— ... можем быть, что-то еще
Re[20]: Про скобочки
От: Temoto  
Дата: 29.04.10 15:43
Оценка:
T>>Ну ладно, нет разницы. "x — x" не отдельный случай, если хочешь такую терминологию.
T>>Когда я писал парсер, унарный минус у меня был проблемой, а унарного '&' просто не было в языке.

ВВ>А унарный плюс был?


Не-а.

T>>>>Я бы делал синтаксис унарного минуса таким: "-x" это он, а "- x" это правая часть от "y — x". То есть пробел обязателен вокруг нормальных операторов и обязательно без пробела после унарного минуса. Тогда "x — x" не вызывает ни визуальной неоднозначности, ни грамматической.


ВВ>>>Угу, вставил лишний пробел и получил другую программу. Не нравится что-то.


T>>Почему-то никого не смущает, что вставив лишний пробел в строковый литерал тоже получится другая программа, хотя в HTML такой "проблемы" нет. Но, хозяин — барин, конечно.


ВВ>Все эти варианты — довольно хитрая эвристика, которая по сути будет догадываться, как рассматривать то или иное выражение. А раз мы догадываемся, то будет и ошибаться. И программа будет работать не так, как "выглядит".

ВВ>Аналогичная проблема есть у джава-скрипта с его алгоритмом автодополнения пропущенных ; который создает больше проблем решает.

ВВ>Грамматика с обязательным ; хороша хотя бы тем, что она однозначна. Однозначностью жертвовать не хочется.


И точно тем же самым она плоха, потому что ты можешь вставить ';' там, где "не надо" и программа будет работать не так как выглядит. Это надо давать людям инструмент, смотреть как они пользуются, какие ошибки возникают. А то получается результаты исследования на бумаге. Заведомо оторваны от реальности.

ВВ>>>И это ты еще привел банальный пример, а в реальности случаи могут быть куда более сложными.

ВВ>>>Ну и под занавес — вспоминаем, что в языке динамическая типизация и посылаем всю эту эвристику в одно место, ибо она попросту невозможна.
T>>Ладно, я ошибся словом, нужно было сказать "компилятор" вместо "парсер". Ощущение борьбы за термины опять.

ВВ>Это не борьба за термины. Неважно, кто занимается этой эвристикой — парсер или компилятор. Важно в данном случае то, что такая эвристика попросту невозможна в языке с динамической типизацией

ВВ>Понимаешь — не термины виноваты, просто предложенный тобой вариант сделать нельзя.

Ну подумаешь "print — x" кинет исключение во время работы, а не во время компиляции. О каких эвристиках речь вобще? Какая тут неоднозначность?

ВВ>На мой взгляд, если есть неоднозначность, то должна быть ошибка или по крайней мере ворнинг. Пример, который ты же сам привел, яркий пример такой неоднозначности.


T>>А мне больше нравится var x = y if cond else y2. Уже который раз ты сравниваешь два варианта: плохой, который я не предлагал и хороший, который предлагаешь ты.


ВВ>Ты же предлагал там где-то ниже сделать фигурные скобочки для блока if обязательными.

ВВ>А var x = y if cond else y2 как будет выглядеть в качестве стейтмента?

Вот '=' это инфиксный стейтмент.

ВВ>
ВВ>cout "Hello, world!"  
ВВ>  if cond 
ВВ>  else 
ВВ>cout "Goodbuy, world!"
ВВ>


ВВ>? Что-то не то...


Ну да. Ты опять придумываешь стрёмные примеры.

cout "Hello, world!" if cond else "Goodbye world!"

T>>Я предлагал выделять *блоки стейтментов*. А в 'if-выражении', на мой взгляд, блоки не нужны, там можно ограничиться одним выражением в каждой позиции.


ВВ>А если нужно несколько выражений внутри if?


Тогда это не выражение. Определи семантику выражения "несколько выражений" пожалуйста. Чему оно равно, как вычислять.

T>>Мне принципиально не нравится вся эта запись в одну строку. Слишком много смысла в одной строке. И она неминуемо будет очень длинной в реальном коде.


ВВ>Я специально записываю все одну строку. Нравится или не нравится — другой вопрос. Но ты в своих примерах хитришь. Речь же идет о символах, с помощью которых можно заменить if/else. Ты же оформляешь свои примеры с разбиением на строки и фактически у тебя разделением логических частей выражения являются не эти диковинные закорючки, а перевод каретки. Потому и выглядит все хорошо.

ВВ>А когда записываешь в одну строку — независимо от стилистических предпочтений, — то сразу видно, как оно там на самом-то деле.

Ну да, видишь, обязательный перевод строки лечит проблемы которые "там на самом-то деле".

ВВ>>>>>>>- для вызова функций

T>>>>>>Ничего. Пустой оператор. f x
ВВ>>>>>Для вызова функции типа x -> void все равно потребуются скобочки — или какой другой (какой, кстати?) литерал для void.
T>>>>Либо f будет означать вызов этой функции и не потребуются.
ВВ>>>И получаем "проблему Руби" в полный рост?
T>>Да. И это может быть вполне разумным компромиссом. Рубироидники от этой "проблемы" не плачут по ночам.

ВВ>Компромиссом между чем и чем? Не делаем функции first class objects, чтобы избавиться от пары скобочек?

ВВ>Честно, мне кажется, что это перебор. Да и совершенно неприемлимо для функционального языка.

Ещё раз, у рубироидников всё нормально. Это опыт многих людей, многих лет. А ты вот так из пальца говоришь, что это неприемлимо.

T>>>>Что такое void, для чего нужен?

ВВ>>>void, он же unit (такой термин понятнее?).
T>>Нет, не понятнее, увы.

ВВ>unit — это то значение, которое в языках группы ML возвращают некоторые выражение. Например, let binding.


ВВ>>>Я в предыдущем посте писал об этом. Вызов вида: func() можно рассматривать как funName arg, где () — это особые литерал для аргумента.

ВВ>>>Собственно, явный void тут и нужен, чтобы сделать вызов явным.
T>>Вызов функции без аргументов это единственное зачем нужен void?

ВВ>В данном контексте — да.


Ну тогда можно префиксный оператор 'call', например.

T>>(извини, искать посты не охота)

T>>Группировка выражений — скобки.
T>>a, (b1, b2), c

ВВ>Ну т.е. экономия на скобочках в данном случае получается незначительной?


В контексте кортежей экономия в любом случае будет максимум — 2 скобки с каждого кортежа. Поскольку в выражениях редко встречается несколько кортежей сразу, то да, в каком-то приближении можно сказать, что она всегда незначительна.
А если из программы убрать 800 скобок, то вроде уже и значительно.
А если из программы в 14500 символов убрать 800 скобок, то опять незначительно.
Это игра слов.

T>>Кстати, в Flow я не делал литералы для списков и массивов вообще.

T>>array a, b это вызов функции array с одним аргументом: кортежем a, b. Она, в данном случае, является конструктором значения из другого значения. Своего рода каст.

ВВ>А пустой массив как создать?


array

ВВ>А как, например, делать паттерн-матчинг по списку, если нет литерала списка?


Точно так же, как делать патерн-матчинг по юзерскому типу с юзерским конструктором.

case foo of
list args → print args

ВВ>Как к голове списка прибавить другое значение?


xs = list 1, 2
(head xs) + 3 # 4

T>>Да, отсутствие смысла в do режет глаз. Такая же заплатка, как '_' или '\' только с другой стороны.


ВВ>А вариант с "не всегда обязательными" ; не решает проблему излишних точек с запятой?


Ты же сам критиковал эвристику жаваскрипта. Здесь то же самое, только упрощено.
По сути, они всегда обязательны между двумя стейтментами. Ну ладно, из 10 строк в одной ты не пишешь ';'. Ну ладно, к этому складывается ещё несколько мест, где тоже не пишешь. Но программист, который не писал парсер не держит в голове полную грамматику языка. Ему на бизнес-задаче надо концентрироваться, а не на оптимальной расстановке ';', поэтому такой вариант не катит, как сложный для понимания.
Я в жаваскрипте пишу ';' только потому что это единственный для меня способ *надёжно* сообщить интепретатору единственный смысл. Чтоб в каких-то местах пропускать разделитель мне уже нужно думать, мол, а разрешено ли это здесь.

T>>Я не вижу конфликта при такой грамматике:

T>>if → "if" expr expr "else" expr
T>>expr → atom | if | atom op atom | ...
T>>atom → number | string | ...
T>>op → "+" | "-" | ...

ВВ>По этой грамматике у тебя такое выражение невозможно: expr + expr. Т.е. на практике даже такое не будет работать: (2 + 3) + 4, потому что (2 + 3) — это не atom.

ВВ>Т.е. это попросту не "боевая" грамматика.

омг ну добавь "(" expr ")" в atom, это же очевидно.
Да, она не боевая. Какая разница? Я просто хотел сказать, что в указанном тобой выражении не вижу конфликтов при таком-то условии (грамматика). А ты, блин, вместо того чтоб показать при каких условиях там таки есть конфликт, ищешь несостоятельность грамматики.

ВВ>И я уже говорил выше, что если грамматика языка позволяет записать expr expr без конфликтов, то круглые скобочки и точка с запятой автоматически идут в лес. Но с Си-подобной грамматикой это невозможно. Этого можно добиться если:


ВВ>- Выкинуть пост и пре инкремент и декрементом на фиг

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

У меня не было терма expr expr. Я вообще затрудняюсь придумать что он должен значить.
expr op expr, где op = "" я могу понять. А вот так просто expr expr это какой-то нонсенс.
Re[2]: Про скобочки
От: Gaperton http://gaperton.livejournal.com
Дата: 29.04.10 15:45
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

ВВ>>А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях. Например, вместо


PD>И получился у тебя Паскаль — почти 1:1


У него получился Google Go. Один в один, без почти.
Re[21]: Про скобочки
От: Воронков Василий Россия  
Дата: 29.04.10 16:08
Оценка:
Здравствуйте, Temoto, Вы писали:

ВВ>>Грамматика с обязательным ; хороша хотя бы тем, что она однозначна. Однозначностью жертвовать не хочется.

T>И точно тем же самым она плоха, потому что ты можешь вставить ';' там, где "не надо" и программа будет работать не так как выглядит. Это надо давать людям инструмент, смотреть как они пользуются, какие ошибки возникают. А то получается результаты исследования на бумаге. Заведомо оторваны от реальности.

Если я вставлю ";" там, где не надо — а кстати, пример можно? а мне сложновато представить, к тому же во многих случаях лишние ";" вполне допускаются, — то по тексту программу будет видно, где ошибка. В случае с print — x и прочими радостями — не видно. Так что разница большая на самом деле.

T>Ну подумаешь "print — x" кинет исключение во время работы, а не во время компиляции. О каких эвристиках речь вобще? Какая тут неоднозначность?


Эээ, ты издеваешься? Неоднозначность простая. Ты не забыл о чем мы говорили? Как рассматривать выражение:

print
-x

Ты предлагал ввести некий анализ, с помощью которого можно определить, что это на самом деле не вычитание x из print, а два выражения.
Так вот — в динамическом языке такой анализ невозможен.

ВВ>>? Что-то не то...

T>Ну да. Ты опять придумываешь стрёмные примеры.
T>cout "Hello, world!" if cond else "Goodbye world!"

Нормальный пример. Я придумываю пример, в котором условное выражение находит не "справа", а "слева", т.е. само по себе является стейтментом. Предположим, что его части вообще никакого полезного значения не возвращают.
Вот другой пример:

cout myStupidFunc(...)
  if cond 
  else 
throw "Error!"


T>>>Я предлагал выделять *блоки стейтментов*. А в 'if-выражении', на мой взгляд, блоки не нужны, там можно ограничиться одним выражением в каждой позиции.

ВВ>>А если нужно несколько выражений внутри if?
T>Тогда это не выражение. Определи семантику выражения "несколько выражений" пожалуйста. Чему оно равно, как вычислять.

Все есть выражение. Даже блок {} — это выражение. В языке же нет разделения на стейтменты и экспрешины, поэтому все твои примеры неизбежно надо рассматривать и в роли экспрешинов и в роли стейтментов.

T>Ну да, видишь, обязательный перевод строки лечит проблемы которые "там на самом-то деле".


Ну т.е. под видом всяких : | _ ты как бы "зашифровано" предлагал перевод строки?

ВВ>>Компромиссом между чем и чем? Не делаем функции first class objects, чтобы избавиться от пары скобочек?

ВВ>>Честно, мне кажется, что это перебор. Да и совершенно неприемлимо для функционального языка.
T>Ещё раз, у рубироидников всё нормально. Это опыт многих людей, многих лет. А ты вот так из пальца говоришь, что это неприемлимо.

А у людей всегда все нормально. У ПХП-ников все нормально. У Сишников тоже все нормально. У всех все нормально. И это опыт многих людей и многих лет. Это *всегда* опыт многих людей и многих лет. Даже когда речь идет о кривом дизайне и кривых решениях.

Ты, я так понимаю, в свой язык решил добавить такую возможность, оттого и выступаешь с ее апологией. Я бы не советовал. Если только язык не удовлетворяет хотя бы одному из требований: 1) полностью ленивый и 2) чистый функциональный. Синтаксис — это одно. Но невозможность нормально писать в функциональном стиле, использовать функции высшего порядке, только потому что кто-то экономил на скобках или еще на чем — это не вариант.
Проще запретить объявлять функции без параметров вообще, это и лучше.

Опять же, напомню тебе твои же слова — зачем вводить в язык необоснованные ограничения? Как например невозможность передать функцию как значение. Причем *только* из-за синтаксиса.

T>>>Вызов функции без аргументов это единственное зачем нужен void?

ВВ>>В данном контексте — да.
T>Ну тогда можно префиксный оператор 'call', например.

А тип функции без параметров какой? Все равно же это type -> void. Почему бы явно это не описать? Да и какую проблему решает префиксный оператор? Избавляемся от скобок справа, вводим ключевой слово слева?

T>В контексте кортежей экономия в любом случае будет максимум — 2 скобки с каждого кортежа. Поскольку в выражениях редко встречается несколько кортежей сразу, то да, в каком-то приближении можно сказать, что она всегда незначительна.

T>А если из программы убрать 800 скобок, то вроде уже и значительно.
T>А если из программы в 14500 символов убрать 800 скобок, то опять незначительно.
T>Это игра слов.

Ты понимаешь, скобочки хочется не просто убрать. Хочется не убрать вместе со скобочками что-нибудь еще, как например, first class функции.

ВВ>>А пустой массив как создать?

T>array

Описал бы лучше полностью свой синтаксис с примерами.

ВВ>>А вариант с "не всегда обязательными" ; не решает проблему излишних точек с запятой?

T>Ты же сам критиковал эвристику жаваскрипта. Здесь то же самое, только упрощено.

Здесь не то же самое. Если ты так говоришь, то просто не понимаешь, что на самом деле происходит в джава-скрипте. Там в зависимости от версии алгоритм добавления ";" такое выражение:


return 
{
  Value1: ...,
  Value2: ...
}



можешь превратить в такое:


return;
{
  Value1: ...,
  Value2: ...
}



и получишь кукишь с маслом вместо значения из функции.
Описанный мной алгоритм очень прост — у последнего выражения в блоке можно опустить точку с запятой. А можно и не опускать. Можно дописать еще и пару лишних. Никакой неоднозначности не будет.
По-моему запомнить это совсем несложно.

T>По сути, они всегда обязательны между двумя стейтментами.


Вовсе нет. Даже в Си это не так.

T>>>Я не вижу конфликта при такой грамматике:

T>>>if → "if" expr expr "else" expr
T>>>expr → atom | if | atom op atom | ...
T>>>atom → number | string | ...
T>>>op → "+" | "-" | ...

ВВ>>По этой грамматике у тебя такое выражение невозможно: expr + expr. Т.е. на практике даже такое не будет работать: (2 + 3) + 4, потому что (2 + 3) — это не atom.

ВВ>>Т.е. это попросту не "боевая" грамматика.

T>омг ну добавь "(" expr ")" в atom, это же очевидно.


ОК. Тогда такое выражение невозможно 2 + 3 + 4.
Что еще такое "очевидное" добавить в грамматику?

T>Да, она не боевая. Какая разница? Я просто хотел сказать, что в указанном тобой выражении не вижу конфликтов при таком-то условии (грамматика). А ты, блин, вместо того чтоб показать при каких условиях там таки есть конфликт, ищешь несостоятельность грамматики.


Разница большая. Можно придумать грамматику из трех строк, в которой конфликтов не будет. Но в реальной грамматике, где учитываются все операции — конфликты будут. Зачем приводить пример такой игрушечной грамматики без конфликтов? Что он показывает?

T>У меня не было терма expr expr. Я вообще затрудняюсь придумать что он должен значить.

T>expr op expr, где op = "" я могу понять. А вот так просто expr expr это какой-то нонсенс.

Ну как же, вот он:

if → "if" expr expr "else" expr
Re: Про скобочки
От: RiNSpy  
Дата: 29.04.10 16:08
Оценка:
Поддерживаю.

Синтаксический оверхед, однако.
Re[3]: Про скобочки
От: Воронков Василий Россия  
Дата: 29.04.10 16:37
Оценка:
Здравствуйте, Gaperton, Вы писали:

PD>>И получился у тебя Паскаль — почти 1:1

G>У него получился Google Go. Один в один, без почти.

В Гоу фигурные скобки обязательны, а круглые — нет. Я фигурные скобки не трогаю, рассматриваю вариант вместо круглых использовать другой токен, вроде 'do' или 'then'. И сдается мне, что на Гоу это похоже слабо.
Re[22]: Про скобочки
От: Temoto  
Дата: 29.04.10 17:28
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


ВВ>>>Грамматика с обязательным ; хороша хотя бы тем, что она однозначна. Однозначностью жертвовать не хочется.

T>>И точно тем же самым она плоха, потому что ты можешь вставить ';' там, где "не надо" и программа будет работать не так как выглядит. Это надо давать людям инструмент, смотреть как они пользуются, какие ошибки возникают. А то получается результаты исследования на бумаге. Заведомо оторваны от реальности.

ВВ>Если я вставлю ";" там, где не надо — а кстати, пример можно? а мне сложновато представить, к тому же во многих случаях лишние ";" вполне допускаются, — то по тексту программу будет видно, где ошибка. В случае с print — x и прочими радостями — не видно. Так что разница большая на самом деле.


Все те же примеры, которые ты приводил про перевод строки.

x; -y

arr;[index]

print; x

T>>Ну подумаешь "print — x" кинет исключение во время работы, а не во время компиляции. О каких эвристиках речь вобще? Какая тут неоднозначность?


ВВ>Эээ, ты издеваешься? Неоднозначность простая. Ты не забыл о чем мы говорили? Как рассматривать выражение:


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

ВВ>print

ВВ>-x

ВВ>Ты предлагал ввести некий анализ, с помощью которого можно определить, что это на самом деле не вычитание x из print, а два выражения.

ВВ>Так вот — в динамическом языке такой анализ невозможен.

Я точно предлагал анализ?

ВВ>>>? Что-то не то...

T>>Ну да. Ты опять придумываешь стрёмные примеры.
T>>cout "Hello, world!" if cond else "Goodbye world!"

ВВ>Нормальный пример. Я придумываю пример, в котором условное выражение находит не "справа", а "слева", т.е. само по себе является стейтментом. Предположим, что его части вообще никакого полезного значения не возвращают.

ВВ>Вот другой пример:

Если его части полезного значения не возвращают, значит это тут не нужно if-выражение.
Как вариант, можно отдельно иметь классический if-statement.

Ты смешиваешь тернарный условный оператор (if-else-expression) и if-statement. Они для разных целей используются. Поэтому один выглядит уродливо там, где нужно применить второй. Это нормально.

T>>>>Я предлагал выделять *блоки стейтментов*. А в 'if-выражении', на мой взгляд, блоки не нужны, там можно ограничиться одним выражением в каждой позиции.

ВВ>>>А если нужно несколько выражений внутри if?
T>>Тогда это не выражение. Определи семантику выражения "несколько выражений" пожалуйста. Чему оно равно, как вычислять.

ВВ>Все есть выражение. Даже блок {} — это выражение. В языке же нет разделения на стейтменты и экспрешины, поэтому все твои примеры неизбежно надо рассматривать и в роли экспрешинов и в роли стейтментов.


Я снова попрошу определить семантику выражения "несколько выражений" или блока. Это кажется чем-то очевидным и естественным, на самом деле возможны разные варианты и когда ты дашь определение, у нас будет общая база.

T>>Ну да, видишь, обязательный перевод строки лечит проблемы которые "там на самом-то деле".


ВВ>Ну т.е. под видом всяких : | _ ты как бы "зашифровано" предлагал перевод строки?


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

if not foo: continue # это единственный случай, где я сомневаюсь: ставить перевод строки или нет. И когда всё-таки поставлю тоже выглядит нормально.

ВВ>>>Компромиссом между чем и чем? Не делаем функции first class objects, чтобы избавиться от пары скобочек?

ВВ>>>Честно, мне кажется, что это перебор. Да и совершенно неприемлимо для функционального языка.
T>>Ещё раз, у рубироидников всё нормально. Это опыт многих людей, многих лет. А ты вот так из пальца говоришь, что это неприемлимо.

ВВ>А у людей всегда все нормально. У ПХП-ников все нормально. У Сишников тоже все нормально. У всех все нормально. И это опыт многих людей и многих лет. Это *всегда* опыт многих людей и многих лет. Даже когда речь идет о кривом дизайне и кривых решениях.


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

От всех сишников, в один голос: рутина, рутина, нет неймспейсов, рутина, сегфолты, рутина. Действительно, на скобки никто не жалуется.

ВВ>Ты, я так понимаю, в свой язык решил добавить такую возможность, оттого и выступаешь с ее апологией. Я бы не советовал. Если только язык не удовлетворяет хотя бы одному из требований: 1) полностью ленивый и 2) чистый функциональный. Синтаксис — это одно. Но невозможность нормально писать в функциональном стиле, использовать функции высшего порядке, только потому что кто-то экономил на скобках или еще на чем — это не вариант.

ВВ>Проще запретить объявлять функции без параметров вообще, это и лучше.

ВВ>Опять же, напомню тебе твои же слова — зачем вводить в язык необоснованные ограничения? Как например невозможность передать функцию как значение. Причем *только* из-за синтаксиса.


В Flow это лечится ленивостью.
Я не выступаю с апологией конкретно этого подхода. Я говорю, что это разумный вариант. Один из многих других вариантов.

T>>>>Вызов функции без аргументов это единственное зачем нужен void?

ВВ>>>В данном контексте — да.
T>>Ну тогда можно префиксный оператор 'call', например.

ВВ>А тип функции без параметров какой? Все равно же это type -> void. Почему бы явно это не описать? Да и какую проблему решает префиксный оператор? Избавляемся от скобок справа, вводим ключевой слово слева?


Тип функции без параметров: type.
type → void это отображение какого-то типа на одно значение void, то есть функция-константа, которая с любым аргументом возвращает одно значение.

Избавляемся от void, вводим ключевое слово для редкого случая — вызов нулларной функции.
Опять, это один из многих вариантов, я не продвигаю конкретно 'call'.

T>>В контексте кортежей экономия в любом случае будет максимум — 2 скобки с каждого кортежа. Поскольку в выражениях редко встречается несколько кортежей сразу, то да, в каком-то приближении можно сказать, что она всегда незначительна.

T>>А если из программы убрать 800 скобок, то вроде уже и значительно.
T>>А если из программы в 14500 символов убрать 800 скобок, то опять незначительно.
T>>Это игра слов.

ВВ>Ты понимаешь, скобочки хочется не просто убрать. Хочется не убрать вместе со скобочками что-нибудь еще, как например, first class функции.


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

ВВ>>>А пустой массив как создать?

T>>array

ВВ>Описал бы лучше полностью свой синтаксис с примерами.


http://s.temoto.ru/flow/spec.rst
Здесь есть очень старая версия. Там, может быть, всё ещё есть []. Но вроде бы должны быть примеры других конструкций типа bytes "foo".

ВВ>>>А вариант с "не всегда обязательными" ; не решает проблему излишних точек с запятой?

T>>Ты же сам критиковал эвристику жаваскрипта. Здесь то же самое, только упрощено.

ВВ>Здесь не то же самое. Если ты так говоришь, то просто не понимаешь, что на самом деле происходит в джава-скрипте.


Да, всё верно. Я сказал

Здесь то же самое, только упрощено.

а ты пропустил половину предложения.

Под "здесь то же самое" я подразумевал именно "не всегда обязательные ';'".

ВВ>и получишь кукишь с маслом вместо значения из функции.

ВВ>Описанный мной алгоритм очень прост — у последнего выражения в блоке можно опустить точку с запятой. А можно и не опускать. Можно дописать еще и пару лишних. Никакой неоднозначности не будет.
ВВ>По-моему запомнить это совсем несложно.

Запомнить несложно. Сложно думать об этом, применять это, когда пишешь бизнес-логику, а не абстрактный код для примеров. Убрал второе выражение из двух в блоке и вроде бы можно убрать ';' вместе с ним. Чем думать об этом — проще всегда ставить ';' там где надо и там где можно без него.

T>>Да, она не боевая. Какая разница? Я просто хотел сказать, что в указанном тобой выражении не вижу конфликтов при таком-то условии (грамматика). А ты, блин, вместо того чтоб показать при каких условиях там таки есть конфликт, ищешь несостоятельность грамматики.


ВВ>Разница большая. Можно придумать грамматику из трех строк, в которой конфликтов не будет. Но в реальной грамматике, где учитываются все операции — конфликты будут. Зачем приводить пример такой игрушечной грамматики без конфликтов? Что он показывает?


Он даёт базу для рассуждений в одной логике. Без него каждый волен мыслить в своей граматике и мы друг друга не поймём. Так и случилось.

T>>У меня не было терма expr expr. Я вообще затрудняюсь придумать что он должен значить.

T>>expr op expr, где op = "" я могу понять. А вот так просто expr expr это какой-то нонсенс.

ВВ>Ну как же, вот он:


ВВ>if → "if" expr expr "else" expr


Терма/продукции expr expr всё ещё нет. Ты выделил *кусок* if.
Re[4]: Про скобочки
От: Gaperton http://gaperton.livejournal.com
Дата: 29.04.10 18:19
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


PD>>>И получился у тебя Паскаль — почти 1:1

G>>У него получился Google Go. Один в один, без почти.

ВВ>В Гоу фигурные скобки обязательны, а круглые — нет. Я фигурные скобки не трогаю, рассматриваю вариант вместо круглых использовать другой токен, вроде 'do' или 'then'. И сдается мне, что на Гоу это похоже слабо.


А ты глянь синтаксис.
http://golang.org/

Мне кажется — очень близко к твоей идее. Я бы сказал, одинакова. И мне очень понравилось — я немного порешал примеров на Го. Хорошая идея.
Re[23]: Про скобочки
От: Воронков Василий Россия  
Дата: 29.04.10 18:29
Оценка:
Здравствуйте, Temoto, Вы писали:

T>Все те же примеры, которые ты приводил про перевод строки.

T>x; -y
T>arr;[index]
T>print; x

Возвращаясь к вопросу об однозначности. Однозначность, понимаешь, такая штука — у нее всегда одно значение Вот у ";" здесь ровно одно значение. Оно всегда одно и то же.
Если вспомнить вариант, который предлагал ты — рассматривать в качестве разделителя выражений пробел. Вот, скажи, подобные конструкции равнозначны:

var x= 2
var x = 2
var x   = 2


Казалось бы, должны, так ведь? А вот подобные уже не равнозначны:

arr[index]
arr [index]


Т.е. в одном случае у нас пробел имеет одно значение, в другом — другое. Однозначности нет. Где-то лишний пробел не играет роли вообще, а где-то приведет к принципиально другой программе.
А вот у точки с запятой семантика одинакова всегда. Поэтому-то решение с пробелами мне и кажется весьма сомнительным.

ВВ>>Эээ, ты издеваешься? Неоднозначность простая. Ты не забыл о чем мы говорили? Как рассматривать выражение:

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

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

ВВ>>Ты предлагал ввести некий анализ, с помощью которого можно определить, что это на самом деле не вычитание x из print, а два выражения.

ВВ>>Так вот — в динамическом языке такой анализ невозможен.
T>Я точно предлагал анализ?

Ты писал, цитирую: "на самом деле визуальную неоднозначность убирает левый операнд. "print — x" уже однозначно понятен только парсеру."
Чтобы "парсер" что-либо понимал, ну, очевидно, анализ какой-то нужен. Конфликт есть? Есть. Надо его как-то разрешать.

T>Если его части полезного значения не возвращают, значит это тут не нужно if-выражение.

T>Как вариант, можно отдельно иметь классический if-statement.

Т.е. обратно вводить в язык разделение на statement/expression? И как будет выглядеть этот if-statement? Если его определение неконфликтно с if-expression, то мы просто получаем две равноценные по смыслу конструкцию.
Не говоря уже о том, что... ну нету просто такого разделения, все есть expression, все возвращает значение. В каких-то случаях возвращаемое значение тебе просто не нужно. Вот и все. В коде вида:

let func(x, y) = 
  {
     var res = x + y;
     ...

     if (check(res))
         cout res
     else
         throw "error";

     if (res > 0)
         res
     else
         magic_const
  }


Первый if выступает в качестве statement, а вот второй — уже в качестве expression, т.к. он становится возвращаемым значением функции func. Придется использовать разный синтаксис для них?

T>Ты смешиваешь тернарный условный оператор (if-else-expression) и if-statement. Они для разных целей используются. Поэтому один выглядит уродливо там, где нужно применить второй. Это нормально.


Еще раз — разделения на statement/expression нет. Да и тернарный оператор тоже по большому счету не нужен. Он остался лишь как наследие из старых времен — да как своего рода сахар.

T>>>>>Я предлагал выделять *блоки стейтментов*. А в 'if-выражении', на мой взгляд, блоки не нужны, там можно ограничиться одним выражением в каждой позиции.

ВВ>>>>А если нужно несколько выражений внутри if?
T>>>Тогда это не выражение. Определи семантику выражения "несколько выражений" пожалуйста. Чему оно равно, как вычислять.

Для определения нескольких выражений используется специальное выражение "блок". Вот как он выглядит:

{
  ...
}


Блок может содержать от нуля до неограниченного кол-ва выражений. Блок сам по себе так же является выражением. Значением, которое возвращает блок, является значение последнего выражения внутри блока. Пустой блок возвращает void.

ВВ>>Все есть выражение. Даже блок {} — это выражение. В языке же нет разделения на стейтменты и экспрешины, поэтому все твои примеры неизбежно надо рассматривать и в роли экспрешинов и в роли стейтментов.

T>Я снова попрошу определить семантику выражения "несколько выражений" или блока. Это кажется чем-то очевидным и естественным, на самом деле возможны разные варианты и когда ты дашь определение, у нас будет общая база.

См. выше. Мне казалось, ты это понимаешь. ОК, будем считать, что терминология не было прояснена.

T> ну если хочешь, наверное, можно так сказать, я не пытался что-то прятать

T>Просто, лично для очевидно, что большой if-else на одной строке хуже, чем на трёх.

Вопрос не о стиле форматирования ("большой if-else"), а о грамматике if-else. Большой на одной строке хуже, маленький хуже на трех — это вопросы стиля. Грамматика может либо позволять записывать if-else в одну строку, либо не позволять.

T>if not foo: continue # это единственный случай, где я сомневаюсь: ставить перевод строки или нет. И когда всё-таки поставлю тоже выглядит нормально.


Потому что ты мыслишь в категориях "есть statements, есть expressions". А если это разделение убирается, то if — это всегда просто тернарный оператор. Всегда. Не более того. Иногда удобнее на нескольких строках, но часто хорошо выглядит и на одной.
Вводить грамматику, согласно которой синтаксис некоторых expression заставляет писать их на разных строках, мне кажется плохой идеей.

T>Неправда твоя, Василий. Может быть, конечно, мы с разными пыхпыхами общались. Я от всех в один голос слышу одни и те же беды про индексацию функции, которая вернула массив, подгрузку нужных классов и пр. Стандартный набор баттхертов.


От кого слышишь? От "рубироидников"? Ты же говорил, что у них все нормально

T>От всех сишников, в один голос: рутина, рутина, нет неймспейсов, рутина, сегфолты, рутина. Действительно, на скобки никто не жалуется.


Странно, я от сишников совсем другие вещи слышу. Впрочем, не суть. Считать решение в другом языке хорошим просто потому что им пользуется много людей — это какой-то неправильный подход. PHP пользуется много людей, как и джава-скриптом — вводим во все языки слабую типизацию?

T>В Flow это лечится ленивостью.


Ну т.е. функцию как значение передать все же можно?

T>Я не выступаю с апологией конкретно этого подхода. Я говорю, что это разумный вариант. Один из многих других вариантов.


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

T>Тип функции без параметров: type.

T>type → void это отображение какого-то типа на одно значение void, то есть функция-константа, которая с любым аргументом возвращает одно значение.

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

T>Избавляемся от void, вводим ключевое слово для редкого случая — вызов нулларной функции.


А чем мешает void? Его наличие необходимо как только снимается разница между expressions и statements. Или опять обратно statements прикручивать?

T>http://s.temoto.ru/flow/spec.rst

T>Здесь есть очень старая версия. Там, может быть, всё ещё есть []. Но вроде бы должны быть примеры других конструкций типа bytes "foo".

Жаль описания самого языка нет, так конечно сложновато понимать, о чем речь.

T>Запомнить несложно. Сложно думать об этом, применять это, когда пишешь бизнес-логику, а не абстрактный код для примеров. Убрал второе выражение из двух в блоке и вроде бы можно убрать ';' вместе с ним. Чем думать об этом — проще всегда ставить ';' там где надо и там где можно без него.


Аналогичная эвристика используется в Немерле. Согласно твоей же логике — много людей, на протяжении лет... — и так далее, и тому подобное.

ВВ>>Разница большая. Можно придумать грамматику из трех строк, в которой конфликтов не будет. Но в реальной грамматике, где учитываются все операции — конфликты будут. Зачем приводить пример такой игрушечной грамматики без конфликтов? Что он показывает?

T>Он даёт базу для рассуждений в одной логике. Без него каждый волен мыслить в своей граматике и мы друг друга не поймём. Так и случилось.

Я не вижу этой базы. Грамматика неполная, фактически попросту неполноценная. Я из нее ничего "вынести" не могу. Если ты хотел показать, что есть грамматики для которых можно в конкретном обсуждаемом случае избежать конфликта, то я и так прекрасно понимаю, что они есть. Более того, я прекрасно понимаю — и делал это в порядке эксперимента, — как я могу модифицировать свою грамматику, чтобы убрать в данном случае конфликты.

ВВ>>if → "if" expr expr "else" expr

T>Терма/продукции expr expr всё ещё нет. Ты выделил *кусок* if.

И что? Какая разница? Два expr идут друг за другом, разделенные пробелом. Что изменится, если их перенести в отдельную продукцию? Ничего. Это та самая ситуация, о которой я говорил — есть два expr, между ними только пробел. В си-подобном синтаксисе такая конструкция невозможна без конфликтов.
Re[5]: Про скобочки
От: Воронков Василий Россия  
Дата: 29.04.10 19:15
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>А ты глянь синтаксис.

G>http://golang.org/

Я смотрел здесь — http://golang.org/doc/go_spec.html#If_statements.
Не скажу, что копал подробно. Но на основе приведенных там продукций/примеров кода складывается ощущение, что синтаксис, скажем так, с хорошим таким багажом наследия от Си (например, есть разделение на statement и expression), но некоторыми небольшими модификациями, например:

ForStmt = "for" [ Condition | ForClause | RangeClause ] Block .


Продукция Block, соответственно, описывается как:

Block = "{" { Statement ";" } "}" .


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

А есть и странные продукции:

IfStmt    = "if" [ SimpleStmt ";" ] [ Expression ] Block [ "else" Statement ] .


Например тут такая запись валидна:

if x {
  y;
}
else 
  z;


Но такая, если верить продукции, нет:

if x
  y;
else 
  z;


Т.е. по-моему очевидно, что фигурные скобочки компенсируют отсутствие круглых.

G>Мне кажется — очень близко к твоей идее. Я бы сказал, одинакова. И мне очень понравилось — я немного порешал примеров на Го. Хорошая идея.


Может, я не увидел в Гоу чего-то, что видишь ты? О какой идее речь? Сократить количество круглых скобочек?
Но там они сокращаются за счет фигурных, я так просто не могу, это будет по меньшей мере уродливо:

var value = if x { y } else { z }


Что-то не то... Я вариант обязательности явного указания блоков не рассматривал.
А вообще примеры, которые я приводил в первом посте, взяты из OCaml.
Re[24]: Про скобочки
От: Temoto  
Дата: 29.04.10 19:31
Оценка:
T>>Все те же примеры, которые ты приводил про перевод строки.
T>>x; -y
T>>arr;[index]
T>>print; x

ВВ>Возвращаясь к вопросу об однозначности. Однозначность, понимаешь, такая штука — у нее всегда одно значение Вот у ";" здесь ровно одно значение. Оно всегда одно и то же.

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

ВВ>
ВВ>var x= 2
ВВ>var x = 2
ВВ>var x   = 2
ВВ>


ВВ>Казалось бы, должны, так ведь? А вот подобные уже не равнозначны:


ВВ>
ВВ>arr[index]
ВВ>arr [index]
ВВ>


ВВ>Т.е. в одном случае у нас пробел имеет одно значение, в другом — другое. Однозначности нет. Где-то лишний пробел не играет роли вообще, а где-то приведет к принципиально другой программе.

ВВ>А вот у точки с запятой семантика одинакова всегда. Поэтому-то решение с пробелами мне и кажется весьма сомнительным.

Согласно каким правилам "var x= 2" и "var x = 2" равнозначны, а "arr[index]" и "arr [index]" ­— нет?

ВВ>>>Эээ, ты издеваешься? Неоднозначность простая. Ты не забыл о чем мы говорили? Как рассматривать выражение:

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

ВВ>Ну мне просто сложно в реале

ВВ>Да и поговорил ты "с бумажкой", а нужная мысль пришла только день спустя. На форуме можешь вернуться к сообщению хоть недельной давности.

Очень странная защита форума. Дела, там, расстояние, это я всё понимаю. Но в реале тоже можно через неделю обсудить новую мысль.

ВВ>>>Ты предлагал ввести некий анализ, с помощью которого можно определить, что это на самом деле не вычитание x из print, а два выражения.

ВВ>>>Так вот — в динамическом языке такой анализ невозможен.
T>>Я точно предлагал анализ?

ВВ>Ты писал, цитирую: "на самом деле визуальную неоднозначность убирает левый операнд. "print — x" уже однозначно понятен только парсеру."

ВВ>Чтобы "парсер" что-либо понимал, ну, очевидно, анализ какой-то нужен. Конфликт есть? Есть. Надо его как-то разрешать.

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

T>>Если его части полезного значения не возвращают, значит это тут не нужно if-выражение.

T>>Как вариант, можно отдельно иметь классический if-statement.

ВВ>Т.е. обратно вводить в язык разделение на statement/expression? И как будет выглядеть этот if-statement? Если его определение неконфликтно с if-expression, то мы просто получаем две равноценные по смыслу конструкцию.

ВВ>Не говоря уже о том, что... ну нету просто такого разделения, все есть expression, все возвращает значение. В каких-то случаях возвращаемое значение тебе просто не нужно. Вот и все. В коде вида:

ВВ>Первый if выступает в качестве statement, а вот второй — уже в качестве expression, т.к. он становится возвращаемым значением функции func. Придется использовать разный синтаксис для них?


T>>Ты смешиваешь тернарный условный оператор (if-else-expression) и if-statement. Они для разных целей используются. Поэтому один выглядит уродливо там, где нужно применить второй. Это нормально.


ВВ>Еще раз — разделения на statement/expression нет. Да и тернарный оператор тоже по большому счету не нужен. Он остался лишь как наследие из старых времен — да как своего рода сахар.


Хакей, разделения нет. Тернарный оператор не нужен. Но if у тебя — выражение. Значит он и есть тернарный оператор. Кроме того, если if — всегда выражение, значит ты обязываешь всегда писать else (потому что иначе у ветки cond == false нет значения. Ну ладно, ты опять скажешь что значение будет вездессущий null, это мы уже обсуждали.

Тогда then — самый читаемый и консистентный вариант, раз ты в такие рамки ставишь.

T>>>>>>Я предлагал выделять *блоки стейтментов*. А в 'if-выражении', на мой взгляд, блоки не нужны, там можно ограничиться одним выражением в каждой позиции.

ВВ>>>>>А если нужно несколько выражений внутри if?
T>>>>Тогда это не выражение. Определи семантику выражения "несколько выражений" пожалуйста. Чему оно равно, как вычислять.

ВВ>Для определения нескольких выражений используется специальное выражение "блок". Вот как он выглядит:


ВВ>Блок может содержать от нуля до неограниченного кол-ва выражений. Блок сам по себе так же является выражением. Значением, которое возвращает блок, является значение последнего выражения внутри блока. Пустой блок возвращает void.


Хакей, блоки как в эрланге. Кстати я для Flow тоже думал о такой конструкции, типа do { expr; expr; } которая 1) форсирует вычисление каждого выражения, 2) вычисляет их принудительно последовательно, 3) возвращает значение последнего выражения, 4) пустой do {} это ошибка (ну это и правда нонсенс).

void вроде бы только для вызова нулларных функций был? Впрочем, это неважно.

Опять, таки. Всё что я говорил про фигурные скобки к твоему if-expression не применимо, потому что я рассуждал в базисе if-statement и тернарного-if-выражения отдельно.

В жестком императивном си-подобном я бы хотел видеть такой if-statement:

if cond { // перевод строки обязателен. Почему скобки. Потому что там может быть несколько стейтментов.
st1
} [ else {
st2
} ]

В функциональном я бы хотел видеть такой if-expression:

name = expr1 if cond else expr2

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

Как теперь наложить сюда твоё блочное выражение. Наверное, вот так:

name = if cond then expr1 else expr2

но

if cond then {
action1;
action2;
}

То есть, переходить на стиль Go, когда результат if-выражения не используется.

То есть, к твоему изначальному вопросу, ответ, наверное, будет такой: можно без проблем убрать всякие скобки из си-подобного синтаксиса. Убрать всякие скобки из конкретно твоего языка, с конкретно твоими прочими условиями без проблем не получится.

T>> ну если хочешь, наверное, можно так сказать, я не пытался что-то прятать

T>>Просто, лично для очевидно, что большой if-else на одной строке хуже, чем на трёх.

ВВ>Вопрос не о стиле форматирования ("большой if-else"), а о грамматике if-else. Большой на одной строке хуже, маленький хуже на трех — это вопросы стиля. Грамматика может либо позволять записывать if-else в одну строку, либо не позволять.


T>>if not foo: continue # это единственный случай, где я сомневаюсь: ставить перевод строки или нет. И когда всё-таки поставлю тоже выглядит нормально.


ВВ>Потому что ты мыслишь в категориях "есть statements, есть expressions". А если это разделение убирается, то if — это всегда просто тернарный оператор. Всегда. Не более того. Иногда удобнее на нескольких строках, но часто хорошо выглядит и на одной.

ВВ>Вводить грамматику, согласно которой синтаксис некоторых expression заставляет писать их на разных строках, мне кажется плохой идеей.

Если это разделение убирается, то

expr1; // потеряли одно значение
if cond then expr2; // потеряли второе значение. Не знаем чему равен if, если cond false
cond3; // и вот это будет результатом блока

от такого кода у меня кипит мозг. Нафиг было всё делать выражениями, если этот факт будет редко использоваться.

T>>Неправда твоя, Василий. Может быть, конечно, мы с разными пыхпыхами общались. Я от всех в один голос слышу одни и те же беды про индексацию функции, которая вернула массив, подгрузку нужных классов и пр. Стандартный набор баттхертов.


ВВ>От кого слышишь? От "рубироидников"? Ты же говорил, что у них все нормально


*С тем что нельзя передать метод, а не результат его вычисления* у них все нормально.

T>>От всех сишников, в один голос: рутина, рутина, нет неймспейсов, рутина, сегфолты, рутина. Действительно, на скобки никто не жалуется.


ВВ>Странно, я от сишников совсем другие вещи слышу. Впрочем, не суть. Считать решение в другом языке хорошим просто потому что им пользуется много людей — это какой-то неправильный подход. PHP пользуется много людей, как и джава-скриптом — вводим во все языки слабую типизацию?


Не потому что много людей пользуется, а потому что это не доставляет проблем. Много людей это всего-лишь подкрепление к аргументу. Насчёт слабой типизации у меня статистики нет, но я считаю, что это именно доставляет проблем.

T>>В Flow это лечится ленивостью.


ВВ>Ну т.е. функцию как значение передать все же можно?


Нет "функции как значения", потому что функция и результат её вычисления не разделены.

f = "Hello world"
print f

Ты можешь сказать, что в print передаётся функция. Ты можешь сказать, что в f передаётся результат вычисления функции. Ты будешь прав *в обоих* случаях.

T>>Я не выступаю с апологией конкретно этого подхода. Я говорю, что это разумный вариант. Один из многих других вариантов.


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


Если вызов функций это один конкретный случай, то так, да.
И если это не создаёт проблем, то вот она и разумность. Возможности урезаны, проблем нет, профит есть.

T>>Тип функции без параметров: type.

T>>type → void это отображение какого-то типа на одно значение void, то есть функция-константа, которая с любым аргументом возвращает одно значение.

ВВ>Вообще-то это нотация, через которую описывается функциональный тип в том же хаскеле. И тип функции без параметров не может быть просто type, в противном случае непонятно, как записывается тип для type.


Именно в той самой нотации я тебе и сказал. Если хочешь — попроси матёрых штангистов подтвердить или опровергнуть.

аргумент → аргумент → результат.

Что такое "тип для type"?

T>>Избавляемся от void, вводим ключевое слово для редкого случая — вызов нулларной функции.


ВВ>А чем мешает void? Его наличие необходимо как только снимается разница между expressions и statements. Или опять обратно statements прикручивать?


Ещё одна сущность.

T>>http://s.temoto.ru/flow/spec.rst

T>>Здесь есть очень старая версия. Там, может быть, всё ещё есть []. Но вроде бы должны быть примеры других конструкций типа bytes "foo".

ВВ>Жаль описания самого языка нет, так конечно сложновато понимать, о чем речь.


Да, косяк, я им не занимался давно. Увышка. В какой-то момент у меня было ощущение, что те недостатки хаскеля, которые я пытаюсь побороть — меньшее зло, чем громадная работа, которую предстоит сделать для реализации компилятора.

T>>Запомнить несложно. Сложно думать об этом, применять это, когда пишешь бизнес-логику, а не абстрактный код для примеров. Убрал второе выражение из двух в блоке и вроде бы можно убрать ';' вместе с ним. Чем думать об этом — проще всегда ставить ';' там где надо и там где можно без него.


ВВ>Аналогичная эвристика используется в Немерле. Согласно твоей же логике — много людей, на протяжении лет... — и так далее, и тому подобное.


Немерле не пользуется много людей на протяжении лет, ты чего. Я другие масштабы имею в виду.

ВВ>>>if → "if" expr expr "else" expr

T>>Терма/продукции expr expr всё ещё нет. Ты выделил *кусок* if.

ВВ>И что? Какая разница? Два expr идут друг за другом, разделенные пробелом. Что изменится, если их перенести в отдельную продукцию? Ничего. Это та самая ситуация, о которой я говорил — есть два expr, между ними только пробел. В си-подобном синтаксисе такая конструкция невозможна без конфликтов.


Ну какие конфликты-то? Приведи пример с разными разборами одной строки.
Re[25]: Про скобочки
От: Воронков Василий Россия  
Дата: 29.04.10 19:53
Оценка:
Здравствуйте, Temoto, Вы писали:

T>Согласно каким правилам "var x= 2" и "var x = 2" равнозначны, а "arr[index]" и "arr [index]" ­— нет?


Ну я у тебя спрашиваю. Они равнозначны или нет? Или же "var x= 2" и "var x = 2" — это разный код? И какой тогда правильный? В первом случае будет ошибка? Или что будет?

T>Ну я имел в виду, что парсеру/компилятору/неважно-чему понятно, что здесь ошибка: инфиксный минус к нечисловым аргументам. Конфликта, в смысле неоднозначности, — нет.


При динамической типизации будет понятно, что это "нечисловой аргумент" только в самый момент исполнения операции минус. Понимаешь? Вот у нас код стек-машины:

Push print
Push x
Min

И вот когда выполняется min, нам сделать некую проверку, определить, что print особого типа и начать выполнять совсем не тот код, который был сгенерирован компилятором. Ну т.е. это вообще практически нереальный сценарий.

T>Хакей, разделения нет. Тернарный оператор не нужен. Но if у тебя — выражение. Значит он и есть тернарный оператор. Кроме того, если if — всегда выражение, значит ты обязываешь всегда писать else (потому что иначе у ветки cond == false нет значения. Ну ладно, ты опять скажешь что значение будет вездессущий null, это мы уже обсуждали.


Вообще я сделал выводы из тех обсуждений "вездессущий null" отсутствует. Вместо него — void. А это подход, который проповедуется большинством функциональных языков, только там void часто называется unit. Блок else — обязательный.

T>Тогда then — самый читаемый и консистентный вариант, раз ты в такие рамки ставишь.


Эта мысль приходила мне в голову. Собственно, причина поднятия этой темы... Мне нравится код вида:

var x = if cond then y else z

if cond then
  y
else
  x


А вот так — уже не особо:

if cond then {
  ...
  y
}
else
  x


T>>>>>>>Я предлагал выделять *блоки стейтментов*. А в 'if-выражении', на мой взгляд, блоки не нужны, там можно ограничиться одним выражением в каждой позиции.

ВВ>>>>>>А если нужно несколько выражений внутри if?
T>>>>>Тогда это не выражение. Определи семантику выражения "несколько выражений" пожалуйста. Чему оно равно, как вычислять.

ВВ>>Для определения нескольких выражений используется специальное выражение "блок". Вот как он выглядит:


ВВ>>Блок может содержать от нуля до неограниченного кол-ва выражений. Блок сам по себе так же является выражением. Значением, которое возвращает блок, является значение последнего выражения внутри блока. Пустой блок возвращает void.


T>Хакей, блоки как в эрланге. Кстати я для Flow тоже думал о такой конструкции, типа do { expr; expr; } которая 1) форсирует вычисление каждого выражения, 2) вычисляет их принудительно последовательно, 3) возвращает значение последнего выражения, 4) пустой do {} это ошибка (ну это и правда нонсенс).


То, что ты описываешь — это скорее этакая do-нотация для энергичного вычисления выражений с побочными эффектами. Она имеет смысл при ленивости всего остального и чистоте языка. У меня блок это просто блок, он не гарантирует последовательности. Внутри него могут быть и ленивые выражения.

T>void вроде бы только для вызова нулларных функций был? Впрочем, это неважно.


Нет, не только. void — это то, что возвращают некоторые выражения. Например:

var x = for (...) ...


Значение x будет void.

T>Опять, таки. Всё что я говорил про фигурные скобки к твоему if-expression не применимо, потому что я рассуждал в базисе if-statement и тернарного-if-выражения отдельно.


Вот в том-то и дело. Уже не жесткий, не императивный, да и Си-подобность на уровне скобочек и точек с запятой только.

T>В функциональном я бы хотел видеть такой if-expression:

T>name = expr1 if cond else expr2
T>Почему здесь скобок нет — потому что несколько быть не может, там одно везде выражение.

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

T>То есть, к твоему изначальному вопросу, ответ, наверное, будет такой: можно без проблем убрать всякие скобки из си-подобного синтаксиса. Убрать всякие скобки из конкретно твоего языка, с конкретно твоими прочими условиями без проблем не получится.


Видимо, это и есть "правильный ответ". Я и сам это в принципе уже понял.

T>Если это разделение убирается, то

T>expr1; // потеряли одно значение
T>if cond then expr2; // потеряли второе значение. Не знаем чему равен if, если cond false
T>cond3; // и вот это будет результатом блока
T>от такого кода у меня кипит мозг. Нафиг было всё делать выражениями, если этот факт будет редко использоваться.

Отчего же редко? Этот факт по-моему используется постоянно. Насколько я могу судить по аналогичным языка по крайней мере.
Ты просто в качестве примера взял нотацию для if из питона, которая лично мне не очень, честно говоря, и пытаешься на ее основе показать, как это плохо, когда все есть экспрешин.

T>>>Неправда твоя, Василий. Может быть, конечно, мы с разными пыхпыхами общались. Я от всех в один голос слышу одни и те же беды про индексацию функции, которая вернула массив, подгрузку нужных классов и пр. Стандартный набор баттхертов.


ВВ>>От кого слышишь? От "рубироидников"? Ты же говорил, что у них все нормально


T>*С тем что нельзя передать метод, а не результат его вычисления* у них все нормально.


T>>>От всех сишников, в один голос: рутина, рутина, нет неймспейсов, рутина, сегфолты, рутина. Действительно, на скобки никто не жалуется.


ВВ>>Странно, я от сишников совсем другие вещи слышу. Впрочем, не суть. Считать решение в другом языке хорошим просто потому что им пользуется много людей — это какой-то неправильный подход. PHP пользуется много людей, как и джава-скриптом — вводим во все языки слабую типизацию?


T>Не потому что много людей пользуется, а потому что это не доставляет проблем. Много людей это всего-лишь подкрепление к аргументу. Насчёт слабой типизации у меня статистики нет, но я считаю, что это именно доставляет проблем.


T>>>В Flow это лечится ленивостью.

ВВ>>Ну т.е. функцию как значение передать все же можно?
T>Нет "функции как значения", потому что функция и результат её вычисления не разделены.
T>f = "Hello world"
T>print f
T>Ты можешь сказать, что в print передаётся функция. Ты можешь сказать, что в f передаётся результат вычисления функции. Ты будешь прав *в обоих* случаях.

Ну это в случае функции без параметров. А как быть если функция принимает параметры? тут уже без разделения не обойдешься.

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

T>Если вызов функций это один конкретный случай, то так, да.
T>И если это не создаёт проблем, то вот она и разумность. Возможности урезаны, проблем нет, профит есть.

Ну у меня это создает просто катастрофические проблемы, весь язык построен на call by value.

T>Именно в той самой нотации я тебе и сказал. Если хочешь — попроси матёрых штангистов подтвердить или опровергнуть.

T>аргумент → аргумент → результат.
T>Что такое "тип для type"?

А что такое "просто type" для описания функционального типа?

T>>>Избавляемся от void, вводим ключевое слово для редкого случая — вызов нулларной функции.

ВВ>>А чем мешает void? Его наличие необходимо как только снимается разница между expressions и statements. Или опять обратно statements прикручивать?
T>Ещё одна сущность.

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

T>Да, косяк, я им не занимался давно. Увышка. В какой-то момент у меня было ощущение, что те недостатки хаскеля, которые я пытаюсь побороть — меньшее зло, чем громадная работа, которую предстоит сделать для реализации компилятора.


А можно пример таких недостатков?

ВВ>>И что? Какая разница? Два expr идут друг за другом, разделенные пробелом. Что изменится, если их перенести в отдельную продукцию? Ничего. Это та самая ситуация, о которой я говорил — есть два expr, между ними только пробел. В си-подобном синтаксисе такая конструкция невозможна без конфликтов.

T>Ну какие конфликты-то? Приведи пример с разными разборами одной строки.

Я же писал до этого, что если разделители между Expr — просто пробел, то при сохранении си-подобного синтаксиса будут конфликты. С теми же унарными операторами и проч.
Re[26]: Про скобочки
От: Temoto  
Дата: 29.04.10 21:01
Оценка:
T>>Согласно каким правилам "var x= 2" и "var x = 2" равнозначны, а "arr[index]" и "arr [index]" ­— нет?

ВВ>Ну я у тебя спрашиваю. Они равнозначны или нет? Или же "var x= 2" и "var x = 2" — это разный код? И какой тогда правильный? В первом случае будет ошибка? Или что будет?


Опять же, согласно каким правилам?

T>>Ну я имел в виду, что парсеру/компилятору/неважно-чему понятно, что здесь ошибка: инфиксный минус к нечисловым аргументам. Конфликта, в смысле неоднозначности, — нет.


ВВ>При динамической типизации будет понятно, что это "нечисловой аргумент" только в самый момент исполнения операции минус. Понимаешь? Вот у нас код стек-машины:


ВВ>Push print

ВВ>Push x
ВВ>Min

ВВ>И вот когда выполняется min, нам сделать некую проверку, определить, что print особого типа и начать выполнять совсем не тот код, который был сгенерирован компилятором. Ну т.е. это вообще практически нереальный сценарий.


Да, Min должен проверить типы аргументов и кинуть TypeError.

T>>Хакей, разделения нет. Тернарный оператор не нужен. Но if у тебя — выражение. Значит он и есть тернарный оператор. Кроме того, если if — всегда выражение, значит ты обязываешь всегда писать else (потому что иначе у ветки cond == false нет значения. Ну ладно, ты опять скажешь что значение будет вездессущий null, это мы уже обсуждали.


ВВ>Вообще я сделал выводы из тех обсуждений "вездессущий null" отсутствует. Вместо него — void. А это подход, который проповедуется большинством функциональных языков, только там void часто называется unit. Блок else — обязательный.


Не понял какие выводы. null переименовал в void?
И "большинство ф-х языков" это сколько/какие?

T>>Тогда then — самый читаемый и консистентный вариант, раз ты в такие рамки ставишь.


ВВ>Эта мысль приходила мне в голову. Собственно, причина поднятия этой темы... Мне нравится код вида:


ВВ>А вот так — уже не особо:


ВВ>
ВВ>if cond then {
ВВ>  ...
ВВ>  y
ВВ>}
ВВ>else
ВВ>  x
ВВ>


Да забей, всё нормально. Это цена скобок вместо отступов и ничего отдельно некрасивого в этом нет.

ВВ>>>Для определения нескольких выражений используется специальное выражение "блок". Вот как он выглядит:


ВВ>>>Блок может содержать от нуля до неограниченного кол-ва выражений. Блок сам по себе так же является выражением. Значением, которое возвращает блок, является значение последнего выражения внутри блока. Пустой блок возвращает void.


T>>Хакей, блоки как в эрланге. Кстати я для Flow тоже думал о такой конструкции, типа do { expr; expr; } которая 1) форсирует вычисление каждого выражения, 2) вычисляет их принудительно последовательно, 3) возвращает значение последнего выражения, 4) пустой do {} это ошибка (ну это и правда нонсенс).


ВВ>То, что ты описываешь — это скорее этакая do-нотация для энергичного вычисления выражений с побочными эффектами. Она имеет смысл при ленивости всего остального и чистоте языка. У меня блок это просто блок, он не гарантирует последовательности. Внутри него могут быть и ленивые выражения.


У тебя { expr1; expr2; expr3 } не гарантирует последовательности? Последовательность и ленивость ортогональны, кстати.

T>>В функциональном я бы хотел видеть такой if-expression:

T>>name = expr1 if cond else expr2
T>>Почему здесь скобок нет — потому что несколько быть не может, там одно везде выражение.

ВВ>Я не понимаю, откуда берется это ограничение — только одно выражение, а потому и скобок не надо.


Круглых? Мусор.
Фигурных? Окружать одно выражение фигурными скобками — тоже мусор.
Почему одно выражение? Такая грамматика. Даже если там блок, это всё равно одно выражение ведь.

T>>Если это разделение убирается, то

T>>expr1; // потеряли одно значение
T>>if cond then expr2; // потеряли второе значение. Не знаем чему равен if, если cond false
T>>cond3; // и вот это будет результатом блока
T>>от такого кода у меня кипит мозг. Нафиг было всё делать выражениями, если этот факт будет редко использоваться.

ВВ>Отчего же редко? Этот факт по-моему используется постоянно. Насколько я могу судить по аналогичным языка по крайней мере.

ВВ>Ты просто в качестве примера взял нотацию для if из питона, которая лично мне не очень, честно говоря, и пытаешься на ее основе показать, как это плохо, когда все есть экспрешин.

(питона там не было)
Покажи любую функцию размером больше 150 символов из своей стандартной библиотеки.

T>>>>В Flow это лечится ленивостью.

ВВ>>>Ну т.е. функцию как значение передать все же можно?
T>>Нет "функции как значения", потому что функция и результат её вычисления не разделены.
T>>f = "Hello world"
T>>print f
T>>Ты можешь сказать, что в print передаётся функция. Ты можешь сказать, что в f передаётся результат вычисления функции. Ты будешь прав *в обоих* случаях.

ВВ>Ну это в случае функции без параметров. А как быть если функция принимает параметры? тут уже без разделения не обойдешься.


Т.е. нужно передать функцию, которая принимает аргумент?

f _ = "Hello world"
print f

Ты можешь сказать, что в print передаётся функция f, ты можешь сказать, что в print передаётся результат вычисления функции f. Ты будешь прав в обоих случаях.

Потому что результат вычисления функции f это нулларная функция, возвращающая "Hello world". Маниакальное каррирование даже там, где не просят. Это затрудняет создание функций с произвольным количеством аргументов. Я думал над этим и не придумал хорошего решения.

T>>Именно в той самой нотации я тебе и сказал. Если хочешь — попроси матёрых штангистов подтвердить или опровергнуть.

T>>аргумент → аргумент → результат.
T>>Что такое "тип для type"?

ВВ>А что такое "просто type" для описания функционального типа?


Я не понял вопроса. Но вот этот тип

x :: String

описывает функцию с именем "x" с 0 аргументов, которая возвращает строку.
Функциональным, обычно, называют тип a → b. Даже если b при этом сам является c → d. Оператор → правоассоциативен, как минус.

T>>>>Избавляемся от void, вводим ключевое слово для редкого случая — вызов нулларной функции.

ВВ>>>А чем мешает void? Его наличие необходимо как только снимается разница между expressions и statements. Или опять обратно statements прикручивать?
T>>Ещё одна сущность.

ВВ>Мне казалось, что тебе уж ее наличие должно показаться вполне логичным. Не говоря уж о том, что от разделения на expression и statements без нее не избавиться.


Если всё стало выражением, это значит только то, что ты теперь получил кучу гемора с определением какой же результат должен быть у всего.
Например, "for" ты потерял, потому что у него результата нет. Сказать на всё, что раньше было стейтментом, что у него результат — специальное значение void, это и есть создать именно лишнюю сущность, закрыть глаза на проблему выражений, создать костыль.

T>>Да, косяк, я им не занимался давно. Увышка. В какой-то момент у меня было ощущение, что те недостатки хаскеля, которые я пытаюсь побороть — меньшее зло, чем громадная работа, которую предстоит сделать для реализации компилятора.


ВВ>А можно пример таких недостатков?


— Эта идиотская идея, что типы документируют код. Это работает только в примитивных случаях, где и документировать нечего.
— Обязательная ленивость. Иногда всё-таки хочется взять на себя ответственность и указать порядок.
— Вся стандартная библиотека завязана на один конкретный тип последовательности: односвязанный список (который имеет конструктор ':'). Как следствие, для Array, Set, Map и пр. — свои, отдельные операции. Например, map/filter/fold работают *только с []*.
— Самая странная, убогая реализация туплов в мире. Это 64 строки типа http://google.com/codesearch/p?hl=en#5KTrgOW2hXs/pub/nslu2/sources/hugs98-Nov2003.tar.gz|cVG3t241wQU/hugs98-Nov2003/fptools/libraries/base/Data/Tuple.hs&q=%22%28,,%29%20a%20b%20c%22&l=71
— main имеет "грязный" тип IO. То есть на хаскеле нельзя писать чистые программы, только чистые функции.

Вот мнение матёрого штангиста на эту тему.
http://thesz.livejournal.com/1010226.html

ВВ>>>И что? Какая разница? Два expr идут друг за другом, разделенные пробелом. Что изменится, если их перенести в отдельную продукцию? Ничего. Это та самая ситуация, о которой я говорил — есть два expr, между ними только пробел. В си-подобном синтаксисе такая конструкция невозможна без конфликтов.

T>>Ну какие конфликты-то? Приведи пример с разными разборами одной строки.

ВВ>Я же писал до этого, что если разделители между Expr — просто пробел, то при сохранении си-подобного синтаксиса будут конфликты. С теми же унарными операторами и проч.


Понял теперь наконец-то.

if y -x else x

Да, тут засада.
Re[27]: Про скобочки
От: Воронков Василий Россия  
Дата: 29.04.10 21:21
Оценка:
Здравствуйте, Temoto, Вы писали:

T>>>Согласно каким правилам "var x= 2" и "var x = 2" равнозначны, а "arr[index]" и "arr [index]" ­— нет?

ВВ>>Ну я у тебя спрашиваю. Они равнозначны или нет? Или же "var x= 2" и "var x = 2" — это разный код? И какой тогда правильный? В первом случае будет ошибка? Или что будет?
T>Опять же, согласно каким правилам?

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

ВВ>>И вот когда выполняется min, нам сделать некую проверку, определить, что print особого типа и начать выполнять совсем не тот код, который был сгенерирован компилятором. Ну т.е. это вообще практически нереальный сценарий.

T>Да, Min должен проверить типы аргументов и кинуть TypeError.

Ты опять нить потерял. Речь была о том, чтобы суметь определить, что print — x это на самом деле не бинарная операция, а две операции: 1) вызов функции 3) negate x
TypeError и так будет.
А вот определить, что это две операции можно уже только при выполнении Min. Короче, это вообще какой-то бредовый вариант.

T>>>Хакей, разделения нет. Тернарный оператор не нужен. Но if у тебя — выражение. Значит он и есть тернарный оператор. Кроме того, если if — всегда выражение, значит ты обязываешь всегда писать else (потому что иначе у ветки cond == false нет значения. Ну ладно, ты опять скажешь что значение будет вездессущий null, это мы уже обсуждали.


ВВ>>Вообще я сделал выводы из тех обсуждений "вездессущий null" отсутствует. Вместо него — void. А это подход, который проповедуется большинством функциональных языков, только там void часто называется unit. Блок else — обязательный.


T>Не понял какие выводы. null переименовал в void?


null это не void

T>И "большинство ф-х языков" это сколько/какие?


Все языки семейства ML тебя устроят? Scala? Haskell? Nemerle?

ВВ>>То, что ты описываешь — это скорее этакая do-нотация для энергичного вычисления выражений с побочными эффектами. Она имеет смысл при ленивости всего остального и чистоте языка. У меня блок это просто блок, он не гарантирует последовательности. Внутри него могут быть и ленивые выражения.

T>У тебя { expr1; expr2; expr3 } не гарантирует последовательности? Последовательность и ленивость ортогональны, кстати.

Не гарантирует последовательности *исполнения*. Да, такой не гарантирует. Это тебе не монада.

T>(питона там не было)

T>Покажи любую функцию размером больше 150 символов из своей стандартной библиотеки.

А что ты конкретно хочешь увидеть? Стандартная библиотека еще не написана. Есть код для тестов.

T>f _ = "Hello world"

T>print f
T>Ты можешь сказать, что в print передаётся функция f, ты можешь сказать, что в print передаётся результат вычисления функции f. Ты будешь прав в обоих случаях.
T>Потому что результат вычисления функции f это нулларная функция, возвращающая "Hello world". Маниакальное каррирование даже там, где не просят. Это затрудняет создание функций с произвольным количеством аргументов. Я думал над этим и не придумал хорошего решения.

Ничего не понял. Как мне описать функцию, которая принимает один аргумент и совершает операцию над этим аргументом?

T>Я не понял вопроса. Но вот этот тип

T>x :: String
T>описывает функцию с именем "x" с 0 аргументов, которая возвращает строку.
T>Функциональным, обычно, называют тип a → b. Даже если b при этом сам является c → d. Оператор → правоассоциативен, как минус.

Опять ничего не понял. Функциональный тип у которого 0 аргументов?

T>Если всё стало выражением, это значит только то, что ты теперь получил кучу гемора с определением какой же результат должен быть у всего.

T>Например, "for" ты потерял, потому что у него результата нет. Сказать на всё, что раньше было стейтментом, что у него результат — специальное значение void, это и есть создать именно лишнюю сущность, закрыть глаза на проблему выражений, создать костыль.

Сохранение этого разделения представляет собой костыль куда больший. Оно в сущности означает, что для написания кода тебе по-прежнему придется использовать типичные конструкции императивного flow control — return и прочая.
К тому же я тут ровным счетом ничего не изобрел.
Re[27]: Про скобочки
От: Воронков Василий Россия  
Дата: 29.04.10 22:03
Оценка:
Здравствуйте, Temoto, Вы писали:

T>- Эта идиотская идея, что типы документируют код. Это работает только в примитивных случаях, где и документировать нечего.

T>- Обязательная ленивость. Иногда всё-таки хочется взять на себя ответственность и указать порядок.
T>- Вся стандартная библиотека завязана на один конкретный тип последовательности: односвязанный список (который имеет конструктор ':'). Как следствие, для Array, Set, Map и пр. — свои, отдельные операции. Например, map/filter/fold работают *только с []*.
T>- Самая странная, убогая реализация туплов в мире. Это 64 строки типа http://google.com/codesearch/p?hl=en#5KTrgOW2hXs/pub/nslu2/sources/hugs98-Nov2003.tar.gz|cVG3t241wQU/hugs98-Nov2003/fptools/libraries/base/Data/Tuple.hs&q=%22%28,,%29%20a%20b%20c%22&l=71
T>- main имеет "грязный" тип IO. То есть на хаскеле нельзя писать чистые программы, только чистые функции.

Кстати, а на чем ты собираешься все это писать? И во что компилировать?
Re[6]: Про скобочки
От: Gaperton http://gaperton.livejournal.com
Дата: 29.04.10 22:04
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Может, я не увидел в Гоу чего-то, что видишь ты? О какой идее речь? Сократить количество круглых скобочек?

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

Не, все правильно ты показываешь. Речь об идее избавления от круглых скобок. И не уродливо это — ты попиши примеры. Очень быстро привыкаешь, и начнет бесить обратно сишная традиция.

Можно избавиться и от фигурных скобок, введя двумерный синтаксис. Было бы желание.
Re[7]: Про скобочки
От: Воронков Василий Россия  
Дата: 29.04.10 22:14
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Не, все правильно ты показываешь. Речь об идее избавления от круглых скобок. И не уродливо это — ты попиши примеры. Очень быстро привыкаешь, и начнет бесить обратно сишная традиция.


В самом Go это не уродство, я такого не говорил. Это некрасиво в языке, где нет разделения на statement и expression — и, соответственно, все является expression. Поэтому любая конструкция, тот же if, может стоять справа от "=". И вот при таком подходе мне обязательные фигурные скобки кажутся странными.

А вообще синтаксис Go хорош тем, что из Сишного просто вытрясли весь мусор. Т.е. как не напишешь любую из конструкций Go, в ней не будет лишних токенов. Но сделано это ИМХО ценой неочевидности некоторых конструкций. Например, после if фигурные скобки обязательны, а после else — нет.

G>Можно избавиться и от фигурных скобок, введя двумерный синтаксис. Было бы желание.


Что такое двумерный синтаксис? Можно поподробнее?
Re[18]: Про скобочки
От: night beast СССР  
Дата: 30.04.10 05:35
Оценка: +1
ВВ>; на каждой строке плохо, но с ним можно бороться. Есть два варианта.

ВВ>1. (то, что реализовано) Точка с запятой является необязательной в том случае, если выражение является последним в блоке или же если оно следует сразу после выражением, которое заканчивается на }


ВВ>2. Убрать точку с запятой на фиг вообще. Ввести такой принцип — перед всеми "простыми" выражениями (т.е. теми, которые в обычных языках только и считаются за выражения) писать специальное ключевое слово. Например, do.

ВВ>Говоря другими словами, у нас теперь все конструкции языка начинаются с ключевого слова. Вуаля, конфликтов нет. Ну делаем поблажку на то, что если у нас выражение одно-единственное в блоке, то do можно не писать:

Извини что встреваю в беседу
Можешь пояснить, чем точка с запятой в конце конце каждого выражения не устраивает?
Re[19]: Про скобочки
От: Undying Россия  
Дата: 30.04.10 06:44
Оценка:
Здравствуйте, night beast, Вы писали:

NB>Извини что встреваю в беседу

NB>Можешь пояснить, чем точка с запятой в конце конце каждого выражения не устраивает?

Видать лаконично больно, хочется по больше символов писать. Я вот тоже хочу предложить в русском языке точку отменить, а вместо нее каждое предложение начинать с префикса НОВОЕ, это ж как бы читабельность текста повысило.
Re[19]: Про скобочки
От: Воронков Василий Россия  
Дата: 30.04.10 09:34
Оценка:
Здравствуйте, night beast, Вы писали:

NB>Извини что встреваю в беседу

NB>Можешь пояснить, чем точка с запятой в конце конце каждого выражения не устраивает?

Ну речь в общем о том, что убрать из синтаксиса мусор — а во многих случаях и так видно, что у тебя разные выражения, зачем еще точки с запятой?
А вообще тут дополнительные сложности как бы создает тот факт, что разделения на expression и statement нет, поэтому такой код валиден:

var x = if (cond)
           firstAction()
        else
           secondAction();


Вот скажи, ты бы хотел его записывать так:

var x = if (cond)
           firstAction();
        else
           secondAction();;
Re[20]: Про скобочки
От: Воронков Василий Россия  
Дата: 30.04.10 09:36
Оценка:
Здравствуйте, Undying, Вы писали:

U>Видать лаконично больно, хочется по больше символов писать. Я вот тоже хочу предложить в русском языке точку отменить, а вместо нее каждое предложение начинать с префикса НОВОЕ, это ж как бы читабельность текста повысило.


Ага, только "символов" на самом деле будет гораздо меньше.
Re[28]: Про скобочки
От: Temoto  
Дата: 30.04.10 10:33
Оценка:
T>>>>Согласно каким правилам "var x= 2" и "var x = 2" равнозначны, а "arr[index]" и "arr [index]" ­— нет?
ВВ>>>Ну я у тебя спрашиваю. Они равнозначны или нет? Или же "var x= 2" и "var x = 2" — это разный код? И какой тогда правильный? В первом случае будет ошибка? Или что будет?
T>>Опять же, согласно каким правилам?

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

ВВ>Вот я и спрашиваю, как этот пробел будет работать в остальных случаях.

Хакей, у меня такой вариант: x= 2 это ошибка, вокруг операторов (кроме '.') должен быть пробел.

ВВ>>>И вот когда выполняется min, нам сделать некую проверку, определить, что print особого типа и начать выполнять совсем не тот код, который был сгенерирован компилятором. Ну т.е. это вообще практически нереальный сценарий.

T>>Да, Min должен проверить типы аргументов и кинуть TypeError.

ВВ>Ты опять нить потерял. Речь была о том, чтобы суметь определить, что print — x это на самом деле не бинарная операция, а две операции: 1) вызов функции 3) negate x

ВВ>TypeError и так будет.
ВВ>А вот определить, что это две операции можно уже только при выполнении Min. Короче, это вообще какой-то бредовый вариант.

Да, точно, потерял.
Так вот, парсер запишет "print — x" как бинарный минус и будет ошибка, в то время как пользователь хотел "print -x". Ну да, обнаружится во время исполнения. Как и все остальные ошибки в динамическом языке.

ВВ>>>Вообще я сделал выводы из тех обсуждений "вездессущий null" отсутствует. Вместо него — void. А это подход, который проповедуется большинством функциональных языков, только там void часто называется unit. Блок else — обязательный.

T>>Не понял какие выводы. null переименовал в void?
ВВ>null это не void

Какие выводы?

T>>И "большинство ф-х языков" это сколько/какие?


ВВ>Все языки семейства ML тебя устроят? Scala? Haskell? Nemerle?


В хаскеле точно нет ни void, ни unit.

ВВ>>>То, что ты описываешь — это скорее этакая do-нотация для энергичного вычисления выражений с побочными эффектами. Она имеет смысл при ленивости всего остального и чистоте языка. У меня блок это просто блок, он не гарантирует последовательности. Внутри него могут быть и ленивые выражения.

T>>У тебя { expr1; expr2; expr3 } не гарантирует последовательности? Последовательность и ленивость ортогональны, кстати.

ВВ>Не гарантирует последовательности *исполнения*. Да, такой не гарантирует. Это тебе не монада.


Круто.
(монада в общем смысле тоже не гарантирует кстати. Только IO)

T>>(питона там не было)

T>>Покажи любую функцию размером больше 150 символов из своей стандартной библиотеки.

ВВ>А что ты конкретно хочешь увидеть? Стандартная библиотека еще не написана. Есть код для тестов.


Я хочу увидеть (и показать) как (в худшем случае) N-1 выражений в каждом блоке не используются.

T>>f _ = "Hello world"

T>>print f
T>>Ты можешь сказать, что в print передаётся функция f, ты можешь сказать, что в print передаётся результат вычисления функции f. Ты будешь прав в обоих случаях.
T>>Потому что результат вычисления функции f это нулларная функция, возвращающая "Hello world". Маниакальное каррирование даже там, где не просят. Это затрудняет создание функций с произвольным количеством аргументов. Я думал над этим и не придумал хорошего решения.

ВВ>Ничего не понял. Как мне описать функцию, которая принимает один аргумент и совершает операцию над этим аргументом?


add_1 :: Number -> Number
x = x + 1

T>>Я не понял вопроса. Но вот этот тип

T>>x :: String
T>>описывает функцию с именем "x" с 0 аргументов, которая возвращает строку.
T>>Функциональным, обычно, называют тип a → b. Даже если b при этом сам является c → d. Оператор → правоассоциативен, как минус.

ВВ>Опять ничего не понял. Функциональный тип у которого 0 аргументов?


Можно убрать слово "функциональный" чтобы выглядело более естественно. Смысл не изменится, потому что всё есть функция. Думаю, что именно в этом и кроется смысл выражения "функциональный язык".

T>>Если всё стало выражением, это значит только то, что ты теперь получил кучу гемора с определением какой же результат должен быть у всего.

T>>Например, "for" ты потерял, потому что у него результата нет. Сказать на всё, что раньше было стейтментом, что у него результат — специальное значение void, это и есть создать именно лишнюю сущность, закрыть глаза на проблему выражений, создать костыль.

ВВ>Сохранение этого разделения представляет собой костыль куда больший. Оно в сущности означает, что для написания кода тебе по-прежнему придется использовать типичные конструкции императивного flow control — return и прочая.

ВВ>К тому же я тут ровным счетом ничего не изобрел.

return сам по себе неплох. Просто нужно помнить, что он ещё и вызывает продолжение, т.е. по сути это name-bind + goto. Так вот, как минимум первая его половина — полезна очень.

Не изобрёл, да. Довольно сложно что-то изобрести вообще.
Re[28]: Про скобочки
От: Temoto  
Дата: 30.04.10 10:35
Оценка:
T>>- Эта идиотская идея, что типы документируют код. Это работает только в примитивных случаях, где и документировать нечего.
T>>- Обязательная ленивость. Иногда всё-таки хочется взять на себя ответственность и указать порядок.
T>>- Вся стандартная библиотека завязана на один конкретный тип последовательности: односвязанный список (который имеет конструктор ':'). Как следствие, для Array, Set, Map и пр. — свои, отдельные операции. Например, map/filter/fold работают *только с []*.
T>>- Самая странная, убогая реализация туплов в мире. Это 64 строки типа http://google.com/codesearch/p?hl=en#5KTrgOW2hXs/pub/nslu2/sources/hugs98-Nov2003.tar.gz|cVG3t241wQU/hugs98-Nov2003/fptools/libraries/base/Data/Tuple.hs&q=%22%28,,%29%20a%20b%20c%22&l=71
T>>- main имеет "грязный" тип IO. То есть на хаскеле нельзя писать чистые программы, только чистые функции.

ВВ>Кстати, а на чем ты собираешься все это писать? И во что компилировать?


Был микропроект по написанию парсера. На хаскеле
Компилировать это отличный вопрос. На первом этапе, честно говоря, я собирался сделать интерпретатор, как более простой вариант.
Но мечта идиота — компилить в LLVM IR.
Re[20]: Про скобочки
От: night beast СССР  
Дата: 30.04.10 10:46
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

NB>>Извини что встреваю в беседу

NB>>Можешь пояснить, чем точка с запятой в конце конце каждого выражения не устраивает?

ВВ>Ну речь в общем о том, что убрать из синтаксиса мусор — а во многих случаях и так видно, что у тебя разные выражения, зачем еще точки с запятой?


if (cond) expr#1 expr#2

как должно выполняться?


ВВ>А вообще тут дополнительные сложности как бы создает тот факт, что разделения на expression и statement нет, поэтому такой код валиден:


не видя грамматику трудно что-то сказать.

ВВ>var x = if (cond)
ВВ>           firstAction()
ВВ>        else
ВВ>           secondAction();



ВВ>Вот скажи, ты бы хотел его записывать так:


ВВ>var x = if (cond)
ВВ>           firstAction();
ВВ>        else
ВВ>           secondAction();;


а почему бы не требовать ";" только в блоке кода?
Re[21]: Про скобочки
От: Воронков Василий Россия  
Дата: 30.04.10 11:00
Оценка:
Здравствуйте, night beast, Вы писали:

NB>
NB>if (cond) expr#1 expr#2
NB>

NB>как должно выполняться?

не видя грамматику трудно что-то сказать.


Можно представить себе грамматику где подобная конструкция неконфликтна.

NB>а почему бы не требовать ";" только в блоке кода?


Не понял.
Re[22]: Про скобочки
От: night beast СССР  
Дата: 30.04.10 11:10
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

NB>>
NB>>if (cond) expr#1 expr#2
NB>>

NB>>как должно выполняться?

ВВ>

ВВ>не видя грамматику трудно что-то сказать.


ВВ>Можно представить себе грамматику где подобная конструкция неконфликтна.


да я не спорю что не конфликтна
что должно быть про cond == false? выполняться только #2 или ничего

NB>>а почему бы не требовать ";" только в блоке кода?


ВВ>Не понял.


if (cond) { 1; 2; } -- хорошо
if (cond) { 1; 2 } -- плохо

ставить ли ; после } -- открытый вопрос.
Re[29]: Про скобочки
От: Воронков Василий Россия  
Дата: 30.04.10 11:13
Оценка:
Здравствуйте, Temoto, Вы писали:

ВВ>>Все языки семейства ML тебя устроят? Scala? Haskell? Nemerle?

T>В хаскеле точно нет ни void, ни unit.

Неправда, в Хаскеле есть тип unit.

T>Круто.


А что крутого? Последовательность исполнения тебе и C# не гарантирует.

T>(монада в общем смысле тоже не гарантирует кстати. Только IO)


Разве? Что-то ты путаешь, мне кажется.

T>Я хочу увидеть (и показать) как (в худшем случае) N-1 выражений в каждом блоке не используются.


Синтаксический мусор т.е.? Ну я и так знаю, что он есть.

T>add_1 :: Number -> Number

T> x = x + 1

А как написать аналог такого:

let isEven(x) = x % 2 == 0;
let list = [1, 2, 3, 4, 5, 6];

... = filter(list, isEven);


Реализацию filter опускаем.

T>Можно убрать слово "функциональный" чтобы выглядело более естественно. Смысл не изменится, потому что всё есть функция. Думаю, что именно в этом и кроется смысл выражения "функциональный язык".


Может быть, это справедливо для Хаскеля (и то сомневаюсь), но для большинства других языков — нет. В ML все есть значение, но значение необязательно есть функция.

T>return сам по себе неплох. Просто нужно помнить, что он ещё и вызывает продолжение, т.е. по сути это name-bind + goto. Так вот, как минимум первая его половина — полезна очень.


Какой еще name-bind? Return без goto полностью аналогичен записи без return.
Я перепробовал много вариантов — с разделением на expression && statements, со злобными ошибками на некоторые из выражений и проч. — к текущему пришел далеко не сразу. Может быть, он неидеален, но это лучшее из того, что я перепробовал.
Re[23]: Про скобочки
От: Воронков Василий Россия  
Дата: 30.04.10 11:17
Оценка:
Здравствуйте, night beast, Вы писали:

NB>да я не спорю что не конфликтна

NB>что должно быть про cond == false? выполняться только #2 или ничего

Ты, видимо, else пропустил. Вообще я все же не понимаю вопрос. Или ты намекаешь на то, что else — это не мусор? А на else никто и не наезжал. Но вот скобочки вокруг cond вполне могут быть и мусором.
Самая минимальная неконфликтная запись условия:


cond ? expr1 : expr2



NB>>>а почему бы не требовать ";" только в блоке кода?

ВВ>>Не понял.
NB>if (cond) { 1; 2; } -- хорошо
NB>if (cond) { 1; 2 } -- плохо
NB>ставить ли ; после } -- открытый вопрос.

Ну а что это меняет? А в глобальном блоке как быть? А как быть с конструкциями, которые вообще могут быть без блоков?
Re[24]: Про скобочки
От: night beast СССР  
Дата: 30.04.10 11:32
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

NB>>да я не спорю что не конфликтна

NB>>что должно быть про cond == false? выполняться только #2 или ничего

ВВ>Ты, видимо, else пропустил. Вообще я все же не понимаю вопрос. Или ты намекаешь на то, что else — это не мусор? А на else никто и не наезжал.


нет, там ";" после первого выражения пропущено.

ВВ>Но вот скобочки вокруг cond вполне могут быть и мусором.


class Test {
   operator bool ();
   operator () (int)
} test;

if test (1) ;


здесь ошибка или нет?

NB>>>>а почему бы не требовать ";" только в блоке кода?

ВВ>>>Не понял.
NB>>if (cond) { 1; 2; } -- хорошо
NB>>if (cond) { 1; 2 } -- плохо
NB>>ставить ли ; после } -- открытый вопрос.

ВВ>Ну а что это меняет? А в глобальном блоке как быть?


так же как в не глобальном.

ВВ> А как быть с конструкциями, которые вообще могут быть без блоков?


пример?
Re[25]: Про скобочки
От: Воронков Василий Россия  
Дата: 30.04.10 12:22
Оценка:
Здравствуйте, night beast, Вы писали:

ВВ>>Ты, видимо, else пропустил. Вообще я все же не понимаю вопрос. Или ты намекаешь на то, что else — это не мусор? А на else никто и не наезжал.

NB>нет, там ";" после первого выражения пропущено.

Если запись expr expr не создает конфликтов, то все понятно. Ты записал в строку if без else и еще одно выражение.

ВВ>>Но вот скобочки вокруг cond вполне могут быть и мусором.


NB>
NB>class Test {
NB>   operator bool ();
NB>   operator () (int)
NB>} test;

NB>if test (1) ;
NB>


NB>здесь ошибка или нет?


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

ВВ>>Ну а что это меняет? А в глобальном блоке как быть?

NB>так же как в не глобальном.

А вот тут точно нужны все точки с запятой:

x => { expr1; expr2; };

ВВ>> А как быть с конструкциями, которые вообще могут быть без блоков?

NB>пример?

Объявление переменной
Re[30]: Про скобочки
От: Temoto  
Дата: 30.04.10 12:26
Оценка:
ВВ>>>Все языки семейства ML тебя устроят? Scala? Haskell? Nemerle?
T>>В хаскеле точно нет ни void, ни unit.

ВВ>Неправда, в Хаскеле есть тип unit.


http://www.haskell.org/hoogle/?hoogle=unit

T>>Круто.


ВВ>А что крутого? Последовательность исполнения тебе и C# не гарантирует.


Что-то мне подсказывает, что два Console.Write выполнятся именно в том порядке, в котором они записаны.

T>>(монада в общем смысле тоже не гарантирует кстати. Только IO)

ВВ>Разве? Что-то ты путаешь, мне кажется.

Монада это интерфейс из двух методов, вот и всё. Как видишь, про последовательность ничего.
Монада IO даёт последовательное вычисление. А тысячи остальных ­— нет. Потому что нигде, кроме IO оно и не нужно.

Ну или покажи где я путаю. В принципе, конечно, могу путать. Но тут уверен.

T>>Я хочу увидеть (и показать) как (в худшем случае) N-1 выражений в каждом блоке не используются.

ВВ>Синтаксический мусор т.е.? Ну я и так знаю, что он есть.

Не синтаксический. как бы это.. семантический мусор что-ли
Грамматически в коде куча значений и не используются. Некрасиво. Вот стейтменты честно говорят, что значений они не возвращают. И for более логичен в виде стейтмента, чем в виде выражения со значением null/void/etc.

Это я всё почему... поставь себя на место компилятора. Не используется выражение? Ну так и не надо его вычислять. Логично.

T>>add_1 :: Number -> Number

T>> x = x + 1

ВВ>А как написать аналог такого:


ВВ>
ВВ>let isEven(x) = x % 2 == 0;
ВВ>let list = [1, 2, 3, 4, 5, 6];

ВВ>... = filter(list, isEven);
ВВ>


ВВ>Реализацию filter опускаем.


even x = x % 2 == 0
xs = list 1..6
ys = filter even xs

(я опять потерял нить по какому поводу этот код)

T>>Можно убрать слово "функциональный" чтобы выглядело более естественно. Смысл не изменится, потому что всё есть функция. Думаю, что именно в этом и кроется смысл выражения "функциональный язык".


ВВ>Может быть, это справедливо для Хаскеля (и то сомневаюсь), но для большинства других языков — нет. В ML все есть значение, но значение необязательно есть функция.


Это как-то в общей теории что-ли... в математике что-ли... значение тождественно нулларной функции, которая вернула бы это значение. У них смысловой разницы нет. Это в языках, где функцию надо явно *вызвать* чтобы получить её значение — разница появляется.

T>>return сам по себе неплох. Просто нужно помнить, что он ещё и вызывает продолжение, т.е. по сути это name-bind + goto. Так вот, как минимум первая его половина — полезна очень.


ВВ>Какой еще name-bind? Return без goto полностью аналогичен записи без return.

ВВ>Я перепробовал много вариантов — с разделением на expression && statements, со злобными ошибками на некоторые из выражений и проч. — к текущему пришел далеко не сразу. Может быть, он неидеален, но это лучшее из того, что я перепробовал.

name-bind это присваивание результата вызова функции какому-то имени.

Например, снаружи код

print x + 1 # то есть функцию '+' вызвали с двумя аргументами
В этом месте можно представить виртуальное имя _expr_x+1

_expr_x+1 = x + 1
print _expr_x+1

Так вот, код оператора + мог бы быть примерно таким:

function op_+ (x, y) {
return _numeric_plus(x, y); # вот этот return делает присваивание результата _numeric_plus имени _expr_x+1 а ещё делает goto на следущую строку (то есть на строку с принтом)
}
Re[29]: Про скобочки
От: Воронков Василий Россия  
Дата: 30.04.10 12:29
Оценка:
Здравствуйте, Temoto, Вы писали:

T>Был микропроект по написанию парсера. На хаскеле

T>Компилировать это отличный вопрос. На первом этапе, честно говоря, я собирался сделать интерпретатор, как более простой вариант.
T>Но мечта идиота — компилить в LLVM IR.

Свой интерпретатор == своя виртуальная машина со своим байт-кодом. А это дает ряд преимуществ. Например, при дизайне байт-кода ты можешь фактически "заточить" его под особенности своего языка.
А вот если использовать LLVM, MSIL/JIT и проч., то тебе придется прогибаться под существующий дизайн. Например, MSIL — это объектно-ориентированный ассемблер и так далее.

Т.е. тут надо аккуратнее выбирать. Свой интерпретатор в чем-то сложнее, но в чем-то проще. Но можно получить нефиговое количество гемороя пытаясь потом портировать его под другую VM. Если уж мечта — это LLVM, то лучше сразу на ней и делать. К тому же рабочий прототип ты получишь раньше, чем с интерпретатором.
Re[30]: Про скобочки
От: Temoto  
Дата: 30.04.10 12:34
Оценка:
T>>Был микропроект по написанию парсера. На хаскеле
T>>Компилировать это отличный вопрос. На первом этапе, честно говоря, я собирался сделать интерпретатор, как более простой вариант.
T>>Но мечта идиота — компилить в LLVM IR.

ВВ>Свой интерпретатор == своя виртуальная машина со своим байт-кодом. А это дает ряд преимуществ. Например, при дизайне байт-кода ты можешь фактически "заточить" его под особенности своего языка.

ВВ>А вот если использовать LLVM, MSIL/JIT и проч., то тебе придется прогибаться под существующий дизайн. Например, MSIL — это объектно-ориентированный ассемблер и так далее.

Да, я уже наслышан о геморе мужиков из Unladen Swallow.
http://www.python.org/dev/peps/pep-3146/#id142 здесь описано подробно

ВВ>Т.е. тут надо аккуратнее выбирать. Свой интерпретатор в чем-то сложнее, но в чем-то проще. Но можно получить нефиговое количество гемороя пытаясь потом портировать его под другую VM. Если уж мечта — это LLVM, то лучше сразу на ней и делать. К тому же рабочий прототип ты получишь раньше, чем с интерпретатором.


Почему рабочий прототип на LLVM раньше?
Re[31]: Про скобочки
От: Воронков Василий Россия  
Дата: 30.04.10 12:51
Оценка:
Здравствуйте, Temoto, Вы писали:

ВВ>>Неправда, в Хаскеле есть тип unit.

T>http://www.haskell.org/hoogle/?hoogle=unit

И что это? unit в Хаскеле это пустой кортеж. Его литерал — это ()

T>>>Круто.

ВВ>>А что крутого? Последовательность исполнения тебе и C# не гарантирует.
T>Что-то мне подсказывает, что два Console.Write выполнятся именно в том порядке, в котором они записаны.

Ерунда.

goto L2;
L1: Console.WriteLine("1");
goto L3
L2: Console.WriteLine("2");
L3:


А если еще вспомнить, что даже в C# есть ленивость:

var list = ....;
var seq = from p in list select p;
...
много кода
...
foreach (var s in seq) {}//а вот тут выполняется select


T>>>(монада в общем смысле тоже не гарантирует кстати. Только IO)

ВВ>>Разве? Что-то ты путаешь, мне кажется.
T>Монада это интерфейс из двух методов, вот и всё. Как видишь, про последовательность ничего.

Монада это — сначала функция А, потом функция Б. Описание функции Б выглядит как "сначала функция А1, потом функция Б2".
По-моему — четкая последовательность.

T>>>Я хочу увидеть (и показать) как (в худшем случае) N-1 выражений в каждом блоке не используются.

ВВ>>Синтаксический мусор т.е.? Ну я и так знаю, что он есть.

T>Не синтаксический. как бы это.. семантический мусор что-ли

T>Грамматически в коде куча значений и не используются. Некрасиво. Вот стейтменты честно говорят, что значений они не возвращают.

Альтернатива приведет к тому, что ты будешь постоянно писать что-то типа:

let func(..) = {
  for (...) {

  }

  null;
};


Я через это уже проходил, некрасивости куда больше.
Да и что такого некрасивого в void? Это просто значение, которого нет.

T>И for более логичен в виде стейтмента, чем в виде выражения со значением null/void/etc.


Ты знаешь как переводится слово void? Пусто. Нету тут ничего, это void. В выражении:

for (...) {

}


Никаких значений тут не создается и ничего не стек не поднимается.

T>Это я всё почему... поставь себя на место компилятора. Не используется выражение? Ну так и не надо его вычислять. Логично.


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

func(...);


Возвращаемое значение тоже не используется, но функция вполне может делать что-нибудь полезное. С сайд-эффектами
Не вызывать ее?

T>even x = x % 2 == 0

T>xs = list 1..6
T>ys = filter even xs

T>(я опять потерял нить по какому поводу этот код)


Ни по какому. Просто хочется лучше понять, что ты придумал.

T>Это как-то в общей теории что-ли... в математике что-ли... значение тождественно нулларной функции, которая вернула бы это значение. У них смысловой разницы нет. Это в языках, где функцию надо явно *вызвать* чтобы получить её значение — разница появляется.


Это в чистых ленивых языках. Тут "функциональность" сама по себе не причем, если ты конечно ее с ленивостью не делаешь тождественной.
Выражение вида

x = 2 + 2

становится функцией именно потому что оно будет вычислено только когда реально потребуется.
Но большая часть остальных языков — вполне себе энергичные. Да еще и с побочными эффектами. Там нельзя делать такую "прозрачную" ленивость.

T>name-bind это присваивание результата вызова функции какому-то имени.


Ну это не return делает. Это делает, например, let binding:

let func() = (0, 1, 2);
let (x, y, z) = func();


Этот код мог выглядеть и так:

let func() = return (0, 1, 2);
let (x, y, z) = func();



Как видишь ничего не меняется.
А вот goto — да, это return.
Re[31]: Про скобочки
От: Воронков Василий Россия  
Дата: 30.04.10 13:07
Оценка:
Здравствуйте, Temoto, Вы писали:

T>Почему рабочий прототип на LLVM раньше?


Если подходить к вопросу сугубо формально, то собственный интерпретатор — это:

1. Парсер (1 штука)
2. Компилятор (1 штука)
3. Виртуальная машина (1 штука)

А собственный компилятор в уже существующий бэкенд, это:

1. Парсер (1 штука)
2. Компилятор (1 штука)

Я не знаком конкретно с LLVM, но я не думаю, что тут ситуация кардинально отличается от .NET. Суть в том, что уже есть готовый бэкенд и есть некий набор инструкций, который на нем выполняется. Для обкатки каких-то решений, конечно, проще, когда все это уже есть. Если идти глубже, то да — может оказаться, что существующий бэкенд в чем-то ограничен, не совсем подходить, и надо будет пытаться обходить его ограничения и особенности.
Но мне кажется, для того чтобы получить из концепции на бумаге что-то работающее — это все же путь более прямой, хоть конечно сильно зависит от языка и твоих задумок.

Со своей вирт. машиной — если все же задача сделать что-то реально полезное, с приемлимой производительностью — можно много времени убить именно на ее тюнинг. Плюс ты *все* делаешь сам. Например, в случае с MSIL-ом в качестве бэкенда реализация какого-нибудь try/catch/finally — дело плевое. Оно уже есть там. Если делать самому — то это нефиговая такая задача.

Ну и честно говоря мне кажется на Хаскеле сложновато будет написать быструю вирт. машину, сравнимую по производительности с реализациями на том же Си. А скорость все же важна.
Re[32]: Про скобочки
От: Temoto  
Дата: 30.04.10 13:31
Оценка:
ВВ>>>Неправда, в Хаскеле есть тип unit.
T>>http://www.haskell.org/hoogle/?hoogle=unit

ВВ>И что это? unit в Хаскеле это пустой кортеж. Его литерал — это ()


Ах вон ты о чём. Теперь понял.

T>>>>Круто.

ВВ>>>А что крутого? Последовательность исполнения тебе и C# не гарантирует.
T>>Что-то мне подсказывает, что два Console.Write выполнятся именно в том порядке, в котором они записаны.

ВВ>Ерунда.


ВВ>
ВВ>goto L2;
ВВ>L1: Console.WriteLine("1");
ВВ>goto L3
ВВ>L2: Console.WriteLine("2");
ВВ>L3:
ВВ>


А причём тут гарантия последовательности? Я сказал про два Console.Write, а не про два Console.Write с кучей goto.

ВВ>А если еще вспомнить, что даже в C# есть ленивость:


А ленивость, ещё раз, к последовательности отношения не имеет. Можно выполнить последовательно и потом. Можно выполнить в разнобой и сейчас.

ВВ>Монада это — сначала функция А, потом функция Б. Описание функции Б выглядит как "сначала функция А1, потом функция Б2".

ВВ>По-моему — четкая последовательность.

Хакей, мы по-разному понимаем этот термин. Думаю, что тебе стоит обратиться к какому-нибудь штангисту и уточнить своё определение.

T>>>>Я хочу увидеть (и показать) как (в худшем случае) N-1 выражений в каждом блоке не используются.

ВВ>>>Синтаксический мусор т.е.? Ну я и так знаю, что он есть.
T>>Не синтаксический. как бы это.. семантический мусор что-ли
T>>Грамматически в коде куча значений и не используются. Некрасиво. Вот стейтменты честно говорят, что значений они не возвращают.
ВВ>Альтернатива приведет к тому, что ты будешь постоянно писать что-то типа:
ВВ>Я через это уже проходил, некрасивости куда больше.

Согласен, некрасиво. Потому что это не альтернатива. Это просто зачем-то явный null в конце. А неиспользованное выражение for осталось.

ВВ>Да и что такого некрасивого в void? Это просто значение, которого нет.


Именно это и некрасиво. Значение, которое ничего не значит. Охренеть содержательно. Если б оно называлось side-effect, было бы честнее и понятнее, чес-слово.

T>>Это я всё почему... поставь себя на место компилятора. Не используется выражение? Ну так и не надо его вычислять. Логично.

ВВ>Не совсем. Не использует *возвращаемое значение* выражения. В коде вида:

ВВ>
ВВ>func(...);
ВВ>


ВВ>Возвращаемое значение тоже не используется, но функция вполне может делать что-нибудь полезное. С сайд-эффектами

ВВ>Не вызывать ее?

Я повторюсь, что лично по-моему, стейтмент это и есть "выражение, значение которого неважно, но вычислить его нужно".

T>>Это как-то в общей теории что-ли... в математике что-ли... значение тождественно нулларной функции, которая вернула бы это значение. У них смысловой разницы нет. Это в языках, где функцию надо явно *вызвать* чтобы получить её значение — разница появляется.


ВВ>Это в чистых ленивых языках. Тут "функциональность" сама по себе не причем, если ты конечно ее с ленивостью не делаешь тождественной.


Я даже чётко написал, что это не в языках программирования вообще.

ВВ>Выражение вида


ВВ>x = 2 + 2


ВВ>становится функцией именно потому что оно будет вычислено только когда реально потребуется.

ВВ>Но большая часть остальных языков — вполне себе энергичные. Да еще и с побочными эффектами. Там нельзя делать такую "прозрачную" ленивость.

Где побочных эффектов нет, там и можно, почему же. А наличие побочных эффектов во многих случаях можно статически найти. Тут рядом это обсуждалось в контексте немерле.

T>>name-bind это присваивание результата вызова функции какому-то имени.


ВВ>Ну это не return делает. Это делает, например, let binding:


ВВ>Как видишь ничего не меняется.

ВВ>А вот goto — да, это return.

Почему return этого не делает ты не сказал. Или может return в Ela этого не делает — то, конечно, всё может быть, я не знаю внутренностей. Опять, я рассуждаю с позиции какой-то теории не в конкретном языке, а в целом.
Хакей, не сошлись терминами. У меня немного другая мысль была.
Re[32]: Про скобочки
От: Temoto  
Дата: 30.04.10 13:52
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


T>>Почему рабочий прототип на LLVM раньше?


ВВ>Если подходить к вопросу сугубо формально, то собственный интерпретатор — это:


ВВ>1. Парсер (1 штука)

ВВ>2. Компилятор (1 штука)
ВВ>3. Виртуальная машина (1 штука)

ВВ>А собственный компилятор в уже существующий бэкенд, это:


ВВ>1. Парсер (1 штука)

ВВ>2. Компилятор (1 штука)

ВВ>Я не знаком конкретно с LLVM, но я не думаю, что тут ситуация кардинально отличается от .NET. Суть в том, что уже есть готовый бэкенд и есть некий набор инструкций, который на нем выполняется. Для обкатки каких-то решений, конечно, проще, когда все это уже есть. Если идти глубже, то да — может оказаться, что существующий бэкенд в чем-то ограничен, не совсем подходить, и надо будет пытаться обходить его ограничения и особенности.

ВВ>Но мне кажется, для того чтобы получить из концепции на бумаге что-то работающее — это все же путь более прямой, хоть конечно сильно зависит от языка и твоих задумок.

ВВ>Со своей вирт. машиной — если все же задача сделать что-то реально полезное, с приемлимой производительностью — можно много времени убить именно на ее тюнинг. Плюс ты *все* делаешь сам. Например, в случае с MSIL-ом в качестве бэкенда реализация какого-нибудь try/catch/finally — дело плевое. Оно уже есть там. Если делать самому — то это нефиговая такая задача.


Понял. Если подходить формально, то конечно, 3 компонента больше, чем 2

ВВ>Ну и честно говоря мне кажется на Хаскеле сложновато будет написать быструю вирт. машину, сравнимую по производительности с реализациями на том же Си. А скорость все же важна.


По-моему, люди часто путают "скорость важна" и "нужна скорость близкая к бесконечности". Как там было... (маленькое число по вкусу) кода выполняется (большое число) времени. Всё остальное оптимизировать смысла нет.
Re[13]: Про скобочки
От: March_rabbit  
Дата: 30.04.10 14:54
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Код намного чаще приходится читать нежели писать. Лишние скобки однозначно ухудшают читаемость кода, так что ваши мнимые ошибки выливаются в совершенно явное и постоянное ухудшение качества кода.

VD>Я уверен, что оно того не стоит.

завидую молодым и самоуверенным
где мои школьные годы?
Re[12]: Про скобочки
От: March_rabbit  
Дата: 30.04.10 14:57
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>Зачем запрещать? Достаточно не допускать их смеси в одном фале.

M_>>не всякий редактор покажет, что стоит имеено здесь — пробел или таб

VD>Не пользуйся "всякими" редакторами. Пользуйся полноценными. Кроме того, табы и пробелы должны контролироваться компилятором.

ага, плавали — знаем.
знаешь, иногда приходится и в чужих системах клавиши давить и файлы править. А что там окажется — только от хозяина зависит.

Классический случай, когда фанат вима или емакса попадает в систему, где стоит что-то другое.....
Re[11]: Про скобочки
От: March_rabbit  
Дата: 30.04.10 14:59
Оценка:
Здравствуйте, Temoto, Вы писали:

ВВ>>>>>А там можно получить неправильную программу просто вставив лишний пробел


FR>>>>Пробел фигня, вот неправильный таб вообще может до смертоубийства довести


T>>>В чём разница?

M_>>разница в том, что разные редакторы ставят разное количество пробелов вместо таба. То есть, глазами смотришь — строки на одном уровне, запускаешь — код ведет себя черти как. Залез в коды — вот оно: таб и пробелы. Уж сколько раз такое было......

T>Ну так настройте редактор.

еще один.
ты пробовал когда-нить поработать за чужой машиной? Когда там все другое И НАСТРОЕНО ПОД ХОЗЯИНА. ?
попробуй, потом расскажешь, как тебе хозяин системы спасибо говорил за "настроенный редактор"
Re[12]: Про скобочки
От: Temoto  
Дата: 30.04.10 16:22
Оценка:
ВВ>>>>>>А там можно получить неправильную программу просто вставив лишний пробел
FR>>>>>Пробел фигня, вот неправильный таб вообще может до смертоубийства довести
T>>>>В чём разница?
M_>>>разница в том, что разные редакторы ставят разное количество пробелов вместо таба. То есть, глазами смотришь — строки на одном уровне, запускаешь — код ведет себя черти как. Залез в коды — вот оно: таб и пробелы. Уж сколько раз такое было......

T>>Ну так настройте редактор.

M_>еще один.
M_>ты пробовал когда-нить поработать за чужой машиной? Когда там все другое И НАСТРОЕНО ПОД ХОЗЯИНА. ?
M_>попробуй, потом расскажешь, как тебе хозяин системы спасибо говорил за "настроенный редактор"

Да, было время когда я каждый день работал за чужой машиной.
Хозяин писал под диктовку, я тоже потихоньку привыкал к его настройкам. Неудобно. Медленно. Но это совсем из другой оперы.

Вы путаете "настроено под хозяина" и "настроено". Если человек пишет на языке, где пробелы/табы важны и они у него не подсвечены — значит редактор не настроен.
Re[33]: Про скобочки
От: Воронков Василий Россия  
Дата: 30.04.10 16:52
Оценка:
Здравствуйте, Temoto, Вы писали:

ВВ>>И что это? unit в Хаскеле это пустой кортеж. Его литерал — это ()

T>Ах вон ты о чём. Теперь понял.

Ну вот это тот же самый void, что и у меня. Не больше и не меньше.
Не забудь, кстати, записать его наличие в список недостатков Хаскеля

ВВ>>А если еще вспомнить, что даже в C# есть ленивость:

T>А ленивость, ещё раз, к последовательности отношения не имеет. Можно выполнить последовательно и потом. Можно выполнить в разнобой и сейчас.

А что же тогда имеет отношение к последовательности?
В чем проблема ленивого языка на пару с сайд-эффектами? Выражение вида var x = y + 2 может иметь один результат там, где оно фактически записано, и совсем другой, если мы выполняем его не сразу, а лишь "по требованию", т.к. "y" мог просто-напросто поменяться.
Очевидно, что вся эта неявная ленивость при сайд эффектах идет лесом.
В С# есть ленивость, но там ты, можно сказать, реализуешь ее на свой страх и риск — и да, злоупотребление тут вполне может привести к не самым приглядным эффектам.

ВВ>>Монада это — сначала функция А, потом функция Б. Описание функции Б выглядит как "сначала функция А1, потом функция Б2".

ВВ>>По-моему — четкая последовательность.
T>Хакей, мы по-разному понимаем этот термин. Думаю, что тебе стоит обратиться к какому-нибудь штангисту и уточнить своё определение.

Объясни тогда свое понимание. Которое при этом не имеет отношения к ленивости.

T>>>>>Я хочу увидеть (и показать) как (в худшем случае) N-1 выражений в каждом блоке не используются.

ВВ>>>>Синтаксический мусор т.е.? Ну я и так знаю, что он есть.
T>>>Не синтаксический. как бы это.. семантический мусор что-ли
T>>>Грамматически в коде куча значений и не используются. Некрасиво. Вот стейтменты честно говорят, что значений они не возвращают.
ВВ>>Альтернатива приведет к тому, что ты будешь постоянно писать что-то типа:
ВВ>>Я через это уже проходил, некрасивости куда больше.

T>Согласен, некрасиво. Потому что это не альтернатива. Это просто зачем-то явный null в конце. А неиспользованное выражение for осталось.


ВВ>>Да и что такого некрасивого в void? Это просто значение, которого нет.


T>Именно это и некрасиво. Значение, которое ничего не значит. Охренеть содержательно. Если б оно называлось side-effect, было бы честнее и понятнее, чес-слово.


"Пустой кортеж". Вполне нормальное понятие.
А что у нас в качестве альтернативы-то? Разделение на statement и expression — это не так хорошо, как тебе почему-то кажется.
Вот есть функция, она всегда возвращает какое-то значение. Что может быть телом функции? Очевидно, только expression. Т.е. я в принципе не могу писать императивный код внутри функции? А несколько выражений могу записать? Блок выражений сам по себе является выражением?
Если да — получаем ту же петрушку. Последним в блоке идет statement. Не компилируем? Заставляем возвращать значение? Вводим, помимо функций, некие субрутины, которые от функций отличаются только тем, что значение не возвращают? Созданные специально для императивного кода.

Опять же, по каким-то причинам большинство ФЯ таки тоже не могут уйти от этого void-а.

ВВ>>Возвращаемое значение тоже не используется, но функция вполне может делать что-нибудь полезное. С сайд-эффектами

ВВ>>Не вызывать ее?
T>Я повторюсь, что лично по-моему, стейтмент это и есть "выражение, значение которого неважно, но вычислить его нужно".

А вот вызов функции — это может быть и стейтмент и не стейтмент.

ВВ>>Это в чистых ленивых языках. Тут "функциональность" сама по себе не причем, если ты конечно ее с ленивостью не делаешь тождественной.

T>Я даже чётко написал, что это не в языках программирования вообще.

Ты четко написал, что подобное поведение для тебя является чуть ли не определением "функциональности" языка. Хотя многие ФЯ вполне энергичны и "все есть функция", очевидно, не про них.

T>Где побочных эффектов нет, там и можно, почему же. А наличие побочных эффектов во многих случаях можно статически найти. Тут рядом это обсуждалось в контексте немерле.


В контексте Немерле обсуждалась техника реализации модификатора pure для функции.
А так — ну нашел ты статически побочный эффект? Что делать? Не компилировать? Вычислять по месту? Во втором случае семантика программы станет вообще дико нетривиальной. Хаскель отдыхает.

T>Почему return этого не делает ты не сказал. Или может return в Ela этого не делает — то, конечно, всё может быть, я не знаю внутренностей. Опять, я рассуждаю с позиции какой-то теории не в конкретном языке, а в целом.

T>Хакей, не сошлись терминами. У меня немного другая мысль была.

Выскажи тогда свою мысль, я ее не понял. Наверное, можно представить себе язык, в котором return осуществляет binding. Но мне непонятно зачем да и вообще, надо сказать, я себе это с трудом представлю. К чему он биндит-то? Функция, одна и та же, может быть вызвана при инициализации, при изменении переменной или записи в консоль (побочные эффекты), наконец ее значение может быть попросту похерено.
Да и вообще это не задача функции что-то там связывать. Может быть у меня связывание происходит через паттерн матчинг вообще. Какой смысл нагружать return такой ответственностью?
Re[34]: Про скобочки
От: Temoto  
Дата: 30.04.10 17:25
Оценка:
ВВ>>>А если еще вспомнить, что даже в C# есть ленивость:
T>>А ленивость, ещё раз, к последовательности отношения не имеет. Можно выполнить последовательно и потом. Можно выполнить в разнобой и сейчас.

ВВ>А что же тогда имеет отношение к последовательности?


Порядок вычисления. Например, стейтментов в блоке или элементов в литерале списка.

ВВ>В чем проблема ленивого языка на пару с сайд-эффектами? Выражение вида var x = y + 2 может иметь один результат там, где оно фактически записано, и совсем другой, если мы выполняем его не сразу, а лишь "по требованию", т.к. "y" мог просто-напросто поменяться.

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

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

ВВ>>>Монада это — сначала функция А, потом функция Б. Описание функции Б выглядит как "сначала функция А1, потом функция Б2".

ВВ>>>По-моему — четкая последовательность.
T>>Хакей, мы по-разному понимаем этот термин. Думаю, что тебе стоит обратиться к какому-нибудь штангисту и уточнить своё определение.

ВВ>Объясни тогда свое понимание. Которое при этом не имеет отношения к ленивости.


Я уже сказал. Это интерфейс о двух методах: pure :: a -> m a и bind :: m a -> (a -> m b) -> m b. Ну, конечно, весь смысл во втором, первый так, чтоб было с чего начать.

T>>Согласен, некрасиво. Потому что это не альтернатива. Это просто зачем-то явный null в конце. А неиспользованное выражение for осталось.

ВВ>>>Да и что такого некрасивого в void? Это просто значение, которого нет.

T>>Именно это и некрасиво. Значение, которое ничего не значит. Охренеть содержательно. Если б оно называлось side-effect, было бы честнее и понятнее, чес-слово.


ВВ>"Пустой кортеж". Вполне нормальное понятие.


По-моему — так себе нормальное оно. Спорно. Больше похоже на костыль. Или я не видел действительно осмысленных применений ему.

ВВ>А что у нас в качестве альтернативы-то? Разделение на statement и expression — это не так хорошо, как тебе почему-то кажется.

ВВ>Вот есть функция, она всегда возвращает какое-то значение. Что может быть телом функции? Очевидно, только expression. Т.е. я в принципе не могу писать императивный код внутри функции? А несколько выражений могу записать? Блок выражений сам по себе является выражением?
ВВ>Если да — получаем ту же петрушку. Последним в блоке идет statement. Не компилируем? Заставляем возвращать значение? Вводим, помимо функций, некие субрутины, которые от функций отличаются только тем, что значение не возвращают? Созданные специально для императивного кода.

Последнее, про субрутины специально для императивного кода мне даже нравится. Эдакая подпись, как global: "да, я беру на себя ответственность и щас буду писать грязный императивный код."

ВВ>Опять же, по каким-то причинам большинство ФЯ таки тоже не могут уйти от этого void-а.


Да, именно. По каким-то. Я, например, честно скажу, что не знаю по каким. Даже не буду гадать.

ВВ>>>Возвращаемое значение тоже не используется, но функция вполне может делать что-нибудь полезное. С сайд-эффектами

ВВ>>>Не вызывать ее?
T>>Я повторюсь, что лично по-моему, стейтмент это и есть "выражение, значение которого неважно, но вычислить его нужно".

ВВ>А вот вызов функции — это может быть и стейтмент и не стейтмент.


Да... я всё больше верю в свой 'do'

ВВ>>>Это в чистых ленивых языках. Тут "функциональность" сама по себе не причем, если ты конечно ее с ленивостью не делаешь тождественной.

T>>Я даже чётко написал, что это не в языках программирования вообще.

ВВ>Ты четко написал, что подобное поведение для тебя является чуть ли не определением "функциональности" языка. Хотя многие ФЯ вполне энергичны и "все есть функция", очевидно, не про них.


Да, некоторые называют языки функциональными уже за то, что не Java (имеют first class function). Это такая скользкая терминологическая херня. я не буду об этом спорить

T>>Где побочных эффектов нет, там и можно, почему же. А наличие побочных эффектов во многих случаях можно статически найти. Тут рядом это обсуждалось в контексте немерле.


ВВ>В контексте Немерле обсуждалась техника реализации модификатора pure для функции.

ВВ>А так — ну нашел ты статически побочный эффект? Что делать? Не компилировать? Вычислять по месту? Во втором случае семантика программы станет вообще дико нетривиальной. Хаскель отдыхает.

Нашёл — не применяй там ленивость, мемоизацию и всё.

T>>Почему return этого не делает ты не сказал. Или может return в Ela этого не делает — то, конечно, всё может быть, я не знаю внутренностей. Опять, я рассуждаю с позиции какой-то теории не в конкретном языке, а в целом.

T>>Хакей, не сошлись терминами. У меня немного другая мысль была.

ВВ>Выскажи тогда свою мысль, я ее не понял. Наверное, можно представить себе язык, в котором return осуществляет binding. Но мне непонятно зачем да и вообще, надо сказать, я себе это с трудом представлю. К чему он биндит-то? Функция, одна и та же, может быть вызвана при инициализации, при изменении переменной или записи в консоль (побочные эффекты), наконец ее значение может быть попросту похерено.

ВВ>Да и вообще это не задача функции что-то там связывать. Может быть у меня связывание происходит через паттерн матчинг вообще. Какой смысл нагружать return такой ответственностью?

Идея такая, что в императивных языках return уже сейчас делает две вещи: бинд и goto. Прими это как факт, как базу для рассуждения.

function f() {
return 10;
}

line1: f();
line2: ...

такой код биндит 10 к специальному неиспользуемому имени и делает goto на line2.

line3: x = f();
line4: print x

такой код биндит 10 к имени 'x' и делает goto на line4.

x = expr это тоже патерн-матчинг, никакого противоречия тут нет.

Интересное начинается, если из семантики return убрать goto.

function f() {
return 10;
if (cond) {
return 20;
}
}

Тогда, в зависимости от условия, функция вернёт 10 или 20.
Re[35]: Про скобочки
От: Воронков Василий Россия  
Дата: 30.04.10 18:08
Оценка:
Здравствуйте, Temoto, Вы писали:

ВВ>>А что же тогда имеет отношение к последовательности?

T>Порядок вычисления. Например, стейтментов в блоке или элементов в литерале списка.

А почему это не связано с ленивостью?
Скажи вот здесь вот:

var seq = from p in list select p;

foreach (var e in seq) 
{

}


порядок вычисления сохраняется?

А здесь:

let l = lazy { 2 + 2}

let r = Lazy.force l + 2


ВВ>>В чем проблема ленивого языка на пару с сайд-эффектами? Выражение вида var x = y + 2 может иметь один результат там, где оно фактически записано, и совсем другой, если мы выполняем его не сразу, а лишь "по требованию", т.к. "y" мог просто-напросто поменяться.

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

T>Да, конечно; я это тоже говорил а ещё говорил, что можно во многих случаях отделить чистые выражения от потенциально содержащих сайдэффекты. И применить ленивость только к чистым, где она безопасна.


Если это дизайн-проект, то он странен. Ибо в Хаскеле я хотя бы точно знаю, что выражение ленивое. А здесь я даже этого не знаю Т.е. получается, что программа ведет себя вообще нетривиальным образом в глазах программиста.
В общем я нахожу это стремным

ВВ>>Объясни тогда свое понимание. Которое при этом не имеет отношения к ленивости.

T>Я уже сказал. Это интерфейс о двух методах: pure :: a -> m a и bind :: m a -> (a -> m b) -> m b. Ну, конечно, весь смысл во втором, первый так, чтоб было с чего начать.

А зачем нужен вообще этот метод? Это "интерфейс" задает последовательность выполнения, что весьма важно в том случае, если у нас есть побочные эффект. Метод 2 выполнится только после метода 1, ибо ему может зависеть от сайд-эффектов метода 1.
Если это не последовательность — то что?

Код вида (псевдо-C#):

WriteLine("1");
WriteLine("2");
WriteLine("3");


я могу расписать так:

var exec = f1 => {
   WriteLine("1");
   f1(f2 => {
                WriteLine("2");
                f2(f3 => {
                            WriteLine("3");    
                            ...
                         });
             }); 
};

exec |> f => f();


Вот тебе и монада.

ВВ>>"Пустой кортеж". Вполне нормальное понятие.

T>По-моему — так себе нормальное оно. Спорно. Больше похоже на костыль. Или я не видел действительно осмысленных применений ему.

Альтернатива?

ВВ>>Опять же, по каким-то причинам большинство ФЯ таки тоже не могут уйти от этого void-а.

T>Да, именно. По каким-то. Я, например, честно скажу, что не знаю по каким. Даже не буду гадать.

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

T>Да... я всё больше верю в свой 'do'


Только, чем он от монад отличается

T>Да, некоторые называют языки функциональными уже за то, что не Java (имеют first class function). Это такая скользкая терминологическая херня. я не буду об этом спорить


Да можешь считать функциональными только чистые и ленивые языки, мне не жалко.
Договоримся, что, говоря "функциональный язык", я имею в виду язык типа OCaml, F#, Scala, Nemerle.

T>Идея такая, что в императивных языках return уже сейчас делает две вещи: бинд и goto. Прими это как факт, как базу для рассуждения.


Мне все равно эта база непонятна. Да чем она поможет? Почему бы не считать, что бинд делает не return, а "=". Кто в данном случае делает бинд:

let (x > 10, y < 20) as tuple = func()


T>function f() {

T> return 10;
T> if (cond) {
T> return 20;
T> }
T>}
T>Тогда, в зависимости от условия, функция вернёт 10 или 20.

И получает код, в который я вообще не въезжаю. По идее бы он должен был выглядеть так:

function f() {
   if (cond)
      20
   else
      10
}


Я готов принять любые допущения, но хочется понять — зачем. Что ты пытаешь показать этим return без goto?
Re[36]: Про скобочки
От: Temoto  
Дата: 30.04.10 21:45
Оценка:
ВВ>>>А что же тогда имеет отношение к последовательности?
T>>Порядок вычисления. Например, стейтментов в блоке или элементов в литерале списка.

ВВ>А почему это не связано с ленивостью?

ВВ>Скажи вот здесь вот:

ВВ>
ВВ>var seq = from p in list select p;

ВВ>foreach (var e in seq) 
ВВ>{

ВВ>}
ВВ>


ВВ>порядок вычисления сохраняется?


Там очень много вычислений. Ты о чём именно?

ВВ>А здесь:


ВВ>
ВВ>let l = lazy { 2 + 2}

ВВ>let r = Lazy.force l + 2
ВВ>


И здесь тоже уточни.

ВВ>>>В чем проблема ленивого языка на пару с сайд-эффектами? Выражение вида var x = y + 2 может иметь один результат там, где оно фактически записано, и совсем другой, если мы выполняем его не сразу, а лишь "по требованию", т.к. "y" мог просто-напросто поменяться.

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

T>>Да, конечно; я это тоже говорил а ещё говорил, что можно во многих случаях отделить чистые выражения от потенциально содержащих сайдэффекты. И применить ленивость только к чистым, где она безопасна.


ВВ>Если это дизайн-проект, то он странен. Ибо в Хаскеле я хотя бы точно знаю, что выражение ленивое. А здесь я даже этого не знаю Т.е. получается, что программа ведет себя вообще нетривиальным образом в глазах программиста.

ВВ>В общем я нахожу это стремным

Смотря чего ожидает программист.

ВВ>>>Объясни тогда свое понимание. Которое при этом не имеет отношения к ленивости.

T>>Я уже сказал. Это интерфейс о двух методах: pure :: a -> m a и bind :: m a -> (a -> m b) -> m b. Ну, конечно, весь смысл во втором, первый так, чтоб было с чего начать.
ВВ>А зачем нужен вообще этот метод? Это "интерфейс" задает последовательность выполнения, что весьма важно в том случае, если у нас есть побочные эффект. Метод 2 выполнится только после метода 1, ибо ему может зависеть от сайд-эффектов метода 1.
ВВ>Если это не последовательность — то что?

Какой ты всё-таки... спрашиваешь моё определение, я его говорю без слова последовательность (наверное не просто так), ты опять навязываешь эту последовательность.

x = pure 10
f a = pure 20
result = bind x f # bind x ( a => pure 20 )
Возвращает pure 20. x вообще не надо вычислять. Нет последовательности.

А то по-твоему получается, что скобки в "a + (b + c)" тоже монада, потому что заставляет вычислить b+c до сложения с 'a'. То, что ты описал называется просто зависимость данных. Понятно, блин, что некоторые выражения зависят от значения других. Как видишь, на примере скобок, для этого не нужны интерфейсы и специальные термины.

ВВ>>>"Пустой кортеж". Вполне нормальное понятие.

T>>По-моему — так себе нормальное оно. Спорно. Больше похоже на костыль. Или я не видел действительно осмысленных применений ему.

ВВ>Альтернатива?


Ну, в Clean в качестве альтернативы — *World (звезда означает, что это значение можно использовать один раз). Не скажу, что это очень здорово, но в этом хотя бы есть смысл, в отличие от пустого кортежа/void: вот было состояние мира, вот мы его поменяли. Всё честно.

Чтобы действительно решить проблему "возврата ничего", один из подходов: FRP. Попытка очистить сайдэффекты. Но это довольно сложно.

А специальная языковая конструкция (стейтмент) это просто. Хотя и 100% "для бедных".

ВВ>А я подозреваю, что это цена за смешение императивности и функциональности. В общем вопрос тот же. Альтернатива?


(вряд ли есть смысл в одном посте задавать один вопрос дважды )

T>>Да... я всё больше верю в свой 'do'

ВВ>Только, чем он от монад отличается

От IO — тем что форсирует вычисление каждого выражения внутри. От остальных монад — всем.

T>>Идея такая, что в императивных языках return уже сейчас делает две вещи: бинд и goto. Прими это как факт, как базу для рассуждения.


ВВ>Мне все равно эта база непонятна. Да чем она поможет? Почему бы не считать, что бинд делает не return, а "=". Кто в данном случае делает бинд:


Потому что вызов функции не всегда стоит справа от '='. Например, в "f() + 1" нет '='.

ВВ>
ВВ>let (x > 10, y < 20) as tuple = func()
ВВ>


В данном случае return в func делает бинд промежуточному скрытому имени, которое потом раскладывается на x и y (если я правильно понял этот код). То есть два бинда.

T>>function f() {

T>> return 10;
T>> if (cond) {
T>> return 20;
T>> }
T>>}
T>>Тогда, в зависимости от условия, функция вернёт 10 или 20.

ВВ>И получает код, в который я вообще не въезжаю. По идее бы он должен был выглядеть так:


ВВ>
ВВ>function f() {
ВВ>   if (cond)
ВВ>      20
ВВ>   else
ВВ>      10
ВВ>}
ВВ>


Это код, который решает ту же самую задачу, но совсем по-другому.

Вот ещё пример зачем нужен return без goto:

function index-of (L, item) {
  return null;
  for x, index in L, [1..] {
    if x == item:
      return index;
      break; // то есть, здесь уже с goto
  }
}


В делфи неявно создаётся переменная Result. Полный аналог такого return.

function ...
begin
Result := 0;
...
Result := что-то ещё
...
Result := f();
end;

ВВ>Я готов принять любые допущения, но хочется понять — зачем. Что ты пытаешь показать этим return без goto?


Ну ты говорил, что return специально не делаешь, вот я хочу показать, что без goto он не так уж и страшен.
Re[14]: Про скобочки
От: Кэр  
Дата: 01.05.10 13:03
Оценка:
Здравствуйте, March_rabbit, Вы писали:

M_>завидую молодым и самоуверенным

M_>где мои школьные годы?

http://www.rsdn.ru/forum/life/3792757.1.aspx
Автор: March_rabbit
Дата: 30.04.10


Ваши школьные годы однозначно очень, очень далеко.
Re[26]: Про скобочки
От: night beast СССР  
Дата: 04.05.10 03:50
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>>>Ты, видимо, else пропустил. Вообще я все же не понимаю вопрос. Или ты намекаешь на то, что else — это не мусор? А на else никто и не наезжал.

NB>>нет, там ";" после первого выражения пропущено.

ВВ>Если запись expr expr не создает конфликтов, то все понятно. Ты записал в строку if без else и еще одно выражение.


это я все к тому, что избавляясь от ; ты получаешь проблемы (в виде неоднозначности грамматики), ничего не приобретая взамен.

var x = lambda(x) -> (x*x) (10)


здесь x -- это функция или 100?
ответ поясни.

ВВ>>>Но вот скобочки вокруг cond вполне могут быть и мусором.


NB>>
NB>>class Test {
NB>>   operator bool ();
NB>>   operator () (int)
NB>>} test;

NB>>if test (1) ;
NB>>


NB>>здесь ошибка или нет?


ВВ>Я вообще не вижу тут проблемы. Ну т.е. у всех конструкций есть вполне очевидное завершение. Ну и ; сам по себе является валидным выражением. Так что все в порядке.


то есть вызовется оператор bool, и если результат true, то вернется 1?
почему именно так?

ВВ>>>Ну а что это меняет? А в глобальном блоке как быть?

NB>>так же как в не глобальном.

ВВ>А вот тут точно нужны все точки с запятой:


ВВ>x => { expr1; expr2; };


на мой взгляд да

ВВ>>> А как быть с конструкциями, которые вообще могут быть без блоков?

NB>>пример?

ВВ>Объявление переменной


Точка с запятой в в конце объявления :
int x;
Re: Про скобочки
От: batu Украина  
Дата: 04.05.10 05:41
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Известно, что в Си-подобном синтаксисе круглые скобочки несколько перегружены смыслом. Это и средство для группировки выражений, и часть грамматики некоторых стандартных выражений вроде for, if и вызов функции, и приведение типов...

ВВ>На мой взгляд это несколько снижает читабельность.

ВВ>А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях. Например, вместо



ВВ>
ВВ>for (x in y) 
ВВ>  expr
ВВ>



ВВ>было бы



ВВ>
ВВ>for x in y do
ВВ>  expr
ВВ>


Здесь, совершенно очевидно, вы правы. Круглые скобки лишние. По ключевому слову In тип оператора For однозначно определяется. Хотя есть вариант обойтись и без этого ключевого слова определив такой тип циклов как отдельный класс операторов ForEach.
ВВ>Или вместо


ВВ>
ВВ>if (x > y)
ВВ>  expr
ВВ>else
ВВ>  expr
ВВ>



ВВ>было бы



ВВ>
ВВ>if x > y then
ВВ>  expr
ВВ>else
ВВ>  expr
ВВ>


И здесь круглые скобки лишние. Транслятору вполне по силам выделить логическое выражение. Можно даже обойтись без ключевого слова Then. У меня здесь другое замечание. Условные операторы If с Else и без Else должны быть разными. И проблема не столько с "кочующим Else", сколько в объектном подходе. Если считать каждый оператор независимым объектом, то конструкцию без Else можно считать таковой. А объект с Else подразумевает выполнение оператора if, и еще какой-то анализ, и возможно действия. Т.е. это другое функциональное содержание. Т.е. другой класс операторов, который в себе содержит оператор If, результат действия которого нуждается в дополнительном анализе.
ВВ>Само собой при сохранении остальной си-подобности.
Как я заметил, здесь обсуждался не поставленый Вами вопрос, а вопрос необходимости фигурных скобок если в теле оператора один оператор. В общем случае лишние скобки только мешают чтению. Проблема только определить какие скобки можно назвать лишними. Т.е. все операторы можно разделить на два множества те, которые требуют чего-то обязательного после (тогда для одного оператора скобки не нужны), и множества операторов для которых наличие чего-то не обязательно. Тогда без скобок не обойтись. Именно они указывают на наличего вот этого чего-то. Отсюда вывод: Приводить к единому виду необходимо сами операторы. Тогда применение скобок будет иметь единые правила. Кстати, что я и предлагаю в своем языке. . Раздел 2 именно о скобках и группировании.

Хотел бы поставить проблему шире. Вообще применение скобок в языках.
Re[8]: Про скобочки
От: Gaperton http://gaperton.livejournal.com
Дата: 05.05.10 19:12
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

G>>Можно избавиться и от фигурных скобок, введя двумерный синтаксис. Было бы желание.


ВВ>Что такое двумерный синтаксис? Можно поподробнее?


Когда scope задается величиной отступа.

Т.е. вместо

if x { a(); b(); } else { c(); d(); }
do_something();


Мы пишем

if x 
   a()
   b()
else
   c()
   d()
do_something()


Один и только один оператор на строке, отступ задает вложенность. Много современных языков это используют. Популярный трюк — заодно и код выглядит единообразно и прилично.
Re[9]: Про скобочки
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.05.10 19:14
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


Много — это кто кроме Питона и Немерля?
... << RSDN@Home 1.2.0 alpha 4 rev. 1471 on Windows 7 6.1.7600.0>>
AVK Blog
Re[10]: Про скобочки
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.05.10 19:17
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


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


AVK>Много — это кто кроме Питона и Немерля?


Эммм, неужто ты про хаскель не в курсе?
Re[10]: Про скобочки
От: FR  
Дата: 06.05.10 08:58
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Много — это кто кроме Питона и Немерля?


F#
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.