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

_>>Да, да, им про это уже не раз писали. И они не раз дежурно отмахивались, что сейчас на это нет ресурсов (людей). Не понимая, что это должно быть не ещё одним побочным направлением развития, которое возможно сделает кто-то из сообщества, а именно главным направлением, над которым должен работать главный разработчик.
VD>Орлы, вы поймите, создание современного ЯП — это огромный труд. Большая часть работы по нему не зависит от платформы, так как это код парсинга, тапизации, и т.п. Не сделав всего этого говорить о платформах просто смешно.
VD>Но если вы хотите иметь найтив-продукт, то в этом нет никаких проблем. Просто присоединяйтесь и я вам расскажу, что нужно сделать, чтобы получить нэйтив-реализацию. Там все не так уж сложно. Но без вашей помощи мы не справимся.

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

1. Все ваши инструменты бутстрапятся, правильно? Т.е. если мы вдруг реализуем компиляцию "hello world" в нейтив на базе ваших существующих .net компиляторов, то потом автоматически получим нативную версию всех инструментов (в первую очередь компилятора, ну и всего остального что у вас там есть)?

2. Насколько язык заточен на CLR? Т.е. от каких из негативных моментов CLR можно будет отказаться при переходе на нативный код, а от каких нельзя. В первую очередь речь о: сборщике мусора, интроспекции времени исполнения (рефлексии, от которой кстати отказываются в .net native), ссылочных (а не на стеке, кстати тоже пытаются ввести в будущем в .net) объектах, неэффективных дженериках и делегатах. А так же насколько доступны unsafe возможности (например арифметика указателей) CLR и можно ли их расширить ещё дальше (нативное выделение памяти и т.п., кстати тоже пытаются ввести определённым образом в будущем в .net)..

3. Насколько язык заточен на библиотеку .Net. Именно язык, а не предоставление .net в качестве стандартной библиотеки языка для пользователя (т.е. речь об аналоге взаимоотношений new и VirtualAlloc из C++). Саму библиотеку для пользователя на самом деле написать не так сложно (полно готовые открытых разработок на эту тему). А в самое первое время можно вообще обойтись возможностью доступа к API ОС (для нативного кода это естественно). В отличие от потребностей самого языка, которые надо будет или переделывать внутри или реализовывать функции аналогичные .net.

В зависимости от ответов можно сделать вывод о том, что с помощью например таких (https://habrahabr.ru/post/119850/) инструментов можно сделать нативную реализацию:
— легко
— сложно
— сложно и не нужно (потому что нативная реализация языка с такими врождёнными пороками просто не нужна).