Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, gandjustas, Вы писали:
G>>Никакой путаницы нет. Макросы nemerle позволяют создавать также операторы и функции, в поведением, которое невозможно предсказать при просмотре функции.
Z>Чем вызов макроса в данном случае отличается от вызова функции? Если не видеть ее кода и документации точно так же нельзя сказать, что она делает.
В том что семантика вызова функции четко определена, а макрос — нет. Во что он превратится можно сказать глядя только в исходный код.
Тут уже пробегал пример с макросом в виде функции, который вычисляет аргументы лениво, а не энергично.
Здравствуйте, gandjustas, Вы писали:
G>В том что семантика вызова функции четко определена, а макрос — нет. Во что он превратится можно сказать глядя только в исходный код.
Во что превратится вызов виртуальной функции (лямбды, или метода интерфейса, за примером далеко ходить не нужно) можно сказать только зная эту функцию.
Здравствуйте, hardcase, Вы писали:
G>>В том что семантика вызова функции четко определена, а макрос — нет. Во что он превратится можно сказать глядя только в исходный код.
H>Во что превратится вызов виртуальной функции (лямбды, или метода интерфейса, за примером далеко ходить не нужно) можно сказать только зная эту функцию.
Вызов гарантированно превратится в вызов. А вызов макроса — во что угодно.
Здравствуйте, Lloyd, Вы писали:
H>>Во что превратится вызов виртуальной функции (лямбды, или метода интерфейса, за примером далеко ходить не нужно) можно сказать только зная эту функцию.
L>Вызов гарантированно превратится в вызов. А вызов макроса — во что угодно.
Ок, перефразирую. Какова будет семантика виртуальной функции?
Здравствуйте, hardcase, Вы писали:
L>>Вызов гарантированно превратится в вызов. А вызов макроса — во что угодно.
H>Ок, перефразирую. Какова будет семантика виртуальной функции?
Да я даже не смогу ответить какова она у обычной функции. Ничего банального, кроме "вызов функции — это вызов функции" голову не приходит.
Это настолько базовое понятие, что фик знает, как его объяснить в более простых терминах.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
G>>В том что семантика вызова функции четко определена, а макрос — нет. Во что он превратится можно сказать глядя только в исходный код.
H>Во что превратится вызов виртуальной функции (лямбды, или метода интерфейса, за примером далеко ходить не нужно) можно сказать только зная эту функцию.
Да ну? Глядя на функцию в haskell можно о ней сказать очень много. Кроме того заранее известен порядок вычислений аргументов: ленивый\энергичный, слева направо, справа налево, выпадание NRE в случае вызова функции для null значения, частичное применение итп
Здравствуйте, gandjustas, Вы писали:
H>>Во что превратится вызов виртуальной функции (лямбды, или метода интерфейса, за примером далеко ходить не нужно) можно сказать только зная эту функцию.
G>Да ну? Глядя на функцию в haskell можно о ней сказать очень много. Кроме того заранее известен порядок вычислений аргументов: ленивый\энергичный, слева направо, справа налево, выпадание NRE в случае вызова функции для null значения, частичное применение итп
Ок. Вернемся к "семантике вызова макроса". Она также известна: макрос (уровня выражения) получает на вход AST, выполняет некие вычисления в компайл тайме и, наконец, возвращает новое AST. Понятие "порядок вычисления аргументов" для макроса значительно отличается от функций — его аргументы вычисляются в процессе компиляции. Что делает функция можно понять из документации к ней, а то КАК именно она это делает — лишь из её исходного кода. Это утверждение справедливо для макроса: его задачу можно узнать из документации, его реализацию — лишь из исходников.
И, собственно, ключевой вопрос — как порядок вычисления аргументов поможет мне понять семантику прежде не известной мне функции?
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Во что превратится вызов виртуальной функции (лямбды, или метода интерфейса, за примером далеко ходить не нужно) можно сказать только зная эту функцию.
G>>Да ну? Глядя на функцию в haskell можно о ней сказать очень много. Кроме того заранее известен порядок вычислений аргументов: ленивый\энергичный, слева направо, справа налево, выпадание NRE в случае вызова функции для null значения, частичное применение итп
H>Ок. Вернемся к "семантике вызова макроса". Она также известна: макрос (уровня выражения) получает на вход AST, выполняет некие вычисления в компайл тайме и, наконец, возвращает новое AST. Понятие "порядок вычисления аргументов" для макроса значительно отличается от функций — его аргументы вычисляются в процессе компиляции. Что делает функция можно понять из документации к ней, а то КАК именно она это делает — лишь из её исходного кода. Это утверждение справедливо для макроса: его задачу можно узнать из документации, его реализацию — лишь из исходников.
H>И, собственно, ключевой вопрос — как порядок вычисления аргументов поможет мне понять семантику прежде не известной мне функции?
Да спокойно. Ты знаешь в каком порядке вычислятся аргументы при вызове функции, то есть ты точно будешь знать порядок сайд-эффектов. Глядя на макрос, который выглядит также как функция, ты этого не узнаешь. Может вообще макрос выкининет вычисление.
Сейчас вот изобретают async для C#5, там семантика известна заранее и соответствует семантике обычного выражения, а макросы позволяют делать выражения с любой семантиков, независимо от того как они выглядят. Это слишком большая пушка для отстрела ног.
Я бы вообще предложил запретить по-умолчанию кастомные синтаксические макросы, оставить только макросы в виде атрибутов и макросы "изкаропки".
Любая дополнительная фича в языке находится на стыке (1) "запас карман не тяготит" (2) "лишний член --- жопе непонятка".
Система макросов Nemerle не является интуитивно простой и понятной, поэтому естественно, сразу же приходят мысли о (2). Посему нужны веские доказательства их полезности на примере решения типичных проблем: описание задачи, решение на Nemerle, решение на другом языке прогаммирования. Или как-либо библиотек (Imperative не подходит, потому что большинство примитивов и так реализованы в других языках программирования).
Здравствуйте, gandjustas, Вы писали:
H>>И, собственно, ключевой вопрос — как порядок вычисления аргументов поможет мне понять семантику прежде не известной мне функции? G>Да спокойно. Ты знаешь в каком порядке вычислятся аргументы при вызове функции, то есть ты точно будешь знать порядок сайд-эффектов. Глядя на макрос, который выглядит также как функция, ты этого не узнаешь. Может вообще макрос выкининет вычисление.
Это следствие самой их сути — трансформации кода. Аргументы макроса это не какая-то величина, которая будет вычислена во время работы программы, — это тот код который был подставлен в макрос. Так вот эта трансформация (работа с аргументами) описывается в документации к макросу.
G>Сейчас вот изобретают async для C#5, там семантика известна заранее и соответствует семантике обычного выражения, а макросы позволяют делать выражения с любой семантиков, независимо от того как они выглядят. Это слишком большая пушка для отстрела ног.
Перефразируя: макросы — зло, потому что они позволяют менять семантику кода (это одно из их предназначений)?
G>Я бы вообще предложил запретить по-умолчанию кастомные синтаксические макросы, оставить только макросы в виде атрибутов и макросы "изкаропки".
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>И, собственно, ключевой вопрос — как порядок вычисления аргументов поможет мне понять семантику прежде не известной мне функции? G>>Да спокойно. Ты знаешь в каком порядке вычислятся аргументы при вызове функции, то есть ты точно будешь знать порядок сайд-эффектов. Глядя на макрос, который выглядит также как функция, ты этого не узнаешь. Может вообще макрос выкининет вычисление.
H>Это следствие самой их сути — трансформации кода. Аргументы макроса это не какая-то величина, которая будет вычислена во время работы программы, — это тот код который был подставлен в макрос. Так вот эта трансформация (работа с аргументами) описывается в документации к макросу.
Спасибо, кэп.
G>>Сейчас вот изобретают async для C#5, там семантика известна заранее и соответствует семантике обычного выражения, а макросы позволяют делать выражения с любой семантиков, независимо от того как они выглядят. Это слишком большая пушка для отстрела ног. H>Перефразируя: макросы — зло, потому что они позволяют менять семантику кода (это одно из их предназначений)?
Не-а. макросы — зло, потому что они позволяют менять семантику кода без изменения самого кода. Ну собственно проблема та же, что и макросов в C. Только в nemerle можно сделать более умные макросы.
G>>Я бы вообще предложил запретить по-умолчанию кастомные синтаксические макросы, оставить только макросы в виде атрибутов и макросы "изкаропки". H>Это решается административными мерами.
Административные меры без энфорсинга со стороны инструментов не работают.
Лично меня интересут макросы для кодогенерации зависящих от внешних факторов.
По сути для меня лично устроили бы более продвинутые аналоги Т4, для автоматической генерации при изменении внешних факторов.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, gandjustas, Вы писали:
G>В том что семантика вызова функции четко определена, а макрос — нет. Во что он превратится можно сказать глядя только в исходный код.
Семантика раскрытия макроса определена не менее четко.
Вот только при чтении кода — это совершенно фиолетово. Точно так же по фигу семантика вызова, важно что функция делает. Какой смысл она несет для программиста. А вот это можно понять только из ее имени и исходного кода.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
L>Такое знание того, что в данном месте будет вызов. Ваш к.о.
Это, кстати, ни разу не факт. Инлайнинг пока что никто не отменял.
Но главное, что для понимания происходящего в коде это совершенно фиолетово. Не зная семантики функции ты не поймешь, что делает код. А зная семантику макроса (не того что он раскрывается или того в какой код, а именно того к чему приводит использование
L>>>А вызов макроса... VD>>в его раскрытие. Гарантия 100%
L>Уже ошибся. Или ты не видишь различия между компиляцией и выполнением?
Я не вижу влияния этого на понимание кода. И знаешь почему? Его нет. А есть только понятный код и не понятный. Макросы это возможност сделать код понятнее. Если использовать их с умом, то ничего страшного в них нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
L>>Такое знание того, что в данном месте будет вызов. Ваш к.о.
VD>Это, кстати, ни разу не факт. Инлайнинг пока что никто не отменял.
Это не меняет семантики вызова.
VD>Но главное, что для понимания происходящего в коде это совершенно фиолетово. Не зная семантики функции ты не поймешь, что делает код.
Это не так, происходит вызов.
VD>А зная семантику макроса (не того что он раскрывается или того в какой код, а именно того к чему приводит использование
"А зная семантику макроса" что?
L>>>>А вызов макроса... VD>>>в его раскрытие. Гарантия 100%
L>>Уже ошибся. Или ты не видишь различия между компиляцией и выполнением?
VD>Я не вижу влияния этого на понимание кода. И знаешь почему? Его нет.
Зато есть незаметная подмена. Но ее заметили, теперь ты начинаешь убеждать, что так и должно быть.
VD>А есть только понятный код и не понятный. Макросы это возможност сделать код понятнее. Если использовать их с умом, то ничего страшного в них нет.
Аргументы с годами не меняются, опять к уму аппелируете. Если пользовать с умом, то ничего не страшно.
Знаешь чем такая аргументация, как у тебя хороша? Всегда можно будет объяснить любую проблему отсутствие ума у собеседника. Удобно.
Здравствуйте, Lloyd, Вы писали:
VD>>Это, кстати, ни разу не факт. Инлайнинг пока что никто не отменял.
L>Это не меняет семантики вызова.
Нет никакой семантики вызова. Чушь это. Всем интересно что делает конкретный код. И никому не интересные детали "вызова", которого может не быть и который может закончиться исключением.
VD>>Но главное, что для понимания происходящего в коде это совершенно фиолетово. Не зная семантики функции ты не поймешь, что делает код.
L>Это не так, происходит вызов.
Ты очередной раз пытаешься выдать свои домыслы за реальность.
L>"А зная семантику макроса" что?
Ты поймешь что происходит. Но объяснять это теоретикам-трепачам бесполезно. Они так и будут нести пургу на основании своих домыслов.
L>Аргументы с годами не меняются,
Аргументы есть аргументы. Это только пурга и бред с кодами меняться может. А аргументы, они или есть или нет. У тебя вот нет.
Ты главное не пробуй то о чем рассуждаешь. А то потом посмеяться будет не над кем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>Это, кстати, ни разу не факт. Инлайнинг пока что никто не отменял.
L>>Это не меняет семантики вызова.
VD>Нет никакой семантики вызова. Чушь это.
Вы в очередной раз бредите, уважаемый.
VD>Всем интересно что делает конкретный код. И никому не интересные детали "вызова", которого может не быть и который может закончиться исключением.
Ну вот ты окончательно и доопределил семантику вызова. Садись, пятерка.
VD>>>Но главное, что для понимания происходящего в коде это совершенно фиолетово. Не зная семантики функции ты не поймешь, что делает код.
L>>Это не так, происходит вызов.
VD>Ты очередной раз пытаешься выдать свои домыслы за реальность.
Отнюдь.
L>>"А зная семантику макроса" что?
VD>Ты поймешь что происходит. Но объяснять это теоретикам-трепачам бесполезно. Они так и будут нести пургу на основании своих домыслов.
Бсполезно потому что аргументов у хамов-практиков — раз-два и обчелся. Да и эти раз-два на проверку оказываются пуком в лужу.
L>>Аргументы с годами не меняются,
VD>Аргументы есть аргументы. Это только пурга и бред с кодами меняться может. А аргументы, они или есть или нет. У тебя вот нет.
Правильно сделал, что про "ум" не отквотил. Действительно выглядело чутка глуповато.
VD>Ты главное не пробуй то о чем рассуждаешь. А то потом посмеяться будет не над кем.
Да я-то пробовал. Как о чем-то можно судить, не пробуя этого?
Здравствуйте, gandjustas, Вы писали:
G>>>Сейчас вот изобретают async для C#5, там семантика известна заранее и соответствует семантике обычного выражения, а макросы позволяют делать выражения с любой семантиков, независимо от того как они выглядят. Это слишком большая пушка для отстрела ног. H>>Перефразируя: макросы — зло, потому что они позволяют менять семантику кода (это одно из их предназначений)? G>Не-а. макросы — зло, потому что они позволяют менять семантику кода без изменения самого кода. Ну собственно проблема та же, что и макросов в C. Только в nemerle можно сделать более умные макросы.
Если так рассуждать, то все библиотеки — такое же зло. Семантику библиотечного вызова тоже ведь можно поменять в любой момент совсем без изменения использующего кода. Я тебе больше скажу — отчасти для этого библиотеки и создаются. Следовательно, библиотеки — это зло изначально(е)!
G>>>Я бы вообще предложил запретить по-умолчанию кастомные синтаксические макросы, оставить только макросы в виде атрибутов и макросы "изкаропки". H>>Это решается административными мерами. G>Административные меры без энфорсинга со стороны инструментов не работают.
От же ж держиморды выискались: запретить-запретить-запретить!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
