[Nitra] Отчет от 09.01.2016
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.01.16 23:40
Оценка: 22 (3)
На сегодня сделали:
1. Библиотечную поддержку унификации и вывода типа на его основе. Она довольно не плохо вписалась в язык зависимых свойств (по сути реализована на базе них). Это позволяет реализовать вывод типов в языках типа C#. Возможно его (с небольшим допиливанием) хватит и для того чтобы поднять вывод типов Nemerle.

2. Реализована специализация для новой подсистемы символов и AST-а.

3. Начал реализовывать бэкэнд на основе CCI Metadata. Реализовал загрузку Nitra-символов для дотнета на базе CCI. Есть мелкие недоработки (например, пока не грузятся значения пользовательских атрибутов), но в целом работает. Например, в нашем C#-е можно ссылаться на символы из внешних сборок.

4. Описание AST и символов для .Net-языков выделили в отдельную библиотеку (DotNetLang. Это позволяет существенно упростить создание разных языков для дотнета, но (что намного важнее) использовать в своих мини-языках символы дотнета. Например, если мы хотим сделать человекочитаемый синтаксис для XAML-а, то символы описывающие контролы будут доступны из коробки — DotNetLang.dll, а их загрузка из другой коробки — DotNet.BackEnd.CCI.dll.

Тест демонстрирующий ссылку на символ описывающий тип System.IO.FileInfo расположенный в mscorlib.dll:
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Отредактировано 11.01.2016 10:35 VladD2 . Предыдущая версия . Еще …
Отредактировано 11.01.2016 10:33 VladD2 . Предыдущая версия .
Отредактировано 11.01.2016 10:31 VladD2 . Предыдущая версия .
Re[9]: [Nitra] Отчет от 09.01.2016
От: WolfHound  
Дата: 12.01.16 08:55
Оценка: 7 (2) +1
Здравствуйте, VladD2, Вы писали:

VD>Без ЖЦ это уже не C#/Nemerle будет. Даже если сделать автоматический подсчет ссылок, все равно семантика будет иная.

1)Найтра это не прикладной язык типа C#/Nemerle/Java/C/C++ итп, а набор языков для создания языков. Так что ограничивать создаваемые языки языками с ГЦ нет вообще никакого смысла.
2)Есть задачи, для которых нужен ГЦ. Есть задачи, для которых вреден ГЦ. И те, и другие нужно решать. Соответственно нужны бэкенды с ГЦ и без ГЦ.
3)Для ЯВУ типа C# и C++ важен тип бэкенда.
С другой стороны, многие ДСЛ могут работать поверх разных типов бэкендов. Ибо их предметная область не содержит никаких намёков на то как именно нужно памятью рулить.
Те большая часть (80%-90%) условных Nemerle.Web и BLToolKit может быть реализована универсально. И лишь небольшая часть логики ответственная за управление памятью должна быть реализована по-разному для разных типов бэкндов.

WH>>Одно из перспективных применений нитры переносимый макроассемблер.

VD>Я надеюсь ты используешь термин "макроассемблер" в переносном смысле?
Я использую термин "переносимый макроассемблер".
Ядро языка должно содержать только конструкции, которые можно транслировать в любой конкретный ассемблер.
Всё остальное включая целочисленную арифметику должно идти в библиотеках.
Ессно писать на таком языке будет весьма неудобно. Но для того мы и пишем натру чтобы можно было поднять уровень языка.
Ессно в комплекте будет множество языковых модулей, которое поднимает уровень языка намного выше С++.
Но у пользователя будет возможность выкинуть то что ему не нужно и добавить то что нужно.
Короче качественная реализация принципа С++ "не платишь за то, что не используешь".
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: [Nitra] Отчет от 09.01.2016
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.01.16 21:12
Оценка: +1
Здравствуйте, xy012111, Вы писали:

X>Пока да, но, мне показалось, и остальное на подходе:

X>

X>New API (SignatureDecoder and MetadataWriter) are incoming.


Ну, ОК. Как сделают — поддержим. Мы сразу рассчитывали на множественные бэкэнды, так что это не будет сложно. Внутри Nitra метаданные представлены всегда символами Nitra. Бэкэнд только осуществляет преобразование из внешнего формата API в наши символы и обратно.

Плюс, уверен, что первое время там будет много багов. Так что лучше погодить немного. Выкатят писалку, поддержим и их.

ЗЫ

Потенциально можно бэкэнды сделать даже для Java и LLVM. Это даже намного интереснее будет, так как языки с ними совместимые автоматом будут заводиться на этих платформах. С LLVM сложнее, так как нужно изобретать GC для него. А вот с Java вполне возможно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [Nitra] Отчет от 09.01.2016
От: WolfHound  
Дата: 11.01.16 21:52
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>С LLVM сложнее, так как нужно изобретать GC для него.

Не обязательно. Можно языки и без ГЦ делать.
Одно из перспективных применений нитры переносимый макроассемблер.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: [Nitra] Отчет от 09.01.2016
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.01.16 23:36
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>Не обязательно. Можно языки и без ГЦ делать.


Без ЖЦ это уже не C#/Nemerle будет. Даже если сделать автоматический подсчет ссылок, все равно семантика будет иная.

WH>Одно из перспективных применений нитры переносимый макроассемблер.


Я надеюсь ты используешь термин "макроассемблер" в переносном смысле?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: [Nitra] Отчет от 09.01.2016
От: jazzer Россия Skype: enerjazzer
Дата: 12.01.16 06:13
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


VD>jazzer, ты не стесняйся, высказывайся. А то твои минусы информации ведь не несут.


Просто не хочется, чтобы Нитра прошла по тем же самоубийственным граблям, что и Немерле в свое время.
Мне вот, несмотря на весь мой интерес к метапрограммированию, Немерле была совершенно неинтересна по той простой причине, что она гвоздями приколочена к .NET. И я, как ты понимаешь, не один такой.
Если вы ограничите Нитру только языками с GC, то это точно так же отсеет огромную часть разработчиков, которые пишут на языках без GC (опять же, включая меня), как это случилось с Немерле.
Вот и всё.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: [Nitra] Отчет от 09.01.2016
От: xy012111  
Дата: 11.01.16 03:43
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>3. Начал реализовывать бэкэнд на основе CCI Metadata.


А это имеет смысл? Мне показалось, что я где-то видел, что в core clr добавляют замену CCI… Или, как эта замена зарелизится, не сложно будет перейти и на неё?
Re[2]: [Nitra] Отчет от 09.01.2016
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.01.16 11:01
Оценка:
Здравствуйте, xy012111, Вы писали:

X>А это имеет смысл? Мне показалось, что я где-то видел, что в core clr добавляют замену CCI… Или, как эта замена зарелизится, не сложно будет перейти и на неё?


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

Что касается замены CCI в Core CLR то я о таком не слышал. Дай ссылку на то о чем ты говоришь, посмотрим.

Вообще, есть множество альтернативных читалок метаданных. Например, своя читалка есть даже в ReSharper-е (отличается высокой скоростью работы). Вот только читалки нам мало. В перспективе мы хотим генерировать сборки с помощью наших бэкэндов. По этому на нужна библиотека которая позволяет не только читать метаданные, но и писать их, а так же писать MSIL, pdb и прочее. Таких библиотек уже меньше, но тоже достаточно. Вот только они каждая из них имеет свои достоинства и недостатки. Мы остановились на CCI Metadata потому что это наиболее комплексное и проверенное решение.

CCI Metadata взят за основу в Roslyn. Но, к сожалению, они его скопипастили в свой проект, сделали все внутренности недоступными (internal, private), так что использовать Roslyn, без ручного патчинга кода, не представляется возможным.

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

Пока что с CCI возникла только одна проблема. Их ссылки на типы требуют резовла (грубо говоря выополнения некоторого кода). Резолв у них оказался довольно тормозным. Так, например, загрузка списка типов из 36 сборок занимает какие-то доли секунды, а получение списка базовых типов боле более 5 секунд. К счастью мы нашли как обойтись без их резолва (нам достаточно сравнения типов по внутренним целочисленным идентификатором), так что загрузка получилась довольно быстрой.

Возможно в будущем выявятся какие-то другие проблемы, но пока CCI выглядит вполне приемлемым решением.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Nitra] Отчет от 09.01.2016
От: xy012111  
Дата: 11.01.16 12:01
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Что касается замены CCI в Core CLR то я о таком не слышал. Дай ссылку на то о чем ты говоришь, посмотрим.

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

Вот кажется это оно и есть: System.Reflection.Metadata (сначала промахнулся, это в corefx, а не в coreclr).
Отредактировано 11.01.2016 12:08 xy012111 . Предыдущая версия .
Re[4]: [Nitra] Отчет от 09.01.2016
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.01.16 19:20
Оценка:
Здравствуйте, xy012111, Вы писали:

X>Вот кажется это оно и есть: System.Reflection.Metadata (сначала промахнулся, это в corefx, а не в coreclr).


Насколько я понимаю — это только читалка. Для компилятора же нужна еще и "писалка", т.е. возможность сохранить символы в сборку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [Nitra] Отчет от 09.01.2016
От: xy012111  
Дата: 11.01.16 19:44
Оценка:
Здравствуйте, VladD2, Вы писали:

X>>Вот кажется это оно и есть: System.Reflection.Metadata (сначала промахнулся, это в corefx, а не в coreclr).

VD>Насколько я понимаю — это только читалка. Для компилятора же нужна еще и "писалка", т.е. возможность сохранить символы в сборку.

Пока да, но, мне показалось, и остальное на подходе:

New API (SignatureDecoder and MetadataWriter) are incoming.

Re[9]: [Nitra] Отчет от 09.01.2016
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.01.16 02:02
Оценка:
Здравствуйте, VladD2, Вы писали:

jazzer, ты не стесняйся, высказывайся. А то твои минусы информации ведь не несут.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: [Nitra] Отчет от 09.01.2016
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.01.16 19:52
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>1)Найтра это не прикладной язык типа C#/Nemerle/Java/C/C++ итп, а набор языков для создания языков. Так что ограничивать создаваемые языки языками с ГЦ нет вообще никакого смысла.


Я и не предлагаю это делать. Найдутся те кто хочет реализовать Swift или Rust, я с радостью поддержу это начинание. Но C# и Nemerle — это языки спроектированные под GC. Для них нужно хотя бы реализовать нечто вроде автоматического рефкаутинга и то будет не тоже самое.

WH>2)Есть задачи, для которых нужен ГЦ. Есть задачи, для которых вреден ГЦ. И те, и другие нужно решать. Соответственно нужны бэкенды с ГЦ и без ГЦ.


Опять же не спорю. Для той же Нитры можно обойтись без ЖЦ (плуми и подсчетом ссылок, например). Но в этой теме говорится о C# и Nemerle.

WH>3)Для ЯВУ типа C# и C++ важен тип бэкенда.


Для плюсов — возможно. Шарп можно перенести на Java или LLVM без заметных проблем.

WH>С другой стороны, многие ДСЛ могут работать поверх разных типов бэкендов.


Опять же не спорю. Но в теме речь о C#/Nemerle.

WH>Те большая часть (80%-90%) условных Nemerle.Web и BLToolKit может быть реализована универсально.


BLToolKit — это библиотека под донтен. Конечно если перенести C# на другую платформу, то он и там будет работать (при условии портироания библиотек связанных с линком). Но без того же GC ничего работать не будет, так как при его проктировании расчет делался на использование GC. Например, те же циклические ссылки не отслеживались. Так что будучи запущенным под управлением системы с подсчетом ссылок он просто убудет жрать ресурсы и падать.

WH>И лишь небольшая часть логики ответственная за управление памятью должна быть реализована по-разному для разных типов бэкндов.


Нет батеька. Если код пишется в расчете на GC, то без него он работать скорее всего не будет.

WH>>>Одно из перспективных применений нитры переносимый макроассемблер.

VD>>Я надеюсь ты используешь термин "макроассемблер" в переносном смысле?
WH>Я использую термин "переносимый макроассемблер".
WH>Ядро языка должно содержать только конструкции, которые можно транслировать в любой конкретный ассемблер.

Ну, то есть под ассемблером имеется в виду минимальный набор инструкций платформы? В таком, философском, смысле с этим можно согласиться.

WH>Всё остальное включая целочисленную арифметику должно идти в библиотеках.


Разве что, если подразумевать, что эти библиотеки — это intristic-функции.

Короче, опять вижу много фантазии оторванной от жизни и приправленной кучей философии.

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

WH>Но у пользователя будет возможность выкинуть то что ему не нужно и добавить то что нужно.


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

Вот, например, в теории инкрементальное редактирование плевое дело. А на практике ты с ним справиться не можешь.

WH>Короче качественная реализация принципа С++ "не платишь за то, что не используешь".


Это все красивые слова. И к теме они отношения не имеют. Если мы хотим реализовать C#, то на платформе должен быть GC или нечто его очень качественно эмулирующее, так как ни дин кодер на C# не будет писать программы намеренно втискивающиеся в рамки мира в котором нет GC.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: [Nitra] Отчет от 09.01.2016
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.01.16 19:59
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Просто не хочется, чтобы Нитра прошла по тем же самоубийственным граблям, что и Немерле в свое время.

J>Мне вот, несмотря на весь мой интерес к метапрограммированию, Немерле была совершенно неинтересна по той простой причине, что она гвоздями приколочена к .NET. И я, как ты понимаешь, не один такой.

Теперь представь себе как я могу вывести всю эту информацию из твоего минуса. Представил? Если, да то трудись, плиз, выражать свое мнение не только в виде оценок которые можно интерпретировать по разному.

J>Если вы ограничите Нитру только языками с GC, то это точно так же отсеет огромную часть разработчиков, которые пишут на языках без GC (опять же, включая меня), как это случилось с Немерле.


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

Сама Нитра спроектирована так чтобы позволять выражать любые системы типов и любые особенности ратнтайма. Ей они просто по фигу. Для нее все это не боле чем набор символов и алогоритмов работы с ними.

Но конкретный язык — это совсем другое дело. Можно реализовать скажем C# или Nemerle на базе подсчета ссылок, но такой языке будет не полностью совместим с полноценными C# или Nemerle. На этом не полноценном языке даже можно написать множество программ. Но это будут программы на подмножестве C# или Nemerle, а не на C# или Nemerle. Программист должен будет учитывать потенциальные циклические ссылки и разруливать их самостоятельно. А это значит, что многие алгоритмы будет другими.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: [Nitra] Отчет от 09.01.2016
От: WolfHound  
Дата: 12.01.16 21:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Опять же не спорю. Для той же Нитры можно обойтись без ЖЦ (плуми и подсчетом ссылок, например).

Что-то ты на C# и Nemerle зациклился.

VD>Но в этой теме говорится о C# и Nemerle.

Не понимаю откуда ты вытащил эту жесткую привязку.

WH>>3)Для ЯВУ типа C# и C++ важен тип бэкенда.

VD>Для плюсов — возможно. Шарп можно перенести на Java или LLVM без заметных проблем.
Я говорил про есть или нет ГЦ. Что останется от шарпа если у него не будет ГЦ?

VD>BLToolKit — это библиотека под донтен.

Это набор ДСЛ которые ничего не говорят про управление памятью.
Если мне не изменяет память циклов при построении ЛИНК запросов не возникает.

VD>Конечно если перенести C# на другую платформу,

C# тут вообще не причём.
Эти ДСЛ можно натянуть на что угодно.

WH>>И лишь небольшая часть логики ответственная за управление памятью должна быть реализована по-разному для разных типов бэкндов.

VD>Нет батеька. Если код пишется в расчете на GC, то без него он работать скорее всего не будет.
В каком месте ДСЛи Nemerle.Web и BLToolKit требуют ГЦ?

VD>Ну, то есть под ассемблером имеется в виду минимальный набор инструкций платформы? В таком, философском, смысле с этим можно согласиться.

"переносимый макроассемблер"
Имеется в виду набор инструкций, который есть у всех фон Неймановских машин.

VD>Разве что, если подразумевать, что эти библиотеки — это intristic-функции.

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

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

По жизни С работает примерно на всех процессорах.

VD>GC является довольно серьезной зависимостью.

Что-то я не слышал про распространённые процессоры с ГЦ.

WH>>Но у пользователя будет возможность выкинуть то что ему не нужно и добавить то что нужно.

VD>Это все влажные мечты.
Это то что у нас УЖЕ есть.

VD>Вот, например, в теории инкрементальное редактирование плевое дело. А на практике ты с ним справиться не можешь.

Я этим вообще не занимался.

WH>>Короче качественная реализация принципа С++ "не платишь за то, что не используешь".

VD>Это все красивые слова. И к теме они отношения не имеют.
Тема про возможности найтры. Так что имеют.
Тем более у меня есть такое чувство что нативный язык имеет больше перспектив чем язык под .НЕТ.
Ибо на под .НЕТ всё что не от макрософт не живёт от слова совсем.

VD>Если мы хотим реализовать C#, то на платформе должен быть GC или нечто его очень качественно эмулирующее, так как ни дин кодер на C# не будет писать программы намеренно втискивающиеся в рамки мира в котором нет GC.

А я и не говорю про кодеров на C#.
Я сразу сказал, что есть задачи, которые на языках с ГЦ решать не разумно.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: [Nitra] Отчет от 09.01.2016
От: jazzer Россия Skype: enerjazzer
Дата: 14.01.16 15:11
Оценка:
Здравствуйте, VladD2, Вы писали:

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


J>>Просто не хочется, чтобы Нитра прошла по тем же самоубийственным граблям, что и Немерле в свое время.

J>>Мне вот, несмотря на весь мой интерес к метапрограммированию, Немерле была совершенно неинтересна по той простой причине, что она гвоздями приколочена к .NET. И я, как ты понимаешь, не один такой.

VD>Теперь представь себе как я могу вывести всю эту информацию из твоего минуса. Представил? Если, да то трудись, плиз, выражать свое мнение не только в виде оценок которые можно интерпретировать по разному.


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

J>>Если вы ограничите Нитру только языками с GC, то это точно так же отсеет огромную часть разработчиков, которые пишут на языках без GC (опять же, включая меня), как это случилось с Немерле.


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


VD>Сама Нитра спроектирована так чтобы позволять выражать любые системы типов и любые особенности ратнтайма. Ей они просто по фигу. Для нее все это не боле чем набор символов и алогоритмов работы с ними.


Ок, когда можно будет увидеть Нитру для Си? (Не говорю про С++, он слишком сложен, наверное)

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


Да мне пофиг на C# или Nemerle или любые другие языки, заточенные под рантайм со сбором мусора. Я с ними не работаю, они меня не интересуют в этом плане. А когда я с ними работаю — то мне возможностей того же Питона в принципе хватает (хотя Хаскель поинтереснее в плане метапрограммирования, не говоря уже о Перле).
Мне интересует применение Нитры к нативным языкам типа того же С++ или хотя бы Си.
Вот, как вариант, можно ли сделать на Нитре простенькое подобие шаблонов С++ для Си?
Я ведь правильно понимаю суть Нитры — берем язык (Си) и добавляем в него фичи, после чего получается Си-с-фичами, которые может прожевать компилятор Нитры и выплюнуть на выходе либо низкоуровневый код (LLVM?) либо голый Си для дальнейшей компиляции обычным компилятором (т.е. аналог cfront)?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[13]: [Nitra] Отчет от 09.01.2016
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.01.16 16:27
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Ок, когда можно будет увидеть Нитру для Си? (Не говорю про С++, он слишком сложен, наверное)


Потенциально можно. Но нужно понимать, что под "Нитру для Си" можно понимать две разные вещи (которые обе, потенциально, возможны):
1. Нитра которая не использует рантайм дотнета. Все утилиты такой версии Нитры будут скомпилированы в найтив.
2. Си компилятор которого и интеграция с IDE сделаны с помощью Нитры.

Важно понимать, что Нитра — это такой же язык и набор "утилит" к нему, как и любой другой. Наличие бэкэндов позволяет на Нитре разработать язык (другой) под платформу для которой есть бэкэнд. При этом не любой язык может быть сомвместим с любым бэкндом. Например, Си можно с легкостью "поднять" на любом бэкэнде, так как язык очень простой и имеющиеся в нем фичи есть почти везде (нужны только указатели). А вот C# уже потребует наличие ратнайма умеющего автоатически управлять памятью.

Натри написана в расчете на рант с ЖЦ. Но ее не трудно подпачить так чтобы она использовала пулы вместо ЖЦ. С C# это уже, в общем случае, невозможно.

J>Мне интересует применение Нитры к нативным языкам типа того же С++ или хотя бы Си.

J>Вот, как вариант, можно ли сделать на Нитре простенькое подобие шаблонов С++ для Си?

Можно. Но тебе придется реализовать нативный (или основанный на LLVM) бэкэнд (или дождаться когда его реализует кто-то другой). Потенциально можно реализовать его и на .net-бэкэнде, но тогда он будет чем-то вроде менеджед-Си, т.е. будет запускаться на дотнете.

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

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

J>Я ведь правильно понимаю суть Нитры — берем язык (Си) и добавляем в него фичи, после чего получается Си-с-фичами,


Все верно. Только "берем" означает, что ты должен реализовать этот язык на Нитре. Вот когда он есть, то можно добавлять в него фичи хоть отдельными модулями.

J>которые может прожевать компилятор Нитры и выплюнуть на выходе либо низкоуровневый код (LLVM?) либо голый Си для дальнейшей компиляции обычным компилятором (т.е. аналог cfront)?


Да. Но для этого нужно создать соответствующие бэнэнды для Нитры. И сама Нитра останется дотнет-приложением. Но потенциально, если написать бэкнд для немерла поддерживающий другую платформу, саму Нитру так же можно будет запускать на другой VM или в нэйтиве. И вот тут появляется делема, так как язык рассчитанный на ЖЦ требует чтобы ратнтайме была поддержка ЖЦ.

Так что минус твой не о чем. Ты просто не верно меня понял. По тому я тебе и говорю, что надо не минусами бросаться, а вопросы задавать. Иначе никакой информации не будет. Один негатив.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.