Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну они выглядят как аналогичные операции в Си, однако "работают" не так, т.е. семантика другая.
Это ты про ++? Чем же у них семантика другая? Разве что не возвращаю значения. Ну, дык это для безопасности. Хотя можно было бы итак и не преестраховываться. В Шарпе тоже не встречал проблем из-за них. Язык все же типобзеопасный, что сильно спасает от подобных бяк. Но значение то меняют по месту. Так что семантика очень близкая. По крайней мере код с их применением на немерле будет полностью идентичен сишному.
ВВ>Честно, мне сложно представить, зачем кому-то в функциональном языке потребовались такие макросы
А где ты увидел функциональный язык? Это же не хаскель упершийся в одну парадигу.
Немерл — язык мультипарадигмынй. Он просто обязан писать в хорошем С-шном стиле. А как же этого достичь если нельзя написать классический сишный 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
{
match (this)
{
| VariantOptionA(a) => $"VariantOptionA($a)"
| VariantOptionB(b) => $"VariantOptionB($b)"
}
}
ВВ>Ага, лексический скоп, в котором нельзя объявлять имена. Фишку понял
Ну, не где.
А чем это отличается от сишного switch-а? Как мне в С или C# объявить переменную внутри switch { тут } ?
ВВ>Для вхождения я никогда не предлагал скобки. В Си тоже скобки — не единственная конструкция которая задает скоп. for, например, тоже задает скоп, независимо от наличия или отсутствия скобок. Т.е. это-то ИМХО нормально.
Если быть точным, то именно в С for скопа не задает. Это так только в С++. Но, да согласен, есть отступления.
ВВ>Это все верно, но "истина где-то рядом". Если большей части людей что-то неудобно или непривычно, то возможно это действительно плохо.
А есть много людей которых чем-то не устраивает скоп в Немерле? Он даже Питонистов удовлетворяет, так как есть #pragma indent.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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>А это и так так.
Т.е. сам же где-то писал, что параметры функцию описываются через тюпл, так зачем ограничивать одним только параметром?
По-моему сразу видно, что именно в таком случае матчится.
VD>Мы вот думали расширить это правило для методов без параметров (но экземплярных, т.е. где доступен this), чтобы можно было писать
Это тоже было бы хорошо, но ИМХО менее очевидно.
VD>А чем это отличается от сишного switch-а? Как мне в С или C# объявить переменную внутри switch { тут } ?
Мда, убил наповал
ВВ>>Для вхождения я никогда не предлагал скобки. В Си тоже скобки — не единственная конструкция которая задает скоп. for, например, тоже задает скоп, независимо от наличия или отсутствия скобок. Т.е. это-то ИМХО нормально. VD>Если быть точным, то именно в С for скопа не задает. Это так только в С++. Но, да согласен, есть отступления.
Разве в С99 не задает? Хотя по фиг в принципе.
Будем считать, что говоря С, я имею в виду C#
ВВ>>Это все верно, но "истина где-то рядом". Если большей части людей что-то неудобно или непривычно, то возможно это действительно плохо. VD>А есть много людей которых чем-то не устраивает скоп в Немерле? Он даже Питонистов удовлетворяет, так как есть #pragma indent.
Да не, я не про Немерле. Мне просто интересен фидбек от программистов, привыкших к Си-подобному синтаксису — понравилось бы им, если бы круглых скобочек стало поменьше.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>В Си есть разница между пост и пре инкрементом, я об этом.
Ну, дык в немерле его просто нельзя использовать в выражении. В С я его тоже так не использовал, так как там это может привести к действительно трудно понимаемым багам.
ВВ>А то как это сделано в Немерле — ну разница между ними просто теряет всякий смысл.
Именно. Но это же не другое поведение? Это же его ограничение. Причем намеренное.
ВВ>Я бы понял, если бы их вообще не было, а так получается, что "спец-эффект" оставили, а возвращаемое значение убрали.
Дык сам оператор полезен, а возврат значения вызывает ошибки. В дизайн языка намеренно не вносились плохие или спорные решения.
ВВ>В хорошем Сишном стиле — это с кучей спец-эффектов, опираясь на порядок операций — в Немерле это будет уже сложно, ибо много конструкций не возвращают значение в отличие от Си.
Не в хорошем, а в плохом. Плохое и устраняли. Возможно чуть-чуть переборшили. В прочем, думаю, тут еще одна причина была. Насколько я понимаю, современный парсер немела не делает различий между постфиксными и префиксными формами унарных операторов. А это делает невозможным качественную реализацию С-шных операторов. Так что придется подождать Немерл 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#
ВВ>Да не, я не про Немерле. Мне просто интересен фидбек от программистов, привыкших к Си-подобному синтаксису — понравилось бы им, если бы круглых скобочек стало поменьше.
Ну, тут все очень просто. Сколько людей столько и мнений. Но если сделать как в С, то все поймут, а если сделать по другому, то сразу появится лагерь поклонников и недовольных.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий!
ВВ>Писать скобки в случае одного выражения или не писать — это тема для отдельного флейма и вроде как такой флейм тут недавно был, смысла в его продолжении я не вижу.
В Visual Studio одно время (версия 5 и ещё 6 вроде) было нужно писать вот так:
for(;;)
{
i++;
}
для прохода в отладчике по шагам несколько итераций; вот так:
for(;;)
i++;
не получалось. Может, в новых версиях уже и можно.
Кстати, вот так:
for(;;) {
i++;
}
тоже не получалось тогда, что и явилось одним из мотивов перехода на:
Здравствуйте, 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>Ну, тут все очень просто. Сколько людей столько и мнений. Но если сделать как в С, то все поймут, а если сделать по другому, то сразу появится лагерь поклонников и недовольных.
Это верно. Стандартный выбор — сделать хорошо или привычно. А может быть, плохо или привычно. Тут уж как повезет.
Все же синтасис Си перегружен этой скобочностью, мне кажется. Тот же шарп воспроизводит его практически один-в-один (Немерле — в меньшей степени), и часто получается лес скобочек, причем с совершенно разной семантикой. И ведь в принципе можно же вполне уменьшить их количество
Это, так сказать, language dependent мотивы. Например, на JavaScript я всегда использую нотацию K&R по той простой причине, что там есть зловредный механизм под названием semicolon insertion, который по сути препроцессит файлы и может вставить лишнего.
Речь о синтаксисе все же.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Кстати, я никогда это не понимал. Все же просто, обычная последовательность операций, какая разница "в строчку" они записаны или "в столбик". Как и с оператором ассайнмента. Почему плохо то, что он возвращает значение?
Ну, тут понимание или есть сразу, или его нет вообще .
Сайд-эффекты — это вам не неправильное форматирование. Незаметный ошибочный сайд-эффект можно искать очень долго.
ВВ>Интересно. А парсер врукопашную написан?
Да. Но в следующей версии планируется использовать PEG. Он должен обеспечить как беспрецедентную расширяемость, так так и требуемую гибкость (значительно большую чем есть сейчас).
ВВ>>>Вообще бы вам весь этот хлам засунуть в Nemerle.Imperative. А то break/continue/return именно там, а for почему-то нет. VD>>mutable тоже туба?
ВВ>mutable не трожь
Не последовательно как-то.
ВВ>Он-то не мешает писать функциональный код, а вот вышеозначенное — конструкции для типичного императивного flow. Ими можно вообще не пользоваться. А вот мутабельными переменными вообще не пользоваться нельзя, все же Немерле не чистый язык.
mutable — это самая базовая императивная конструкция. Без него императив не возможен.
ВВ>Непонятно, почему я считал, что параметр должен быть один.
В психологии — это называют "ожидание худшего".
ВВ> И в статье по Немерле у тебя написано, что несколько параметров интерпретируются как кортеж. ВВ>Видимо, я напутал с OCaml-ом.
А там не так?
ВВ>Это верно. Стандартный выбор — сделать хорошо или привычно. А может быть, плохо или привычно. Тут уж как повезет.
Ну, да. По этому я лично придерживаюсь очень простого правила. Привычное надо менять только тогда когда оно создает реальные проблемы (ощутимые и не обходимые другими путями). Вот сишное приведение типов, задание типов переменных спереди, четкое выделение операторов в виде стэйтментов, делегаты в качестве замены функциональных типов и многое другое — это явно плохое. И избежание повторения таких привычных вещей легко объяснимо, а значит правильно. А вот отказ от скобок и оператора for — не объяснимо и по сути не нужно. Это привычки людей. А людей не надо ломать об колено. Им еще ФП и МП учить. Пусть уж лучше они учат их в привычной среде.
ВВ>Все же синтасис Си перегружен этой скобочностью, мне кажется.
Вы еще Лисп не видели, коллега! (с)
ВВ> Тот же шарп воспроизводит его практически один-в-один (Немерле — в меньшей степени), и часто получается лес скобочек, причем с совершенно разной семантикой. И ведь в принципе можно же вполне уменьшить их количество
А жалобы есть от тех кто С-подобные языки пользует? Нет? Ну, а что тогда копья ломать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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>А жалобы есть от тех кто С-подобные языки пользует? Нет? Ну, а что тогда копья ломать?
Здравствуйте, Воронков Василий, Вы писали:
VD>>Сайд-эффекты — это вам не неправильное форматирование. Незаметный ошибочный сайд-эффект можно искать очень долго.
ВВ>Вот объясни мне как *возвращаемое значение* может привести к *незаметному* ошибочному сайд-эффекту?
Для не внимательных выделил лопату жирным.
ВВ>Т.е. там можно составить расширяемое формальное описание грамматики?
Да. И каждый макрос будет правилом такой грамматики. Причем маклос сможет использовать любые другие правила введенные другими макросами доступными к этому времени в скомпилированном виде (т.е. подключенные к проекту).
ВВ>Дык без него вообще писать затруднительно, в том-то и дело.
Ну, почему же? ФП доказанно полон по Тьюрингу. Не всегда эффективен, не всегда достаточно гибок, но писать можно что угодно.
ВВ>Немерле же не ставит цель убрать сайд-эффекты вообще.
Нет. По этому и паранойи с вносом цилка черти куда нет.
ВВ>Однако ж "странный синтаксис" не мешает тому же Питону пользоваться большой популярностью.
Он к этому шел (идет) где-то 15 (а то и больше) лет. И до сих пор не достиг поплярности даже C#-а.
Плюс — это скрипт который часто используют для "несерьёзных целей". Это позволило ему проникнуть в массы.
Короче, можешь попытать счастье. Может твой синтаксис (тет через 15) тоже проникнет в массы.
ВВ>Вот Си-касты — плохо, согласен. А почему плохо? Невыразительный синтаксис, "сливается", не всегда и видно с первого взгляда, где тут приведение. Короче, скобочек много. И в данном случае ML-ный :> как раз альтернатива скобкам. Как do здесь:
Дело не в скобочках. Дело в том, что это контекстно зависмая грамматика. В С/С++ чтобы отличить приведение от других выражений нужно знать тип выражения внутри скобок. В C# водится эвристика которая вызвает некоторые побочные эффекты. Ну, и человек тоже плохо эти эвристики съедает. Скобки же здесь не причем. В тех же кортежах тоже скобки используются, но проблем они не вызывают.
ВВ>В Лиспе скобочек много, но семантика их всегда одинакова. Разве нет?
В лиспе семантика? Не, ну у скобок там конечно всегда семантика скобок. Но скажем список и вызов функции отличается... эээ.. ну ничем. В прочем там все список и что угодно может оказаться макросом .
VD>>А жалобы есть от тех кто С-подобные языки пользует? Нет? Ну, а что тогда копья ломать?
ВВ>А я не в счет?
Ах, ты. Да ты в счет. Итак счет 1 к скольки там?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Известно, что в Си-подобном синтаксисе круглые скобочки несколько перегружены смыслом. Это и средство для группировки выражений, и часть грамматики некоторых стандартных выражений вроде 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);
ВВ>Само собой при сохранении остальной си-подобности.
Здравствуйте, VladD2, Вы писали:
VD>Не, ну, возможно есть хроники которые ошибки месяцами выявлюят. У меня в худшем случае на сложную ошибку уходит 2-3 дня. И это точно не ошибки из разряда плохое форматирование.
Причем здесь скорость выявления причин известной ошибки? На исправление ошибки программист может и пять минут тратить, только толку от этого немного, т.к. если ошибка не шибко часто встречающаяся (и тем более без исключения), то пользователи о ней могут сообщить программисту через несколько месяцев, а то и вообще никогда. И все это время периодически натыкаясь на эту ошибку пользователи будут думать, что им вместо нормальной программы подсунули какую-то криво работающую поделку.
ВВ>>>def func(x, y) { | (2, _) => ... | (3, 1) => ... } VD>>Так оно и есть. Мог бы попробовать прежде чем писать.
ВВ>О, круто ВВ>Непонятно, почему я считал, что параметр должен быть один. И в статье по Немерле у тебя написано, что несколько параметров интерпретируются как кортеж. ВВ>Видимо, я напутал с OCaml-ом.
let func = function
| 2, _ -> 0
| 3, 1 -> 1
| x, y -> x * y
ВВ>>А там можно получить неправильную программу просто вставив лишний пробел
FR>Пробел фигня, вот неправильный таб вообще может до смертоубийства довести
Сейчас уже ничем вроде, это я просто вспомнил веселый поиск ошибки на питоне кажется версии 2.2,
которая такие вещи не отлавливала и не выдавала ни варнингов ни ошибок.
