T>>Конечно, это вырожденные случаи, просто из любопытства интересно, ловит ли компилятор подобные извороты?

H>А ловит ли компилятор, скажем, Си, извороты вида:
H>

for(;;);

H>

Проверил. Не ловит. Очень удивительно, я ожидал варнинг.

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

T>>>Кстати, расскажите, пожалуйста, как вы в немерле боретесь (если) с многопроходностью?

К>Влад, человек вроде про многопроходность, а не про многопоточность спрашивал

Э... сори. Проклятое зрение!

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

Макросы отрабатывают на некоторых стадиях или между ними. Скажем макро-атрибуты отрабатывают после построения дерева типов и после связывания типов для типов и их членов. Макросы уровня выражения раскрываются во время типизации тел методов (непосредственно перед типизацией выражения в котором они встречаются).

Макросы могут раскрыться в код так же содержащий макросы.

Так что при раскрытии макросов никакой многопроходности нет.

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

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

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

Макрос уровня выражения — это просто функция получающая набор выражений в качестве параметров и возвращающая выражение (АСТ уровня выражения). Мета-атрибуты — это процедуры выполняемые в различные стадии компиляции и способные модифицировать АСТ (императивно).

T>Я точно не знаю синтаксиса Немерла, надеюсь, такой будет понятен:

Дык, может стоит познакомиться?
http://www.rsdn.ru/summary/5099.xml

T>

T>macro Infinite
T>syntax "inf"
T>{
T>  output "inf"
T>}
T>

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

Дык в том то все и дело, что макросы не выполняются, а раскрываются. В указанном тобой виде макрос можно будет определить только при уловии, что до этого макрос был реализован без рекурсии. Готовый макрос можно подключить (в виде dll) к проекту соберающему тот же макрос. Но это будет предыдущая версия макроса! При своем раскрытии эта версия генерирует код в котором не будет себя же. Этот код и станет результатом работы нового макроса. Кода проект содержащий макрос будет перекомпилирован еще раз, то точно так же раскроется новая весрия, но так как она была создана из старой, то она вернет все тот же АСТ не содержащий себя.

Так что в этом плане рекурсия и есть, и ее нет. Визуально мы можем написать код так:

  macro @if (cond, e1, e2)
  syntax ("if", "(", cond, ")", e1, Optional (";"), "else", e2)
  {
    <[ if ($cond) $e1 else $e2) ]>
  }

Но он все равно раскроется в:

  macro @if (cond, e1, e2)
  syntax ("if", "(", cond, ")", e1, Optional (";"), "else", e2)
  {
    Util.locate(cond.Location,
    <[
      match ($cond : bool)
      {
        | true => $e1
        | _ => $e2
      }
    ]>)
  }

Так как старая версия вернет именно этот код.

Еще раз повторюсь макрос Nemerle должен быть скомпилирован до применения. Так что самого себя он использовать не может.

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

T>Конечно, это вырожденные случаи, просто из любопытства интересно, ловит ли компилятор подобные извороты?

Они просто невозможны.

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

H>>А ловит ли компилятор, скажем, Си, извороты вида:
H>>

for(;;);

H>>

T>Проверил. Не ловит. Очень удивительно, я ожидал варнинг.

Он о том, что компилятор C написан на С же, но это не приводит к тому, что компилятор зацикливается встретив конструкцию for... если я его правильно понял.

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

VD>Они просто невозможны.

На самом деле возможны (это связано с механизмом разрешения имен функций).

Макрос:

namespace test
{
  macro Macro1()
  {
    <[ Macro1() ]> // Call, НЕ MacroEnvelope
  }
}

Код:

namespace test
{
  module Program
  {
    Main() : void { Macro1(); }
  }
}

Компилятор вылетает с переполнением стека.


Другое дело, что никто в здравом уме не станет такую фигню писать.

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

VD>Он о том, что компилятор C написан на С же, но это не приводит к тому, что компилятор зацикливается встретив конструкцию for... если я его правильно понял.

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

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

H>Другое дело, что никто в здравом уме не станет такую фигню писать.

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

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

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

В принципе достаточно сделать в компиляторе защиту от неограниченной рекурсии макросов (скажем, 100 итераций), не известно правда, насколько это оправданно. Во всяком случае никто на такие проблемы еще не натыкался.

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


T>Конечно, это вырожденные случаи, просто из любопытства интересно, ловит ли компилятор подобные извороты?

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

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

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

H>В принципе достаточно сделать в компиляторе защиту от неограниченной рекурсии макросов (скажем, 100 итераций), не известно правда, насколько это оправданно. Во всяком случае никто на такие проблемы еще не натыкался.

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

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

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

VD>Кроме того в твоих рассуждениях этот термин совершенно не нужен. Без него получится даже понятнее.
VD>Скажем, если фразу "Избыточность сообщения — разница между энтропией сообщения и максимально возможной энтропией." перефразировать так — "Избыточность сообщения — разница между информационной насыщенностью сообщения сообщения и максимально возможной информационной насыщенностью сообщения.", то она станет только понятнее. Хотя после этого становится очевидным, что "максимально возможной информационной насыщенностью сообщения" может быть бесконечна. Из чего делаем вывод, что или определение не верное, или логический вывод хромает.
Что-то я запутался в твоих рассуждениях. Информационная энтропия по Шеннону имеет одно очень конкретное свойство, на которое я опираюсь в своих рассуждениях — она ограничена сверху. В конечном итоге из этого я делаю заключение, что каждую конкретную программу нельзя сжимать до бесконечности, даже используя сколь угодно продвинутые средства абстракции. Совсем выкидывать энтропию из текста нельзя. Может просто не ссылаться на неё часто, а только в определении насыщенности и там, где используется её свойство ограниченности сверху?

VD>При этом нет нет никакого смысла давать определение понятиям "Информационная насыщенность сообщения" и "Избыточность сообщения". Все и так интуитивно понимают смысл этих слов. Избыточность — кода можно выкинуть лишнее и смысл не потеряется. Информационная насыщенность — когда мало "воды".
С этим соглашусь

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

VD>Усложнять — легко. Упрощать — тяжело. Так что не надо стараться усложнять. Это и так получится .
Черт возьми, а ведь ты прав!

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

VD>Если пришлешь статью в ближайшее время, то обещаю обработать ее первой. При это будут как правки языковые, так и замечания в виде комментариев (в балунах).
Постараюсь побыстрее, но не обещаю.
С делами завал.

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

H>Компилятор вылетает с переполнением стека.

Если это так, то это просто баг. Компилятор не должен видеть имени еще не скомпилированного макроса.

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

0>Постараюсь побыстрее, но не обещаю.
0>С делами завал.

Если сделаешь сегодня (максимум завта) то включим статью в сдаваемый на днях номер.

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

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

H>>Компилятор вылетает с переполнением стека.

VD>Если это так, то это просто баг. Компилятор не должен видеть имени еще не скомпилированного макроса.

А он и не видит. Компиляция валится при использовании этого макроса.
Я же для тебя написал комментарий: <[ Macro1() ]> есть ничто иное как обычный PExpr.Call("Macro1", []), тогда как синтаксические макросы в цитатах выглядят как MacroEnvelope, если мне не изменяет память.