Есть язык, с хаскеле-подобным синтаксисом (т.е. layout-based), выражения можно писать прямо в топ-левеле. Выражениями является все, кроме директив открытия модулей и глобальных let-биндингов. Однако два выражения подряд по типу:
2+2
someFunc x y
не являются особо хорошим кодом, т.к. выражения должны что-то возвращать, а если возвращаемое значение игнорируется, то, видимо, и в выражении особого смысла нету. Поэтому на код подобного рода генерируется ворнинг.
Вернее, на самом деле не так.
Код, как выше, вообще работает совсем не так, можно подумать. Т.е. для выражений на топ-левеле layout свободный, поэтому можно писать так:
Однако как в первом случае писать нельзя, ибо такое выражение будет в реальности интерпретировано как:
(+) 2 2 someFunc x y
И здесь-то и кроется проблема.
С одной стороны — все логично. Нельзя писать код, который все равно приводил бы к ворнингам. С другой — нарушаются правила layout-а, и код, который кажется внешне правильным, приводит к весьма странной ошибке типа. Однако если включить layout для выражений на топ-левеле, то два предыдущих примера сразу же станут некорректными. Например, if придется писать так:
ВВ>Есть такая идеологическая проблема.
ВВ>Есть язык, с хаскеле-подобным синтаксисом (т.е. layout-based), выражения можно писать прямо в топ-левеле. Выражениями является все, кроме директив открытия модулей и глобальных let-биндингов. Однако два выражения подряд по типу:
ВВ>
ВВ>2+2
ВВ>someFunc x y
ВВ>
ВВ>не являются особо хорошим кодом, т.к. выражения должны что-то возвращать, а если возвращаемое значение игнорируется, то, видимо, и в выражении особого смысла нету. Поэтому на код подобного рода генерируется ворнинг.
А как же сайд-эффекты? print "Hello world" ?
ВВ>Какое из двух зол лучше?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Воронков Василий, Вы писали: ВВ>>Есть такая идеологическая проблема. FR>Разделители не помогут, например как в OCaml ';;' ?
Разделитель на самом деле есть — ($). Т.е. можно так:
2+2 $
myfun x y
Но по сути это скорее ближе к seq в хаскеле.
В реальности так и пишется сейчас, и это в общем правильно, т.к. бакс явно говорит, что нужно проигнорировать значение слева и вернуть значение справа, и к тому же раскручивает санки.
Но проблема в том, что синтаксис все же построен на отступах — поэтому иногда возникают ситуации, когда два выражения идут подряд в топ-левеле, и чисто визуально они воспринмаются как два разных выражения. А в действительности это не так — и в итоге получаются весьма странные ошибки.
Здравствуйте, Temoto, Вы писали:
ВВ>>не являются особо хорошим кодом, т.к. выражения должны что-то возвращать, а если возвращаемое значение игнорируется, то, видимо, и в выражении особого смысла нету. Поэтому на код подобного рода генерируется ворнинг. T>А как же сайд-эффекты? print "Hello world" ?
В реальности сейчас такой print может быть только foreign функцией. И для нее таки будет сгенерирован ворнинг. Отчасти это правильно, т.к. если возникают побочные эффекты, то надо избавляться от санков, и явно декларировать порядок выполнения.
Если код прям именно такой, то можно просто написать так:
let _ = print "Hello, world!"
и ворнинга не будет.
Но с т.з. самого языка — все равно это обычная функция, которая должна возвращать какое-то полезное значение.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Но проблема в том, что синтаксис все же построен на отступах — поэтому иногда возникают ситуации, когда два выражения идут подряд в топ-левеле, и чисто визуально они воспринмаются как два разных выражения. А в действительности это не так — и в итоге получаются весьма странные ошибки.
Может тогда стоит сделать как в интерпретаторе питона, нажатие enter после ':' переводит в режим с отступами
(рисуются ... слева) при этом работает только ввод без интерпретации, ввод пустой строки снова запускает
интерпретатор.
Здравствуйте, FR, Вы писали:
FR>Может тогда стоит сделать как в интерпретаторе питона, нажатие enter после ':' переводит в режим с отступами FR>(рисуются ... слева) при этом работает только ввод без интерпретации, ввод пустой строки снова запускает FR>интерпретатор.
Так я ж не про Репл. В Репле-то как раз ;; используется.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Кстати, мне казалось, что тебе вариант описания лямбды вида "(x,y)=>x+y" нравится больше, чем "fun(x,y) {x+y}". Или что-то поменялось с тех пор?
Да, больше. Но он не самодостаточен. Скажем нельзя описать тип возвращаемого значения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ВВ>>Кстати, мне казалось, что тебе вариант описания лямбды вида "(x,y)=>x+y" нравится больше, чем "fun(x,y) {x+y}". Или что-то поменялось с тех пор? VD>Да, больше. Но он не самодостаточен. Скажем нельзя описать тип возвращаемого значения.
Ну то есть отсутствие скобочек тебе не мешает?
def sum = (x,y) => x+y
-1;
Кстати, с т.з. синтаксиса никто не мешает тип приписать: "(x:int,y:int):int=>x+y"
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну то есть отсутствие скобочек тебе не мешает?
ВВ>
ВВ>def sum = (x,y) => x+y
ВВ>-1;
ВВ>
В выражениях — нет. Когде же речь идет о группировке стэйтментов/выражений — скобки очень способствуют восприятию и навигации.
Потом, лично моя логика очень простая. Большинство программистов воспитаны на сишных скобках. Можно сказать, что они впитали их с молоком матери. Зачем ссать против ветра?
Создав язык с удобным тебе синтаксисом не стоит ожидать, то он будет нравится массам. Нужно потакать привычкам окружающих. Пусть даже эти привычки кажутся тебе дурными.
ВВ>Кстати, с т.з. синтаксиса никто не мешает тип приписать: "(x:int,y:int):int=>x+y"
Для Немерла — да. Но в макросе он не реализован. В 99% это не нужно. А для оставшегося процента есть исходный (ML-й) синтаксис. Для Шарпа, скорее всего, будет проблемы, так как синтаксис описания типа возвращаемого значения не регулярный.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В выражениях — нет. Когде же речь идет о группировке стэйтментов/выражений — скобки очень способствуют восприятию и навигации. VD>Потом, лично моя логика очень простая. Большинство программистов воспитаны на сишных скобках. Можно сказать, что они впитали их с молоком матери. Зачем ссать против ветра?
Что такое "группировка стэйтментов/выражений"? Два выражения подряд в Си без всяких скобочек пишутся. Обсуждаемое в разрезе Си-подобного синтаксиса аналогично следующему:
x+y
-z;
Точку с запятой забыли на первой строке — и получили одно выражение, а не два. Выглядит как два, на самом деле — одно. Ты мне так что ли предлагаешь писать:
{x+y}
{-z}
Скобочки в Си обычно лексический скоп отмечают, но речь-то не об этом. Хаскелл, кстати, скобочки поддерживает в качестве альтернативного синтаксиса, но выглядит — страх и ужас.
VD>Создав язык с удобным тебе синтаксисом не стоит ожидать, то он будет нравится массам. Нужно потакать привычкам окружающих. Пусть даже эти привычки кажутся тебе дурными.
Что нравится массам — вопрос загадочный. Ты Луа знаешь? Там синтаксис — лютый коктейль из всего на свете. Однако массам нравится, и в своей нише первее всех.
ВВ>>Кстати, с т.з. синтаксиса никто не мешает тип приписать: "(x:int,y:int):int=>x+y" VD>Для Немерла — да. Но в макросе он не реализован. В 99% это не нужно. А для оставшегося процента есть исходный (ML-й) синтаксис. Для Шарпа, скорее всего, будет проблемы, так как синтаксис описания типа возвращаемого значения не регулярный.
Главное отличие этого синтаксиса от fun, не считая дурацкого слова "fun" (весело, что ли, кому-то? ) — это отсутствие скобочек. Почему ты считаешь, что здесь скобочки не нужны? И куда предлагаешь их засунуть?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Что такое "группировка стэйтментов/выражений"? Два выражения подряд в Си без всяких скобочек пишутся. Обсуждаемое в разрезе Си-подобного синтаксиса аналогично следующему:
ВВ>
ВВ>x+y
ВВ>-z;
ВВ>
Не пишутся. Не выдумывай. Стэйтменты могут идти подряд только в рамках блока. Иначе:
if (c)
b;
c;
и приплыли.
ВВ>Точку с запятой забыли на первой строке — и получили одно выражение, а не два.
Это уже отдельный вопрос к теме не относящийся. Если забыли, то будет один стейтмент/выражение. Хочешь обсудить способы борьбы с этим?
ВВ> Выглядит как два, на самом деле — одно.
Как что выглядит мало кого интересует. В правильных языках тебя об этом предупредят.
ВВ>Ты мне так что ли предлагаешь писать:
ВВ>
ВВ>{x+y}
ВВ>{-z}
ВВ>
Я не вижу смысла в данном коде. Потому как тут по фигу как писать.
В реальном коде первое выражение будет ошибкой. Об этом и должен сказать компилятор. Вычисленное значение не должно теряться.
ВВ>Скобочки в Си обычно лексический скоп отмечают, но речь-то не об этом. Хаскелл, кстати, скобочки поддерживает в качестве альтернативного синтаксиса, но выглядит — страх и ужас.
Ага. Он в любом варианте для гражданского населения страх и ужас.
Ты же об отступах речь вел. Вот скобки и решают все проблемы с отступами.
ВВ>Что нравится массам — вопрос загадочный. Ты Луа знаешь? Там синтаксис — лютый коктейль из всего на свете. Однако массам нравится, и в своей нише первее всех.
Дык и популярность у Луа чуть выше Хаскеля, не смотря на серьезную поддержку. Отказались бы еще от скобок у вызовов функций и популярности было бы еще меньше.
ВВ>Главное отличие этого синтаксиса от fun, не считая дурацкого слова "fun"
А чё же его не считать то? Он самый дурацкий и есть. Занимает много места и практически ничего не дает. А вот разница с (x){ ... } была бы уже не такая значительная. В Котлине сделали: { x -> ... }, например.
ВВ>(весело, что ли, кому-то? ) — это отсутствие скобочек.
Сам же первым делом сказал про fun.
ВВ>Почему ты считаешь, что здесь скобочки не нужны? И куда предлагаешь их засунуть?
Я к этому вопросу подхожу так... В нутри выражения фигурные скобки не желательны. Их место на уровне блоков. А блоки относятся к стэйтментам, функциям и т.п. Другими словами к структуре программы. Вот там скобки на своем месте. По сему лямбды и операторы вроде if-а в скобках не нуждаются. А как только речь заходит о группировке нескольких выражений, то они становятся нужны.
В прочем, я не отрицаю отступного синтаксиса. Но как видишь с ним бывают проблемы. Да и не привычен он для многих.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Вот уже который раз наблюдаю твои споры по поводу синтаксиса. Пичаль. Ты ведь заправила по синтаксису. Почему нет царя в голове? Почему нет понимания каким целям он служит? Желательны-нежелательны, вкусовщина. Вот читаю я это всё и в Н не верю. Синтаксис основа, а нет ни логического его у тебя обоснования ни философского.
Здравствуйте, VladD2, Вы писали:
ВВ>>Точку с запятой забыли на первой строке — и получили одно выражение, а не два. VD>Это уже отдельный вопрос к теме не относящийся. Если забыли, то будет один стейтмент/выражение. Хочешь обсудить способы борьбы с этим?
Это как раз вопрос, который и относится к теме — в отличие от скобочек. Речь именно об этом. Так как layout не включен для выражений на топ-левеле их необходимо разделяться через sequencing оператор. Если оператор забыть, то выражения на разных строках склеиваются.
ВВ>> Выглядит как два, на самом деле — одно. VD>Как что выглядит мало кого интересует. В правильных языках тебя об этом предупредят.
В каких?
ВВ>>
ВВ>>{x+y}
ВВ>>{-z}
ВВ>>
VD>Я не вижу смысла в данном коде. Потому как тут по фигу как писать.
Смысла здесь не больше и не меньше, чем в:
func1 x y
func2 x
Две апликации. Или одна? Вот в чем вопрос
VD>В реальном коде первое выражение будет ошибкой. Об этом и должен сказать компилятор. Вычисленное значение не должно теряться.
Предупредит. Но речь не об этом. К тому же, если это выражение является последним в блоке, то предупреждения не будет — значение ведь не теряется. Поэтому на ворнинг тут расчитывать не приходится.
В приведенном примере кода "правильное" поведение такое:
+ дать ворнинг на аплкацию func1 (результат не используется)
+ вернуть результат апликации func2
Но если забыть sequencing, то получится одна апликация и, как следствие, ошибка типа. Весьма неочевидная к тому же.
ВВ>>Скобочки в Си обычно лексический скоп отмечают, но речь-то не об этом. Хаскелл, кстати, скобочки поддерживает в качестве альтернативного синтаксиса, но выглядит — страх и ужас. VD>Ага. Он в любом варианте для гражданского населения страх и ужас.
Гражданское население пугается того, что тип-аннотации в Немерле пишутся не так, как в шарпе. И что?
Синтаксис Хаскелла довольно прост, в отличие от си-подобного, и проектировался под функциональные язык, в отличие от си-подобного.
VD>Ты же об отступах речь вел. Вот скобки и решают все проблемы с отступами.
Нет. Речь о многострочных выражениях. Включение отступов как раз *решает* эту проблему.
ВВ>>Что нравится массам — вопрос загадочный. Ты Луа знаешь? Там синтаксис — лютый коктейль из всего на свете. Однако массам нравится, и в своей нише первее всех. VD>Дык и популярность у Луа чуть выше Хаскеля, не смотря на серьезную поддержку. Отказались бы еще от скобок у вызовов функций и популярности было бы еще меньше.
Луа — самый популярный язык для ембединга. Кстати, скобки при вызове функций там ряде случаев можно опускать.
Руководствуясь твоей логикой, Хаскелл был бы популярней, если бы имел Си-подобный синтаксис — я думаю, это не так.
ВВ>>Главное отличие этого синтаксиса от fun, не считая дурацкого слова "fun" VD>А чё же его не считать то? Он самый дурацкий и есть. Занимает много места и практически ничего не дает. А вот разница с (x){ ... } была бы уже не такая значительная. В Котлине сделали: { x -> ... }, например.
fun — три символа. => два. Экономия небольшая.
Продаю идею синтаксиса для лямд:
\(x,y) x + y
и парсить проще, чем шарповый.
ВВ>>Почему ты считаешь, что здесь скобочки не нужны? И куда предлагаешь их засунуть? VD>Я к этому вопросу подхожу так... В нутри выражения фигурные скобки не желательны. Их место на уровне блоков. А блоки относятся к стэйтментам, функциям и т.п. Другими словами к структуре программы. Вот там скобки на своем месте. По сему лямбды и операторы вроде if-а в скобках не нуждаются. А как только речь заходит о группировке нескольких выражений, то они становятся нужны.
Однако { что-то там } в Немерле в свою очередь так же является выражением. Если мне не изменяет память, даже код вида {x}+{y} является корректным.
Си-подобный синтаксис вообще неплохой, но он задумывался для императивного языка с четким разделением на выражения и стейтменты. Когда это разделение убирается, то получает чехарда с тем, что блок {} сам по себе становится выражением, а точка с запятой иногда обязательна, а иногда — нет.
VD>В прочем, я не отрицаю отступного синтаксиса. Но как видишь с ним бывают проблемы. Да и не привычен он для многих.
Здравствуйте, grosborn, Вы писали:
G>Вот уже который раз наблюдаю твои споры по поводу синтаксиса. Пичаль. Ты ведь заправила по синтаксису. Почему нет царя в голове? Почему нет понимания каким целям он служит? Желательны-нежелательны, вкусовщина. Вот читаю я это всё и в Н не верю. Синтаксис основа, а нет ни логического его у тебя обоснования ни философского.
Обоснуй. А то заправилам меня пичаль от тваяго саабщения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
> G>Вот уже который раз наблюдаю твои споры по поводу синтаксиса. Пичаль. Ты ведь заправила по синтаксису. Почему нет царя в голове? Почему нет понимания каким целям он служит? Желательны-нежелательны, вкусовщина. Вот читаю я это всё и в Н не верю. Синтаксис основа, а нет ни логического его у тебя обоснования ни философского. > > Обоснуй. А то заправилам меня пичаль от тваяго саабщения.
Я ни разу не видел что бы ты как-то обосновывал свое мнение по синтаксису. Все обсуждения что я читал, синтаксис вы обсуждаете на уровне нравится/не нравится. И даже где-то открыто было — вкусовщина. И вэтой ветке так же.
Особенно меня задевает отступной синтаксис. Как можно не понимать, что это абсолютно неприемлемо для любого языка, который использует человек? Мы же не для дроидов языки создаем, <скипнуто сумбурное философское обоснование>
Нужно иметь четкие критерии позволяющие обоснованно подходить к формированию синтаксиса. Нужно понимать, что в процессе работы с этим синтаксисом, часть (текст программы -> программа) это мизерная часть. Основная задача синтаксиса, это не "оптимальное выражение инструкций препроцессору и компилятору". Основная задача синтаксиса, это документирование этих инструкций. Процесс работы с текстом программы, это многократное перечитывание и переписывание. Сокращая синтаксис, мы вроде бы как сокращаем затраты на переписывание, а поскольку это система, сокращая синтаксис и усложняя перечитывание (неинтуитивные соглашения) и понимание(не поддерживая структуру), мы увеличиваем объем переписывания.
Синтаксис — для человека, не для компилятора. Синтаксис должен отвечать целям документировани и понимания. Соглашения должны быть систематичны.
}
