Прикручиваю автокомплит в SharpDevelop, в связи с этим возник вопрос (по-видимому к VladD2) — что это за индекс файла такой в интерфейсе ISource, из которого Location умеет изготавливать имя файла?
Как вообще с ним работать из IDE?

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

H>Как вообще с ним работать из IDE?


Разобрался.
Нужно просто для очередного имени файла спрашивать Location.GetFileIndex, который во внутреннюю таблицу его и добавит, если его там до этого небыло.

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

H>Прикручиваю автокомплит в SharpDevelop,

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

H>в связи с этим возник вопрос (по-видимому к VladD2) — что это за индекс файла такой в интерфейсе ISource, из которого Location умеет изготавливать имя файла?

Индекс в глобальной (статической) таблице. Подробнее см. реализацию функции GetFileIndex() в AST.n.

H>Как вообще с ним работать из IDE?

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

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

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

H>>Прикручиваю автокомплит в SharpDevelop,

VD>Не хочется тебя разочаровывать, но это тебе вряд ли удастся. По крайней мере так чтобы качественно работало.

Ну, IEngine завелся, парсит проект
По Ctrl+Space оно выдает список, надо только его по-человечески отобразить.

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

H>Ну, IEngine завелся, парсит проект

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

В студии делается так... При изменениях вне тел методов перепарсивается весь проект (в бэкграунде, через очередь). При изменении внутри тел методов перепарсивается только тело. Это позволяет довольно сносно обрабатывать большие проекты.

У этих же друзей я не нашел даже такой возможности как получить оповещение об изменении части файла.

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

VD>Индекс в глобальной (статической) таблице. Подробнее см. реализацию функции GetFileIndex() в AST.n.

А если не секрет, почему так было сделано? Почему бы не хранить имя файла напрямую, строка ведь все равно должна быть интернирована.

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

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

H>>Ну, IEngine завелся, парсит проект

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

VD>В студии делается так... При изменениях вне тел методов перепарсивается весь проект (в бэкграунде, через очередь). При изменении внутри тел методов перепарсивается только тело. Это позволяет довольно сносно обрабатывать большие проекты.

VD>У этих же друзей я не нашел даже такой возможности как получить оповещение об изменении части файла.

Я вызываю BeginUpdateCompileUnit для текущего документа при его изменении.

Еще не понял такого кода в NemerleSource в обработчике OnChangeLineText:

if (projectInfo.IsProjectAvailable)
{
    TextLineChange changes = lineChange[0];

    RelocationQueue.AddRelocationRequest(RelocationRequestsQueue,
    FileIndex, CurrentVersion,
    changes.iNewEndLine + 1, changes.iNewEndIndex + 1,
    changes.iOldEndLine + 1, changes.iOldEndIndex + 1,
    changes.iStartLine + 1, changes.iStartIndex + 1);
}

Если честно, то практически ничего в исходниках, кроме описаний интерфейсов, не читал.

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

ВВ>А если не секрет, почему так было сделано? Почему бы не хранить имя файла напрямую, строка ведь все равно должна быть интернирована.

Дык ровно один раз. А далее сравниваются целые числа. Сравнений локейшонов производится миллионы раз. А инициализация их из строки почти никогда.

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


H>Еще не понял такого кода в NemerleSource в обработчике OnChangeLineText:
H>

H>if (projectInfo.IsProjectAvailable)
H>{
H>    TextLineChange changes = lineChange[0];

H>    RelocationQueue.AddRelocationRequest(RelocationRequestsQueue,
H>    FileIndex, CurrentVersion,
H>    changes.iNewEndLine + 1, changes.iNewEndIndex + 1,
H>    changes.iOldEndLine + 1, changes.iOldEndIndex + 1,
H>    changes.iStartLine + 1, changes.iStartIndex + 1);
H>}
H>

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

OnChangeLineText вызывается при изменении участка исходника. Информация об изменении помещается в RelocationQueue и потом, в рабочем потоке, применяется к имеющемуся АСТ. Это приводит к пересчету все локешонов. Кроме того при этом отслеживаются изменение внутри методов и методы ставятся в очередь на перекомпиляцию.

А вот BeginUpdateCompileUnit вызывать явно не нужно. Надо вообще выкинуть BeginUpdateCompileUnit из публичного интерфейса.

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

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

Т.е. для оптимизации сравнения?
А так было бы медленнее?

struct Location
{
  int Col;
  int Line;
  FileInfo File;
}

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

VD>А в этом коде вся суть. Так как мы отслеживаем изменения внутри методов, то остальное АСТ нужно приводить в корректное состояние после внесения изменения. Все локешоны ниже точки изменения нужно пересчитать.
VD>OnChangeLineText вызывается при изменении участка исходника. Информация об изменении помещается в RelocationQueue и потом, в рабочем потоке, применяется к имеющемуся АСТ. Это приводит к пересчету все локешонов. Кроме того при этом отслеживаются изменение внутри методов и методы ставятся в очередь на перекомпиляцию.
VD>А вот BeginUpdateCompileUnit вызывать явно не нужно. Надо вообще выкинуть BeginUpdateCompileUnit из публичного интерфейса.

Да пусть сделает. Фишка #D не в том, что IDE такая хорошая, а в том, что все же вокруг него тусуется довольно приличный community. Если сделать минимальную поддержку Немерле — пусть даже без автокомплита, — и включить ее в дистрибуции Шарп-Девелопа, то этой пойдет на пользу проекта.

Только вот интегрироваться лучше бы с 4.0 сразу. К тому же они там серьезный redesign обещали.

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

ВВ>Т.е. для оптимизации сравнения?
ВВ>А так было бы медленнее?

ВВ>

ВВ>struct Location
ВВ>{
ВВ>  int Col;
ВВ>  int Line;
ВВ>  FileInfo File;
ВВ>}
ВВ>

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

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

ВВ>Да пусть сделает.

Я что против? Просто задачу прямо не делается. Придется искать обходные маневры. И не факт, что вообще получится работоспособная версия.

ВВ>Фишка #D не в том, что IDE такая хорошая, а в том, что все же вокруг него тусуется довольно приличный community. Если сделать минимальную поддержку Немерле

Минимальная уже есть.

ВВ> — пусть даже без автокомплита, — и включить ее в дистрибуции Шарп-Девелопа, то этой пойдет на пользу проекта.

Не спорю. Но тормозящий комплит может оказаться антиреклама.

ВВ>Только вот интегрироваться лучше бы с 4.0 сразу. К тому же они там серьезный redesign обещали.

4 чего?

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

VD>Насколько позволяют мои телепатические способности — было бы медленее. Вообще, сам можешь подумать. В Location на одно поле типа int хранит информацию о файле и флагах (был ли Location сгенерирован, есть ли для него исходный код...). А ты вместо этого целую структуру данных хочешь запихнуть.

FileInfo — это класс, т.е. сравниваться будут указатели. Размер структуры Location на 32б будет таким же. Мне просто правда хочется понять, какие могут быть причины для создания отдельного пуля для имен файлов.

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

ВВ>>Только вот интегрироваться лучше бы с 4.0 сразу. К тому же они там серьезный redesign обещали.
VD>4 чего?

SharpDevelop 4.0, переведен на WPF, обещали и другой редизайн (к слову, многое из того, что делает hardcase может и отвалиться). Недавно стала доступна то ли бета, то ли альфа, но я не качал.

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

ВВ>> — пусть даже без автокомплита, — и включить ее в дистрибуции Шарп-Девелопа, то этой пойдет на пользу проекта.
VD>Не спорю. Но тормозящий комплит может оказаться антиреклама.

Комплит можно сделать для классов фреймворка. Class view можно сделать. Некоторую поддержку рефакторинга. Интегрировать Nemerlish. Ну и написать им, чтобы включили в следующий релиз. Вроде в таком объеме на антирекламу тянуть не должно.

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


ВВ>FileInfo — это класс, т.е. сравниваться будут указатели. Размер структуры Location на 32б будет таким же. Мне просто правда хочется понять, какие могут быть причины для создания отдельного пуля для имен файлов.

Локешонов на средний проект получается под миллионы. В каждом убдет ссылка котору ЖЦ должен будте проверить. Плюс еще где-то надо хоранить финформацию о флагах.

Внимание, вопрос — зачем?

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

ВВ>>FileInfo — это класс, т.е. сравниваться будут указатели. Размер структуры Location на 32б будет таким же. Мне просто правда хочется понять, какие могут быть причины для создания отдельного пуля для имен файлов.
VD>Локешонов на средний проект получается под миллионы. В каждом убдет ссылка котору ЖЦ должен будте проверить. Плюс еще где-то надо хоранить финформацию о флагах.
VD>Внимание, вопрос — зачем?

Я не предлагаю решение, а спрашиваю, почему было выбрано существующее. Для саморазвития, если хочешь
ОК, т.е. имя файла хранится в пуле, а не упаковывается в какой-нибудь класс (хоть FileInfo, хоть свой, "с флагами"), чтобы облегчить жизнь GC.

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

ВВ>SharpDevelop 4.0, переведен на WPF, обещали и другой редизайн (к слову, многое из того, что делает hardcase может и отвалиться). Недавно стала доступна то ли бета, то ли альфа, но я не качал.

Там и в релизе то все кривее не куда. Я бы с бэтой возиться не стал бы.

Вот что нуно сделать, так это обратиться к разработчикам и попросить их сделать более низкоуровневый АПИ, чтобы можно было не только близницов-братьев вроде Шарпа и Васика поддерживать, но и сложные языки вроде Немерла.

У Студии ведь с этим проблем нет.

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

ВВ>Комплит можно сделать для классов фреймворка.

Языком можно сделать все что угодно. На практике же все не так просто.

ВВ> Class view можно сделать. Некоторую поддержку рефакторинга. Интегрировать Nemerlish. Ну и написать им, чтобы включили в следующий релиз. Вроде в таком объеме на антирекламу тянуть не должно.

Ну, ты уже пробовал сделать? Как оно получается?

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

ВВ>Я не предлагаю решение, а спрашиваю, почему было выбрано существующее. Для саморазвития, если хочешь

Не знаю. Не я его принимал, но я не вижу в нем ничего плохого. Зато вижу плюсы.

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

ВВ>>Комплит можно сделать для классов фреймворка.
VD>Языком можно сделать все что угодно. На практике же все не так просто.

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

По поводу 4.0 — тут проблема в том, что они обещали серьезные изменения. Делать ингерацию для 3.1, которая отвалится в 4.0
Плюс как раз пока еще релиза нет, можно затребовать у них кое-какие фишки.

Кстати, вот интеграция для Boo ведь работает как-то с автокомплитом. Я правда Boo совсем не знаю, но он тоже статически типизированный, с выводом типов, автокомплит есть Да и код интеграции вроде как тоже открыт.

ВВ>> Class view можно сделать. Некоторую поддержку рефакторинга. Интегрировать Nemerlish. Ну и написать им, чтобы включили в следующий релиз. Вроде в таком объеме на антирекламу тянуть не должно.
VD>Ну, ты уже пробовал сделать? Как оно получается?

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

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

ВВ>>Я не предлагаю решение, а спрашиваю, почему было выбрано существующее. Для саморазвития, если хочешь
VD>Не знаю. Не я его принимал, но я не вижу в нем ничего плохого. Зато вижу плюсы.

А сам бы ты как сделал? Через пул или хранил бы указатель на класс с информацией о файле?

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

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

ВВ>>Комплит можно сделать для классов фреймворка.

VD>Языком можно сделать все что угодно. На практике же все не так просто.

ВВ>> Class view можно сделать. Некоторую поддержку рефакторинга. Интегрировать Nemerlish. Ну и написать им, чтобы включили в следующий релиз. Вроде в таком объеме на антирекламу тянуть не должно.

VD>Ну, ты уже пробовал сделать? Как оно получается?


Да, Class view можно сделать, но я в ту сторону еще не заглядывал, на первый взгляд там от автокомплита один шаг.
Нужно из CodeCompileUnit сделать шарпдевелоповский ICompilationUnit.

Nemerlish кстати я туда уже давно прикрутил.

В релиз они точно не будут мое поделие включать — оно на Nemerle писано (хотя все в том же SharpDevelop).


Что сейчас сделано и работает:
1) Интеграция с msbuild: добавить-удалить файлы, настройка параметров сборки проекта, билд
2) Ссылки на библиотеки макросов и проекты макро-сборок
3) Отладка (оно само — я к этому рук не прикладывал), но с локальными функциями там проблемы
3) Кривая-косая подсветка синтаксиса (я еще не пробовал сносить башку стандартному хайлайтеру)
4) Немерлишь (до кучи, как говорится, — им ваще кто-то пользуется?)
5) Автоподстановка — пока тока имена.

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

ВВ>SharpDevelop 4.0, переведен на WPF, обещали и другой редизайн (к слову, многое из того, что делает hardcase может и отвалиться). Недавно стала доступна то ли бета, то ли альфа, но я не качал.

Што отвалится — починим. Там не так уж и много у меня на GUI висит. Разбираться в альфа-бетах пока резону нет, когда выпустят, тогда и посмотрю.

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

H>В релиз они точно не будут мое поделие включать — оно на Nemerle писано (хотя все в том же SharpDevelop).

А это пофиг. Интеграция с F# там написана на F#.

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

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

H>>В релиз они точно не будут мое поделие включать — оно на Nemerle писано (хотя все в том же SharpDevelop).

ВВ>А это пофиг. Интеграция с F# там написана на F#.

В 3.2 (которую использую) она написана на C#.

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

ВВ>>А это пофиг. Интеграция с F# там написана на F#.
H>В 3.2 (которую использую) она написана на C#.

А там какие-нибудь фичи вроде комплита появились? Хз, может, переделали. Но, честно, я не думаю, что у них такой C# nazi на проекте, какая разница, на каком языке доступна интеграция и почему это должно мешать включить ее в дистрибутив

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

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

ВВ>>>А это пофиг. Интеграция с F# там написана на F#.
H>>В 3.2 (которую использую) она написана на C#.

ВВ>А там какие-нибудь фичи вроде комплита появились? Хз, может, переделали. Но, честно, я не думаю, что у них такой C# nazi на проекте, какая разница, на каком языке доступна интеграция и почему это должно мешать включить ее в дистрибутив


Зачем к ним в дистрибутив включать? У нас свой есть. Просто очередную опцию можно сделать — Sharp Develop Binding, наравне с интеграцией в VS.

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

H>Зачем к ним в дистрибутив включать? У нас свой есть. Просто очередную опцию можно сделать — Sharp Develop Binding, наравне с интеграцией в VS.

Чтобы больше людей узнало о Немерле. Т.е. вся пользовательская база #D. Без этого я вообще не вижу смысла в этой интеграции.

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

ВВ>Чтобы больше людей узнало о Немерле. Т.е. вся пользовательская база #D. Без этого я вообще не вижу смысла в этой интеграции.

Если мыслить в таком ключе... Надо с разрабами поговорить.

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

ВВ>>Чтобы больше людей узнало о Немерле. Т.е. вся пользовательская база #D. Без этого я вообще не вижу смысла в этой интеграции.

H>Если мыслить в таком ключе... Надо с разрабами поговорить.

Вот только им наша реклама на фиг не упала...

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

ВВ>>>Чтобы больше людей узнало о Немерле. Т.е. вся пользовательская база #D. Без этого я вообще не вижу смысла в этой интеграции.
H>>Если мыслить в таком ключе... Надо с разрабами поговорить.
VD>Вот только им наша реклама на фиг не упала...

А им тоже выгодно, чтобы #D поддерживал больше интеграций. Boo-то они включили, чем Немерле хуже.

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

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

Именно. Ты уж прости, что я так отвечаю, но обычно если человек этого не понимает, то объяснить ему детали практически невозможно.

ВВ>По поводу 4.0 — тут проблема в том, что они обещали серьезные изменения. Делать ингерацию для 3.1, которая отвалится в 4.0

Если этот самый 4.0 создан на базе WPF, то толку от его поддержки в ближайшие 3-5 лет будет не много. #Develop используют те кого не страивает скорость работы VS, а так же те кто использует его клон MonoDevelop под линуксом, так как там вообще никаких IDE нет.

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

Поддержка старого #Develop имеет смысл именно в качестве рекламы и как легкая IDE которую возможно будет портнуть под MonoDevelop.

ВВ>Плюс как раз пока еще релиза нет, можно затребовать у них кое-какие фишки.

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

ВВ>Кстати, вот интеграция для Boo ведь работает как-то с автокомплитом. Я правда Boo совсем не знаю, но он тоже статически типизированный, с выводом типов, автокомплит есть Да и код интеграции вроде как тоже открыт.

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

Плюс у немерла есть серьезные проблемы с реализацией и скоростью.

В #Develop предлагается типизироваться отдельные члены динамически, а парсить только изменяемые файлы. Для немерла это неприемлемо. В детали в даваться не убуду, так как их очень много.

Собственно одной из задач для Nemerle 2.0 я вижу изменение принципов работы компилятора с тем, чтобы урпостить его использование в IDE-режиме. Для этого работа с кодом должна стать версионной и строго иерархичной, чтобы изменение мелкой финтифлюшки не приводило к необходимости повторно обрабатывть тучи данных, и чтобы макросы не могли менять АСТ как им захочется, а всегда порождали новую версию некоторых подветок АСТ.

В прочем, боюсь, что и для Nemerle 2.0 реализовать поддержку #Develop будет проблематично.

ВВ>Автокомплит я сделать не пробовал.

А я поглядел что там к чему и пришел в уныние. Возможно я чего-то не заметил, но если я все понял правильно, то #Develop предлагает всегда динамически парсить весь измененный файл и не позволяет узнать какой его участок был изменен. Плюс он предполагает, что мы будем манипулировать его интерфейсом вроде тайп-резолвера. А для нас это не приемлемо.

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

ВВ>А сам бы ты как сделал? Через пул или хранил бы указатель на класс с информацией о файле?

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

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

ВВ>Boo-то они включили, чем Немерле хуже.

А она на чем написана?

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

H>Если мыслить в таком ключе... Надо с разрабами поговорить.

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

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

VD>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Boo-то они включили, чем Немерле хуже.
VD>А она на чем написана?

Вроде на C#, если мне память не изменяет. Но, думаю, по тем же самым причинам, по которым интеграция Немерле в VS тоже написана на C#.

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

ВВ>Вроде на C#, если мне память не изменяет. Но, думаю, по тем же самым причинам, по которым интеграция Немерле в VS тоже написана на C#.

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

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

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

VD>Интеграция Немерле с VS написана на двух языках. Основная логика и все сложное написано как раз на Немерле, а на шарпе та обвязка которую мы тупо скопипастили из питоновской интеграции.
VD>В прочем, сейчас я уже не уверен, что это была хорошая идея. Но она дала одно приемущество. Удалось вделить движок интеграции который теперь можно использовать не только в студии.

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

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

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

Возможно основная причина — это требования шарп-девелоперов.

А вообще, и они и создатель Бу доступны в сети. Если очень интересует этот вопрос, то можно спросить у них.

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

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

Основное отличие интеграции Бу от интеграции Шарпа и Васика в том, что она использует свой движок парсинга и комплита (у шарпа и васика что-то под названием NRefactory куда я вообще не лазил). Причем в ней они пинают компилятор Бу для разбора кода. Собственно куски кода я надергал из каждой интеграции (Бу, Шарп, Питон, Фэшарп)