Dv
Просто наша — она не совсем наша
Size: a a a
2019 July 03
Dv
В смысле таргет платформа у него другая, например
Dv
Ну и там ещё есть некоторые особенности резолва, из-за которых ты не хочешь загружать либы во время компиляции
Dv
Потому что загрузка либов любит отваливаться
Dv
По пустякам каким-нибудь
Dv
Т.е. ошибка резолва типов во время компиляции может не воспроизводиться в рантайме, даже если у тебя какой-то либы (обычно семиколенной зависимости какой-нибудь) не хватает
AK
Охотно верю, что с компиляцией под целевую платформу, отличную от текущей, может быть куча приколов. Такое RefEmit впринципе не поддерживает. Но разве есть что-то, что избавит тебя от этого гемора при разработке языка под NET?
AK
Какой-то типа языковой фреймворк со встроенной поддержкой нугета сразу?
AK
Я знаю про CCI, но вряд ли там такое есть, да и после перехода на Roslyn он вроде как устарел
2019 July 05
DB
А зачем такие сложности? Не проще транслировать язык в C#, а его уже комплировать стандартными средствами под любую платформу?
Зачем изобретать свой Roslyn?
Зачем изобретать свой Roslyn?
B
Громадяне!
Была на ютубе инфа, что использовать Reflection.Emit для создания бэкенда компилятора - плохая идея. Так ли это, и если нет, то что лучше использовать для этого. Есть ли вообще какая-то литература\рефернсы в целом по переносу языков на CLI
Была на ютубе инфа, что использовать Reflection.Emit для создания бэкенда компилятора - плохая идея. Так ли это, и если нет, то что лучше использовать для этого. Есть ли вообще какая-то литература\рефернсы в целом по переносу языков на CLI
Плохо, потому что емит может только под текущий фремворк, нельзя кросскомпиляцию делать скажем в кор с обычной, или в нетстандарт
Dv
А зачем такие сложности? Не проще транслировать язык в C#, а его уже комплировать стандартными средствами под любую платформу?
Зачем изобретать свой Roslyn?
Зачем изобретать свой Roslyn?
1. Лол это для неосиляторов
2. Семантика твоего языка совершенно необязательно напрямую транслируется в C#
3. А с дебагом что?
2. Семантика твоего языка совершенно необязательно напрямую транслируется в C#
3. А с дебагом что?
DB
2. А зачем гадать? Тут же конкретный случай, а не решение на все случаи жизни.
3. Тоесть .NET сборку с отладочными символами и валидным кодом дебажить сложнее, чем сгенерированный IL? D:
3. Тоесть .NET сборку с отладочными символами и валидным кодом дебажить сложнее, чем сгенерированный IL? D:
AK
2. А зачем гадать? Тут же конкретный случай, а не решение на все случаи жизни.
3. Тоесть .NET сборку с отладочными символами и валидным кодом дебажить сложнее, чем сгенерированный IL? D:
3. Тоесть .NET сборку с отладочными символами и валидным кодом дебажить сложнее, чем сгенерированный IL? D:
.NET сборка будет содержать отладочные символы для промежуточного кода на сишарпе, а не для исходного кода на создаваемом языке
DB
А так их не будет вовсе.
AK
почему?
DB
Потому что автору придется пилить еще и отладчик. Вопрос - зачем?
AK
Не отладчик, а только генерацию pdb
DB
Хмм.
AK
Это довольно несложный процесс, по крайней мере в RefEmit - наверняка в Mono.Cecil тоже