_nn_ wrote: > Nemerle это хорошо, но требует .Net, что не всегда хорошо > А что насчет Nemerle, который будет компилироваться в native ?
Сложно слишком.
> P.S. > Естественно придется отказаться от рефлексии и других полезных функций.
А почему? От Emit'а действительно придется отказаться, но Reflection в
нативных языках никто не отменял.
Здравствуйте, Cyberax, Вы писали:
C>_nn_ wrote: >> Nemerle это хорошо, но требует .Net, что не всегда хорошо >> А что насчет Nemerle, который будет компилироваться в native ? C>Сложно слишком.
А в чем именно сложность ?
>> P.S. >> Естественно придется отказаться от рефлексии и других полезных функций. C>А почему? От Emit'а действительно придется отказаться, но Reflection в C>нативных языках никто не отменял.
Ну в таком случае можно и платформозависимый emit добавить
Здравствуйте, _nn_, Вы писали:
nn>Nemerle это хорошо, но требует .Net, что не всегда хорошо nn>А что насчет Nemerle, который будет компилироваться в native ?
Думаю, если будет реализована идея похожая на вот эту, "Пожалуйста, сэр, могу ли я получить компоновщик" то требуемая функциональность будет доступна для всех .Net языков, а не только для Ne.
Технически — идея достаточно просто реализуемая. Почему же её ещё никто не сделал, в том виде в котором описывает Джоуэл? Имхо, потому, что таки не сильно оно востребовано
А вот частные решения, вроде преобразования IL в native для отдельных сборок с сохранением метаданных, уже давно появились в популярных обфускаторах.
nn>P.S. nn>Естественно придется отказаться от рефлексии и других полезных функций.
Кстати, совсем не обязательно.
Выбор команды Nemerle понять легко — это, с одной стороны, значительное упрощение/удешевление разработки компилятора (позволяет больше сосредоточиться на самом языке), ну и с другой — на шару интероперабельность с мейнстримом, кроcсплатформенность. Да и больше будет способствовать росту популярности языка.
_nn_ wrote: >> > Nemerle это хорошо, но требует .Net, что не всегда хорошо >> > А что насчет Nemerle, который будет компилироваться в native ? > C>Сложно слишком. > А в чем именно сложность ?
_НАМНОГО_ большая сложность формирования кода.
Конечно, можно просто написать фронтенд к GCC, но это тоже весьма
нелегкая задача. Да и писать придется на pure C
Здравствуйте, Cyberax, Вы писали:
C>_nn_ wrote: >>> > Nemerle это хорошо, но требует .Net, что не всегда хорошо >>> > А что насчет Nemerle, который будет компилироваться в native ? >> C>Сложно слишком. >> А в чем именно сложность ? C>_НАМНОГО_ большая сложность формирования кода.
C>Конечно, можно просто написать фронтенд к GCC, но это тоже весьма
Вообще-то это и подрозумевалось C>нелегкая задача. Да и писать придется на pure C
Неужто фронт энд на С++ никак не написать ?
Здравствуйте, _nn_, Вы писали:
__>Nemerle это хорошо, но требует .Net, что не всегда хорошо __>А что насчет Nemerle, который будет компилироваться в native ?
__>P.S. __>Естественно придется отказаться от рефлексии и других полезных функций.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _nn_, Вы писали:
__>>Nemerle это хорошо, но требует .Net, что не всегда хорошо __>>А что насчет Nemerle, который будет компилироваться в native ?
__>>P.S. __>>Естественно придется отказаться от рефлексии и других полезных функций.
VD>В лес такие полезные вещи.
Неужели нативный язык это настолько плохо ?
VD>А вообще вот
_nn_ wrote: > C>нелегкая задача. Да и писать придется на pure C > Неужто фронт энд на С++ никак не написать ?
В теории, можно (фронтенд для Ады написан на Аде, например). На практике
— лучше даже не пытаться.
Здравствуйте, Cyberax, Вы писали:
C>_nn_ wrote: >> C>нелегкая задача. Да и писать придется на pure C >> Неужто фронт энд на С++ никак не написать ? C>В теории, можно (фронтенд для Ады написан на Аде, например). На практике C>- лучше даже не пытаться.\
Вы, кстати, фрэнтэнд и бэкэнд не путаете? А то фрэнтэнд Нэмерла написан на Нэмерле, и фронтэнд Шарпа в Моно написан на Шарпе.
VladD2 wrote: > C>В теории, можно (фронтенд для Ады написан на Аде, например). На практике > C>- лучше даже не пытаться. > Вы, кстати, фрэнтэнд и бэкэнд не путаете? А то фрэнтэнд Нэмерла написан > на Нэмерле, и фронтэнд Шарпа в Моно написан на Шарпе.
Я говорю про фронтенды к GCC.
GCC (GNU Compiler Collection) is essentially divided into a front end
and a back end. The main reason for this division is for providing code
reusability. As all of us know GCC supports a variety of languages. This
includes C, C++, Java etc.
If you want to introduce a new language into GCC, you can. The only
thing you have to do is to create a new front end for that language.
The back end is same for all the languages. Different front ends exist
for different languages.
Так вот, весь API: treelang, RTL (Register Transfer Language), все
библиотеки поддержки,- для написания frontend'а для GCC написан на
чистом С (даже несовместимом с С++). Чтобы писать фронтенд на другом
языке, придется обернуть существующий API. В теории это сделать можно —
для ADA в GCC уже есть такой адаптер, но это требует достаточно много
работы.
Здравствуйте, Cyberax, Вы писали:
C>Так вот, весь API: treelang, RTL (Register Transfer Language), все C>библиотеки поддержки,- для написания frontend'а для GCC написан на C>чистом С (даже несовместимом с С++). Чтобы писать фронтенд на другом C>языке, придется обернуть существующий API. В теории это сделать можно — C>для ADA в GCC уже есть такой адаптер, но это требует достаточно много C>работы.
Теперь понял о чем вы. Дык фронтэнд уже есть. Только он несовместим с GCC. Так что задачу можно сформулировать как создание конвертера из формата одного фрэнтэнда в другой.
Задача в общем-то подъемная. Вот только когда вы сделаете компилятор, то поймете, что в дотнет-языках рантай чуть ли более важен чем компилятор. Да и библиотеки тоже фактор не маловажный.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>Так вот, весь API: treelang, RTL (Register Transfer Language), все > C>библиотеки поддержки,- для написания frontend'а для GCC написан на > C>чистом С (даже несовместимом с С++). Чтобы писать фронтенд на другом > C>языке, придется обернуть существующий API. В теории это сделать можно — > C>для ADA в GCC уже есть такой адаптер, но это требует достаточно много > C>работы. > Теперь понял о чем вы. Дык фронтэнд уже есть. Только он несовместим с > GCC. Так что задачу можно сформулировать как создание конвертера из > формата одного фрэнтэнда в другой.
Тут скорее нужен фронтенд для всего CLR IL. До недавнего времени это
было невозможно, так как GCC в процессе компиляции терял информацию о
типах. Примерно год назад стало возможным сохранять информацию о типах,
так что компилятор CLR->native, в теории, возможен.
На практике, в багтрекере Mono до сих пор висит task "Исследовать
возможность использования GCC".
> Задача в общем-то подъемная. Вот только когда вы сделаете компилятор, то > поймете, что в дотнет-языках рантай чуть ли более важен чем компилятор.
Runtime — это GC и библиотеки языковой поддержки. Boehm GC работает без
проблем практически со всем, что только существует. Библиотеки языковой
поддержки действительно придется переписать.
> Да и библиотеки тоже фактор не маловажный.
Скомпилировать в нативный код библиотеки Mono
Здравствуйте, Cyberax, Вы писали:
C>Тут скорее нужен фронтенд для всего CLR IL.
Скорее наоборот. Для IL нужен бэкэнд.
C> До недавнего времени это C>было невозможно, так как GCC в процессе компиляции терял информацию о C>типах. Примерно год назад стало возможным сохранять информацию о типах, C>так что компилятор CLR->native, в теории, возможен.
Я же говорю в ваших рассуждениях каша.
Почему вообще возможность компиляции IL в нэйтив-код вообще должна касаться GCC?
IL давно компилируется в нэйтивный код разными способами (Борток, Феникс, утилиты третьих фирм).
C>На практике, в багтрекере Mono до сих пор висит task "Исследовать C>возможность использования GCC".
Видимо из-за отсуствия особой необходимости.
C>Runtime — это GC и библиотеки языковой поддержки. Boehm GC работает без C>проблем практически со всем, что только существует. Библиотеки языковой C>поддержки действительно придется переписать.
Языком все работает. А на практике хрена два ты сможешь осилить все что нужно.
Boehm GC твой — это детский лепет по сравнению с тем, что реально нужно сделать.
А "библиотеки" это только звучит так коротко. А на практике среди библиотек должны быть такие вещи как System.Reflection. И GCC с их реализацией никак не поможет.
>> Да и библиотеки тоже фактор не маловажный. C>Скомпилировать в нативный код библиотеки Mono
Языком все просто. На практике тот же Барток сильно урезает функциональность. А Феникс не живет без дотнета.
В общем, если бы это было просто, и действительно нужно, то давно было бы сделано.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>Тут скорее нужен фронтенд для всего CLR IL. > Скорее наоборот. Для IL нужен бэкэнд.
А зачем? На семантику IL обычные языки ложаться очень плохо.
А вот получить компилятор из IL в машинные коды примерно 40 платформ —
это гораздо интереснее.
> Почему вообще возможность компиляции IL в нэйтив-код вообще должна > касаться GCC?
В IL можно и без GCC нормально скомпилировать. То есть если для того,
чтобы сделать Native Nemerle достаточно будет просто собрать компилятор
IL2Native.
> C>На практике, в багтрекере Mono до сих пор висит task "Исследовать > C>возможность использования GCC". > Видимо из-за отсуствия особой необходимости.
Таск большой и сложный, некому заняться.
> Языком все работает. А на практике хрена два ты сможешь осилить все что > нужно.
> Boehm GC твой — это детский лепет по сравнению с тем, что реально нужно > сделать.
Ага, Mono — отстой.
> А "библиотеки" это только звучит так коротко. А на практике среди > библиотек должны быть такие вещи как System.Reflection. И GCC с их > реализацией никак не поможет.
Поможет. GCC может писать информацию о типах в любом виде (например, в
XML), так что собрать reflection-package можно без особых проблем.
В GCC-XML это даже для С++ сделали.
> В общем, если бы это было просто, и действительно нужно, то давно было > бы сделано.
А если не сделать, то .NET дальше своей ниши не уйдет.
