Здравствуйте, Воронков Василий, Вы писали:
ВВ>Вообще было бы интересно, если бы рассказал, какие были причины для введения именно второго варианта (с перекрытием) в Немерле, когда вот создатели Шарпа сочли его опасным. (Я подозреваю, что это может быть косвенно связано с матчем).
Здравствуйте, VladD2, Вы писали:
ВВ>>Понятно, *почему* такой код работает, но ведь с т.з. пользователя тут не создается никаких функций и это выглядит так, как если бы некоторые лексические блоки были "более равны" чем другие. VD>Я в этом тоже виноват? Или мне нужно было спросить о причинах у Липперта или Меерса?
Причем тут ты-то? Я просто привел пример, который мне кажется не очень красивым поведением скопинга. Равно как и:
{
var x = 2;
}
var x = 3;//error, variable already defined
Абсолютно бессмысленная, на мой взгляд, ошибка. И, кстати, ты тут тоже совсем не виноват
ВВ>>Аналогично и с match. Match, на мой взгляд, конструкция, которой очень нужен лексический скоп, именно перекрывающий родительский. Причем каждому вхождению match-а. Вместо того, чтобы вводить match как некий "особенный" лексический скоп, имеющий больше прав, чем какой-нибудь if, вполне логично сделать все блоки перекрывающими. VD>Еще неплохо вспомнить о том, что if — это макрос реализованные через match.
Да, точно
VD>На этот вопрос я уже отвечал. Не нравится мой ответ — гугль тебе в руки. VD>def не имеет семантики присвоения (изменения значения) и не подвержен синдрому случайного изменения. Что тут непонятного?
Непонятно, почему это сразу спасает нас от всех проблем так, что даже ворнинг не надо генерировать
Пример, который ты приводил, может прекрасно привести к некорректному результату и при иммутабельной переменной, которая "неожиданно для программиста" что-то там такое перекроет в родительском скопе.
Помнится, я когда-то на одном проекте дико мучался с выбенетом — отвык от васика, видимо. Так как для меня имена FILENAME и fileName просто подсознательно воспринимаются как разные, то я получал перекрытие *константы* FILENAME переменной fileName, которая, причем, приходила из внешнего контекста и даже не менялась. Т.е. налицо была, так сказать, полная иммутабельность. А неудобство было.
ВВ>>Нет, эти вопросы напрямую не связаны с Немерле. Просто он тут под руку все время подворачивается. На самом деле я пишу свой интерпретатор VD>А, ну, успехов. Но все равно, если ты пытаешься понять дизайн другого языка, то лучше это делать на практике.
Да, ты прав. Тогда, наверное, все такие вопросы отпадут. Кстати, раз уж зашла речь, а не скажешь, зачем нужен в Немерле оператор "=="?
VD>Кстати, немерле идеальный язык для создания интерпретаторов и компиляторов. Вот мог бы его и применить. За одно изучил бы.
Я очень даже хорошо представляю, как Немерле — да впрочем любой ФЯ — может упростить реализацию компилятора. А вот как он поможет в написании стек-машины?
Потом в шарпе все же есть конструкция switch, которая, при соблюдении должных пассов, транслируется в CIL switch с константным доступом. А на Немерле как? Только через match?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Причем тут ты-то? Я просто привел пример, который мне кажется не очень красивым поведением скопинга. Равно как и:
ВВ>
ВВ>{
ВВ> var x = 2;
ВВ>}
ВВ>var x = 3;//error, variable already defined
ВВ>
+1
ВВ>Абсолютно бессмысленная, на мой взгляд, ошибка. И, кстати, ты тут тоже совсем не виноват
+1
ВВ>Непонятно, почему это сразу спасает нас от всех проблем так, что даже ворнинг не надо генерировать
Дык нет проблем, не от чего и спасаться.
ВВ>Пример, который ты приводил, может прекрасно привести к некорректному результату и при иммутабельной переменной, которая "неожиданно для программиста" что-то там такое перекроет в родительском скопе.
Не может.
ВВ>Да, ты прав. Тогда, наверное, все такие вопросы отпадут. Кстати, раз уж зашла речь, а не скажешь, зачем нужен в Немерле оператор "=="?
Для перегрузки
ВВ>Я очень даже хорошо представляю, как Немерле — да впрочем любой ФЯ — может упростить реализацию компилятора. А вот как он поможет в написании стек-машины?
Он позволит тебе написать ДСЛ и генерить код по этому ДСЛ-ю.
ВВ>Потом в шарпе все же есть конструкция switch, которая, при соблюдении должных пассов, транслируется в CIL switch с константным доступом. А на Немерле как? Только через match?
Причем тут switch? Я не привык к таким переходам.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ВВ>>Да, ты прав. Тогда, наверное, все такие вопросы отпадут. Кстати, раз уж зашла речь, а не скажешь, зачем нужен в Немерле оператор "=="? VD>Для перегрузки
О, точно
Кстати, а оператор ассайнмента ("=") перегружать можно?
ВВ>>Я очень даже хорошо представляю, как Немерле — да впрочем любой ФЯ — может упростить реализацию компилятора. А вот как он поможет в написании стек-машины? VD>Он позволит тебе написать ДСЛ и генерить код по этому ДСЛ-ю.
А можно немного поподробнее? Я могу как-то управлять генерацией IL-кода из макроса?
ВВ>>Потом в шарпе все же есть конструкция switch, которая, при соблюдении должных пассов, транслируется в CIL switch с константным доступом. А на Немерле как? Только через match? VD>Причем тут switch? Я не привык к таким переходам.
У нас есть некий набор инструкций, порядка 50, мы по сути бежим по ним и выполняем то или иное действие в зависимости от инструкции. У инструкций разный размер. Ну т.е. типа:
switch (op)
{
case OpCode.Push: ...
case OpCode.Pop: ...
case OpCode.Add: ...
}
и так далее. Свитч в шарпе довольно быстрая штука при аккуратном использовании — ну в частности надо соблюдать чтобы диапазон выборки был без провалов. Свитч вида case 100, case 200 и пр. в CIL swithc конечно не отранслируется.
А как бы я писал этот код на Немерле? Матч вряд ли сможет породить такой же быстрый код, или я ошибаюсь?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А вам какая модель больше нравится:
Однозначно вторая.
ВВ>И почему, если можно
Вторая модель развязывает внешнюю и внутреннюю области видимости.
Т.е. если у меня есть куча внутренних областей, то я совсем не буду счастлив, добавив нечто во внешнюю область, получить ошибки компиляции во внутренних, о которых я ни сном, ни духом.
И наоборот — я могу писать что угодно во внутренних областях, называть переменные как мне нравится, и мне чихать на то, что там вовне.
Здравствуйте, jazzer, Вы писали:
J>Вторая модель развязывает внешнюю и внутреннюю области видимости. J>Т.е. если у меня есть куча внутренних областей, то я совсем не буду счастлив, добавив нечто во внешнюю область, получить ошибки компиляции во внутренних, о которых я ни сном, ни духом. J>И наоборот — я могу писать что угодно во внутренних областях, называть переменные как мне нравится, и мне чихать на то, что там вовне.
А имеет ли смысл неявно потакать загромождению пространства имен , и уж тем более смешиванию внешних и внутренних областей ?
