предложение по синтаксису н2
строка вида //-----
воспринимается как разделитель файла. Т.е. Независимая единица компиляции разве что кроме using. Ошибки компиляции не переходят через секции. Секция воспринимается как конец файла и требует закрытия всех скобок.

Зачем надо? Ускорение компиляции так как не измененые секции не надо разбирать и типизировать. Упрощение поиска ошибок так как не закрытая скобки не будут порождать кучу ошибок.

Здравствуйте, Аноним, Вы писали:

А>предложение по синтаксису н2
А>строка вида //-----
А>воспринимается как разделитель файла. Т.е. Независимая единица компиляции разве что кроме using. Ошибки компиляции не переходят через секции. Секция воспринимается как конец файла и требует закрытия всех скобок.

А зачем в одном файле размещать несколько единиц компиляции?

А>Зачем надо? Ускорение компиляции так как не измененые секции не надо разбирать и типизировать. Упрощение поиска ошибок так как не закрытая скобки не будут порождать кучу ошибок.

Типизировать надо все равно, а парсинг настолько быстр, что выигрыш представляется сомнительным.

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

Z>Здравствуйте, Аноним, Вы писали:

А>>предложение по синтаксису н2
А>>строка вида //-----
А>>воспринимается как разделитель файла. Т.е. Независимая единица компиляции разве что кроме using. Ошибки компиляции не переходят через секции. Секция воспринимается как конец файла и требует закрытия всех скобок.

Z>А зачем в одном файле размещать несколько единиц компиляции?

А>>Зачем надо? Ускорение компиляции так как не измененые секции не надо разбирать и типизировать. Упрощение поиска ошибок так как не закрытая скобки не будут порождать кучу ошибок.

Z>Типизировать надо все равно, а парсинг настолько быстр, что выигрыш представляется сомнительным.

потому что единицы компиляции можно частично типизировать и если изменение их не затронет, то перетипизировать их уже не надо
Если например в файле 10 классов, каждый из которых отделен через //-----, то разбирать придется только 1, и типизировать тело одного класса, и типизировать объеденные тела.
При этом часто можно будет не выполнять макросы, считая их сгенерированными если любые изменения единицы компиляциии не влияют на них.

Здравствуйте, Аноним, Вы писали:

А>Зачем надо? Ускорение компиляции так как не измененые секции не надо разбирать и типизировать. Упрощение поиска ошибок так как не закрытая скобки не будут порождать кучу ошибок.

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

гораздо интереснее именно многопоточная обработка, что тоже планируется.

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

P>Здравствуйте, Аноним, Вы писали:

А>>Зачем надо? Ускорение компиляции так как не измененые секции не надо разбирать и типизировать. Упрощение поиска ошибок так как не закрытая скобки не будут порождать кучу ошибок.

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

P>гораздо интереснее именно многопоточная обработка, что тоже планируется.

Для работы в редакторе эта микрооптимизация даст больше чем многопоточность.
Добавлять ее не сложно (наверное), а ускорение будет значительным в разы возможно до 10 раз. Ни какая многопоточность этого не даст.
Плюс контроль Ошибок дополнительный.

Здравствуйте, <Аноним>, Вы писали:

А>Зачем надо? Ускорение компиляции так как не измененые секции не надо разбирать и типизировать. Упрощение поиска ошибок так как не закрытая скобки не будут порождать кучу ошибок.
Это все делается гораздо проще.
ИДЕ сообщает, в каком месте изменился исходник.
На основе этой информации можно перепарсить кусок АСТ.
При это даже если во время правки будет не хватать скобок ИДЕ сможет понять где именно их не хватает.
И не нужно никаких разделителей.

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

WH>Здравствуйте, <Аноним>, Вы писали:

А>>Зачем надо? Ускорение компиляции так как не измененые секции не надо разбирать и типизировать. Упрощение поиска ошибок так как не закрытая скобки не будут порождать кучу ошибок.
WH>Это все делается гораздо проще.
WH>ИДЕ сообщает, в каком месте изменился исходник.
WH>На основе этой информации можно перепарсить кусок АСТ.
WH>При это даже если во время правки будет не хватать скобок ИДЕ сможет понять где именно их не хватает.
WH>И не нужно никаких разделителей.

Разве? Что то берет сомнение, что придется делать полную типизацию все равно всего тела модуля.

Здравствуйте, Аноним, Вы писали:

Перестань, плиз, оверквотить.

А>потому что единицы компиляции можно частично типизировать и если изменение их не затронет, то перетипизировать их уже не надор

Все не так просто как ты себе представляешь.

На практике при парсинге может быть повреждена структура файла (обычное дело при редактировании).
Кроме того в языках вроде C#, C++, Nemerle есть препроцессор.
По сему парсинг проще делать целиком. Высокая скорость парсинга позволяет это делать на каждый чих.

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

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

Если реактивной системы нет, то некоторая часть изменений дерева разбора будет требовать полной перетипизации. Именно так и делается в Н1. За счет того что типизации на уровне типов и их членов (без типизации выражений) является очень быстрой — это не вызывает проблем.

А>Если например в файле 10 классов, каждый из которых отделен через //-----, то разбирать придется только 1, и типизировать тело одного класса, и типизировать объеденные тела.

Это не серьезно. Зачем мучить людей какой-то разметкой? Все равно это ровным счетом ничего не даст. Скажем, внутри одного из блоков может быть инструкция:

#define XXX

человек введением всего одного символа:

#define XXXz

может изменить весь файл до неузнаваемости. При этом перепарсить придется все начиная от места изменения и до конца фала. А все секции пойдут к черту.

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

Это все не нужно. Парсинг довольно быстрая операции. Проще тупо на каждый чих перепарсивать файл.

Чтобы исключить тормоза парсинг можно всегда вести в бэкграуд-потоке, или переводить парсинг в бэкграунд при превышении некоторого времени реакции (например 0.1 секунды).

99% файлов которые пишутся вручную не превышают 200Кб. Это объемы смехотворные для современных процессоров. Ну, а при редактировании мега-файлов можно потерпеть из небольшую латентность в отрисовке цветов и прочего. Ведь такие файлы очень редко редактируются.

Здравствуйте, Аноним, Вы писали:

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

Ты заблуждаешься. Парсинг весьма быстрый и почти линейный процесс. Его ускорение в 10 раз мало что даст. В любом случае, если парсинг будет медленным — это будет плохо. Ведь если в проекте 10 мег исходников (редкость, но встречается), то медленный парсер приведет к тому, что компиляция выльется в десятки секунд только для парсинга. Так что проблемы будут не только в редкаторе.

А с быстрым парсером и в редакторе проблем не будет.

Вообще, современные интеграции с IDE обычно поступают так. Для подсветки синтаксиса в них используется отдельный лексер. Он работает построчно (запоминается состояние на начало строки). Это очень быстро даже при очень кривой реализации.

Расширенная же подсветка, для которой нужен парсинг и типизация, делается в бэкграудн-потоке. Когда поток авершает свою работу ГУИ-поток получает эту информацию и использует для подсветки.

В нашем случае есть огромная проблема — мы не имеем отдельного лексера и имеем возможность динамического расширения.

По сему самой простой и эффективной стратегией будет полный перепасинг всего файла.

ЗЫ

Собственно, ты не о том думаешь. Основные тормоза не в парсинге, а в типизации. Именно там не линейные алгоритмы и море данных для обработки.

Вот там то и будет полезно иметь многопоточную обработку. Для С-подобных языков всегда можно предварительно распарсить код без типизации, а потом производить типизацию тел методов (само медленное) в бэкграунде.

Сложнее с прямыми клонами ML (F#, Haskell, ...). У них типизация всегда идет сверху в низ, так что распараллелить ее сложнее. Разве что код разных модулей можно параллельно типзировать.

Здравствуйте, Аноним, Вы писали:

А>Разве? Что то берет сомнение, что придется делать полную типизацию все равно всего тела модуля.

Полной типизации как раз можно избежать. А вот полного перепарсивания измененного исходника избежать сложнее.