Здравствуйте, 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/) инструментов можно сделать нативную реализацию:
— легко
— сложно
— сложно и не нужно (потому что нативная реализация языка с такими врождёнными пороками просто не нужна).
Здравствуйте, alex_public, Вы писали:
_>1. Все ваши инструменты бутстрапятся, правильно? Т.е. если мы вдруг реализуем компиляцию "hello world" в нейтив на базе ваших существующих .net компиляторов, то потом автоматически получим нативную версию всех инструментов (в первую очередь компилятора, ну и всего остального что у вас там есть)?
Упрощенно говоря — да. Компилятор языка это текст плюс ратнтайм, плюс используемый внешний АПИ. Если мы можем компилировать этот текст самим собой, то все что нужно для переноса языка на другую платформу — это скомпилировать себя собой с бэкэндом для этой платформе.
Естественно при этом есть нюансы.
1. АПИ — компилятор использует ряд вызовов рантайма. Их надо воспроизвести в целевом рантайме. Собственно мы используем минимум:
* Работа со строками в формате UTF-16 (классы string и StringBuilder).
* Коллекции (List<T>, HashSet<T>, Dictionary<R, V>, ImmutableArray и т.п.) все это есть в исходниках в библиотеках на гитхабе. Да и написать с нуля не долго.
* Чтение и запись файлов.
* Динамическая загрузка библиотек, создание экземпляра объекта и вызов его метода (это нужно для динамической расширяемости).
Если брать не только компилятор, но и движок IDE, то нужны еще:
* Именованные каналы для общения с сервером движка IDE.
* АПИ по работе с потоками и процессами для организации параллельных вычислений.
Конечно же код работы непосредственно с IDE просто перекомпилировать не удастся. У все IDE свои АПИ. Для них надо писать фронтэнд вручную. Движек же IDE у нас работает в отдельном процессе и взаимодействует с фронтэндом через именованные каналы. Так что сервер может работать на платформе отличной от той на которой работает IDE. Фронтэнд у нас очень тонкий. Логики там нет. Он просто должен реализовывать АПИ IDE и преобразоывать их в посылку и прием сообщений IDE-серверу живущему в отдельном процессе.
_>2. Насколько язык заточен на CLR?
Тут, для начала, надо определиться о том, что понимать под понятием "язык". Мы делаем язык для "написания языков" (т.е. компиляторов и тулинга). Называется он Nitra. При его разработке используется как он сам, так и код на языке общего назначения — Nemerle. Сейчас используется Nemerle 1.2.х, который написан сам на себе с применением все того же бустрапинга. Его минус в том, что он не поддерживает сменяемые бэкэнды. В процессе работы над Нитрой мы хотим переписать сабсэт Nemerle используемый в Нитре на Нитре, чтобы забутстрапить и Нитру, и этот сабсэт Нимерла с использованием бэкэндов. В принципе можно было бы перевести на бэкэнды и старый Немерл. Но я в этом не вижу особого смысла. Работы много, толку мало.
В Нитре и этом сабсэте Немерла используются:
1. Автоматическое управление памятью. Для компилятора можно просто выделять память из одного непрерывного блока и тупо забить на его освобождение (делать его для всего пула в конце компиляции). Будет перерасход процентов в 10-20, но учитывая объемы современной памяти — это не критично. На первое время сойдет. Ну, или реализовать самый примитивный вариант GC и вызывать сборку мусора вручную в известных точках. Для движка IDE такой способ будет неприемлем, но для компилятора — прокатит. Далее, конечно, надо реализовать точный GC на основе поколений или один из новомодных алгоритмов. Еще один вариант — реализовать автоматическое управление памятью на базе подсчета ссылок. По сути это ограниченный ЖЦ.
2. Динамическая загрузка кода. Грамматики, код типизации и бэкнд помещаются в библиотеки. Во время исполнения они подгружаются как в компилятор, так и в движок IDE. Там они компонуются с другими такими же сущностными и получается конечный парсер, типизатор и бэкэнд. Эту часть можно абстрагировать в виде АПИ и реализовать для каждой из платформ на базе их родного АПИ. Подгружаемые типы являются монотипными (т.е. не обобщенными).
3. ООП дотнетного типа:
* Классы с одним предком.
* Интерфейсы с множественным наследованием.
* Виртуальные таблицы.
Тут нужна поддержка в рантайме. Таблицы интерфейсов и виртуальная таблица методов. Собственно как это все делается известно. Но это требует реализации.
Дженерики, конечно же нами тоже используются, но в рамках обобщенных типов данных. Никаких динамических загрузок обобщенных типов не требуется, так что их можно реализовать путем генерации специализаций.
Нитра предоставляет сериализацию символов и АСТ-а. Так что дженерики можно будет записывать в библиотеки в виде АСТ-а и символов, а потом материализовывать их для конкретных типов (как шаблоны С++ только без исходников).
Рефлексия нами по сути не используется. Только для той самой подгрузки грамматик (что может быть абстрагированно).
Нитра из коробки предоставляет метаданные для всех внутренностей любого языка написанного на Нитре. Так что для языка не составит труда реализовать и рефлексию и прочий блэкджек с девочками. Причем сериализация и десериализация метаинформации производится с помощью генерации кода. Это с одной стороны быстро, а с другой не привязывает нас к АПИ вроде рефлексии.
Все вышесказанное было о бутстрап-языке, т.е. минимуме необходимом для самовоспроизведении. Важно понимать, что Нитра — это конструктор.
Немерл на его базе позволит как добавлять новые фичи (в виде компонентов), так и отключать имеющиеся (при условии, что при их разработке соблюдалась модульность).
Таким образом каждый сможет создать для себя свой набор необходимых ему фич. Если тебе не хочется использовать автоматическое управление памятью и ты согласен выписывать руками конструкторы с деструкторами, а так же следить за памятью вручную, то можешь просто сделать расширение с ручным управлением памятью.
Кстати, работа с указателями была в дотнете и Шарпе с самого начала. Просто она мало кому была нужна на практике. Ну, и без деструкторов все это было весьма печально.
_>3. Насколько язык заточен на библиотеку .Net. Именно язык, а не предоставление .net в качестве стандартной библиотеки языка для пользователя
Этого вообще не понял. Языку просто по фигу какая там у него библиотека. Вот библиотека от языка зависит. Если у нас язык с ЖЦ, то и в библиотеке должны быть ЖЦ-типы.
Для бутстрапинга нужно воспроизвести ряд классов, но их набор не велик и почти все они есть в исходниках. Так что их надо будет просто скомпилировать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_>>1. Все ваши инструменты бутстрапятся, правильно? Т.е. если мы вдруг реализуем компиляцию "hello world" в нейтив на базе ваших существующих .net компиляторов, то потом автоматически получим нативную версию всех инструментов (в первую очередь компилятора, ну и всего остального что у вас там есть)? VD>Упрощенно говоря — да. Компилятор языка это текст плюс ратнтайм, плюс используемый внешний АПИ. Если мы можем компилировать этот текст самим собой, то все что нужно для переноса языка на другую платформу — это скомпилировать себя собой с бэкэндом для этой платформе.
Отлично.
VD>Естественно при этом есть нюансы. VD>1. АПИ — компилятор использует ряд вызовов рантайма. Их надо воспроизвести в целевом рантайме. Собственно мы используем минимум: VD>* Работа со строками в формате UTF-16 (классы string и StringBuilder). VD>* Коллекции (List<T>, HashSet<T>, Dictionary<R, V>, ImmutableArray и т.п.) все это есть в исходниках в библиотеках на гитхабе. Да и написать с нуля не долго.
Вот такие вещи вообще говоря должны реализовываться не рантаймом, а входить в стандартную библиотеку языка (и быть написанными на вашем языке). А от рантайма должны требоваться грубо говоря только функции выделения и освобождения (если без GC) памяти.
VD>* Чтение и запись файлов. VD>* Динамическая загрузка библиотек, создание экземпляра объекта и вызов его метода (это нужно для динамической расширяемости).
VD>Если брать не только компилятор, но и движок IDE, то нужны еще: VD>* Именованные каналы для общения с сервером движка IDE. VD>* АПИ по работе с потоками и процессами для организации параллельных вычислений.
Ну а это всё по сути прямые обёртки над функциями ОС и пишется элементарно.
Кстати, раз вы таких специалисты по парсингу и т.п., то при переходе нативный код я бы на вашем месте первым делом решил такую простую задачу: автоматическую конвертацию заголовочных файлов из WindowsSDK (или Linux — разницы нет) в декларацию чужих импортируемых функций на вашем языке. Если будет такой простейший конвертер (кстати, помнится для каких-то языков я такое уже видел), то это решит огромное число проблем и сходу (даже без создания своей библиотеки языка) позволит писать полноценные приложения (в том числе и с GUI и всем остальным).
VD>Конечно же код работы непосредственно с IDE просто перекомпилировать не удастся. У все IDE свои АПИ. Для них надо писать фронтэнд вручную. Движек же IDE у нас работает в отдельном процессе и взаимодействует с фронтэндом через именованные каналы. Так что сервер может работать на платформе отличной от той на которой работает IDE. Фронтэнд у нас очень тонкий. Логики там нет. Он просто должен реализовывать АПИ IDE и преобразоывать их в посылку и прием сообщений IDE-серверу живущему в отдельном процессе.
Тут наверное просто стоит определиться, для какой из известных кроссплатформенных IDE вы в первую очередь захотели бы написать плагин. Собственно их вообще таких не много. Но для начал достаточно одной, чтобы хотя бы демонстрация технологии была.
_>>2. Насколько язык заточен на CLR? VD>В Нитре и этом сабсэте Немерла используются: VD>1. Автоматическое управление памятью. Для компилятора можно просто выделять память из одного непрерывного блока и тупо забить на его освобождение (делать его для всего пула в конце компиляции). Будет перерасход процентов в 10-20, но учитывая объемы современной памяти — это не критично. На первое время сойдет. Ну, или реализовать самый примитивный вариант GC и вызывать сборку мусора вручную в известных точках. Для движка IDE такой способ будет неприемлем, но для компилятора — прокатит. Далее, конечно, надо реализовать точный GC на основе поколений или один из новомодных алгоритмов. Еще один вариант — реализовать автоматическое управление памятью на базе подсчета ссылок. По сути это ограниченный ЖЦ.
Печально это конечно. Подсчёт ссылок — это ужасно (в смысле как универсальное решение для всей памяти). GC лучше, но тоже не очень (при этом его реализация очень не тривиальна).
VD>2. Динамическая загрузка кода. Грамматики, код типизации и бэкнд помещаются в библиотеки. Во время исполнения они подгружаются как в компилятор, так и в движок IDE. Там они компонуются с другими такими же сущностными и получается конечный парсер, типизатор и бэкэнд. Эту часть можно абстрагировать в виде АПИ и реализовать для каждой из платформ на базе их родного АПИ. Подгружаемые типы являются монотипными (т.е. не обобщенными).
Да, это очевидно всё.
VD>3. ООП дотнетного типа: VD>* Классы с одним предком. VD>* Интерфейсы с множественным наследованием. VD>* Виртуальные таблицы. VD>Тут нужна поддержка в рантайме. Таблицы интерфейсов и виртуальная таблица методов. Собственно как это все делается известно. Но это требует реализации.
Тут тоже всё тривиально (по сути никаких внутренних отличий от C++, так что можно взять готовую эффективную реализацию). Только вот есть один вопрос, который я уже упоминал, но не увидел на него ответа. Что у нас с разделением на типы ссылки и значения? В .net у нас экземпляры классов только ссылочные — это не эффективно. Должны быть и ссылочные механизмы и нормальные объекты-значения. И в памяти и на стеке.
VD>Дженерики, конечно же нами тоже используются, но в рамках обобщенных типов данных. Никаких динамических загрузок обобщенных типов не требуется, так что их можно реализовать путем генерации специализаций. VD>Нитра предоставляет сериализацию символов и АСТ-а. Так что дженерики можно будет записывать в библиотеки в виде АСТ-а и символов, а потом материализовывать их для конкретных типов (как шаблоны С++ только без исходников).
Позитивно.
VD>Рефлексия нами по сути не используется. Только для той самой подгрузки грамматик (что может быть абстрагированно). VD>Нитра из коробки предоставляет метаданные для всех внутренностей любого языка написанного на Нитре. Так что для языка не составит труда реализовать и рефлексию и прочий блэкджек с девочками. Причем сериализация и десериализация метаинформации производится с помощью генерации кода. Это с одной стороны быстро, а с другой не привязывает нас к АПИ вроде рефлексии.
Вообще отлично.
VD>Таким образом каждый сможет создать для себя свой набор необходимых ему фич. Если тебе не хочется использовать автоматическое управление памятью и ты согласен выписывать руками конструкторы с деструкторами, а так же следить за памятью вручную, то можешь просто сделать расширение с ручным управлением памятью.
Нуу тут опять же есть нюансы. Совсем ручное управление (как в C) мало кому интересно (хотя опять же должно быть доступно в языке, хотя бы в каком-то unsafe режиме). А при полуавтоматическом (умные указатели и т.п.) могут всплывать различные проблемы типа "восходящего фунарга" и т.п. В том же C++ эта проблем сейчас по сути решена благодаря введению в язык семантики перемещения. Но это уже по сути глобальная правка всего языка, а не просто изменение одной мелкой подсистемы (выделения памяти).
_>>3. Насколько язык заточен на библиотеку .Net. Именно язык, а не предоставление .net в качестве стандартной библиотеки языка для пользователя VD>Этого вообще не понял. Языку просто по фигу какая там у него библиотека. Вот библиотека от языка зависит. Если у нас язык с ЖЦ, то и в библиотеке должны быть ЖЦ-типы.
Речь о том, какие функции .net используются рантаймом (а не библиотекой) языка — их же придётся заменять на вызовы к ОС. Я уже приводил пример, что допустим рантайму C++ необходим доступ к функциям типа VirtualAlloc, VirtualFree и т.п. Плюс там обычно используются различные синхронизации (типа критических секций) и некоторые нюансы многопоточности (типа tls).
Вообще пока что судя по твоим словам всё относительно позитивно, хотя есть и серьёзные проблемы. Из того, что я прочитал, какую-то реализацию сложнее прямых обёрток вокруг системного АПИ требуют только:
1. Своя библиотека контейнеров (в принципе элементарно)
2. Какое-то управление памятью — а это слооожно (если хотим эффективно).
Остальное получается по идее портируемо в режиме Ctrl+C/Ctrl+V.
Здравствуйте, alex_public, Вы писали:
_>Вот такие вещи вообще говоря должны реализовываться не рантаймом, а входить в стандартную библиотеку языка (и быть написанными на вашем языке).
Дык оно так и есть. Просто библиотека и есть часть рантайма для компилятора.
_>А от рантайма должны требоваться грубо говоря только функции выделения и освобождения (если без GC) памяти.
А вот так не бывает. Библоитека она всегда рассчитана на язык. Там масса нюансов.
_>Ну а это всё по сути прямые обёртки над функциями ОС и пишется элементарно.
Все пишет элементарно. Вопрос лишь в том, что надо сесть и сделать. Вот рук которые это сделаю и не хватает. Плюс в данном случае это должны быть руки знакомые с целевой платформой и способные для нее написать эти обертки.
_>Кстати, раз вы таких специалисты по парсингу и т.п., то при переходе нативный код я бы на вашем месте первым делом решил такую простую задачу: автоматическую конвертацию заголовочных файлов из WindowsSDK (или Linux — разницы нет) в декларацию чужих импортируемых функций на вашем языке. Если будет такой простейший конвертер (кстати, помнится для каких-то языков я такое уже видел), то это решит огромное число проблем и сходу (даже без создания своей библиотеки языка) позволит писать полноценные приложения (в том числе и с GUI и всем остальным).
Мы конечно специалисты по парсингу и спарсить заголовочные файлы С не является особой проблемой, но опять же у нас не 100 рук. Плюс тут нужно не только парсить уметь, но и помнить все нюансы работы с этими АПИ. Если с АПИ Винды я еще знаком (хотя уже лет 15 с ними не возился), то с линукосовыми или iOS-ыми я не знаком совсем. Стало быть я плохой кандидат на эту задачу. А вот помочь с парсингом — это пожалуйста.
_>Тут наверное просто стоит определиться, для какой из известных кроссплатформенных IDE вы в первую очередь захотели бы написать плагин. Собственно их вообще таких не много. Но для начал достаточно одной, чтобы хотя бы демонстрация технологии была.
Тут опять таки лучше чтобы такой задачей занимались люди которые близки к этой платформе и этой IDE. Я шарю в MS VS. Для нее я реализацию написал. А вот написть тоже для Эклипса какого или IDEA мне будет проблематично. В то же время я могу элементарно объяснить что надо делать спецу в этих технологиях и он спокойно за месяцок-другой ненапряжной работы это сделает. Движок ведь уже отлажен.
_>Печально это конечно. Подсчёт ссылок — это ужасно (в смысле как универсальное решение для всей памяти). GC лучше, но тоже не очень (при этом его реализация очень не тривиальна).
Да нет ничего печально. Просто ты дико предвзят (причем не по делу) к GC. А для компилятора нет ничего впечатлительного и в тупейшем "нарезателе" памяти. Компилятор программа пакетная. Собрала данные, обработала, выплюнула исполнимый модуль. Основной объем памяти занимают АСТ и дерево разбора.
GC тоже не бином Ньютона. В LLVM есть вся поддержка GC. И есть готовые реализации GC. Состыковать все это вполне подъемная задача. За время компиляции ЖЦ дотнета почти не запускается.
Ну, а для своих нужды ты уже сам сможешь решить использовать тебе GC или вручную памятью управлять.
_>Тут тоже всё тривиально (по сути никаких внутренних отличий от C++, так что можно взять готовую эффективную реализацию).
Ты говоришь очевидные и банальные вещи. Я тебе заранее мог бы скзазать, что все что нужно сделать евляется известным и тривиальным. Вопрос только в том, что в совокупности это не кислый объем работ который а) надо сделать; б) требует знаний в целевой платформе.
Лично у меня просто нет ни времени, ни знаний в целевых платыформах отличных от Винды. А для винды и так есть дотнет.
Я, конечно, могу взять и сделать LLVM-версию бэкэнда для Винды. Но не ясно зачем она нужна, и не это отвлечет меня от развития Нитры и Немерла, так что в итоге все встроится в очередь и отдалит результат еще дальше.
_>Только вот есть один вопрос, который я уже упоминал, но не увидел на него ответа. Что у нас с разделением на типы ссылки и значения? В .net у нас экземпляры классов только ссылочные — это не эффективно. Должны быть и ссылочные механизмы и нормальные объекты-значения. И в памяти и на стеке.
У нас — конструктор. Мы вольны добавлять в него все что захотим. Главное, чтобы в рантайме поддержка была. Для самого немерла используется дотнетное разделение на вэлью-типы и ссылочные. Ссылочные живут в хипе, вэлью на стеке и в внутри других объектов. При грамотном проектировании ник каким проблемам с производительностью это не влечет. Но если кому-то хочется это оптимизировать, то флаг ему в руки. Их можно оформить как расширение к компилятору и использовать в своих проектах или ключить в стандартную библиотеку (расширения компилятора — тоже библиотечные вещи).
_>Нуу тут опять же есть нюансы. Совсем ручное управление (как в C) мало кому интересно (хотя опять же должно быть доступно в языке, хотя бы в каком-то unsafe режиме).
Согласен.
_>А при полуавтоматическом (умные указатели и т.п.) могут всплывать различные проблемы типа "восходящего фунарга" и т.п.
Я как то с фунаргами не знаком (глянул википедию). Если речь о релизация ФВП (функций высшего порядка), то очевидно, что тут нужно делить их на два типа:
1. С копирующими замыканиями (значениями лежащими в стеке).
2. Позволять захватывать ссылки только на объекты управляемые ЖЦ или рефкаунтингом.
_>В том же C++ эта проблем сейчас по сути решена благодаря введению в язык семантики перемещения.
Тоже полезная концепция. И не только для замыканий. Я сам думал об уникальных указателях.
_>Но это уже по сути глобальная правка всего языка, а не просто изменение одной мелкой подсистемы (выделения памяти).
_>Речь о том, какие функции .net используются рантаймом (а не библиотекой) языка — их же придётся заменять на вызовы к ОС.
Рантайм на котором будет выполняется скомпилированная программа? Да нам как-то по фигу это. Хоть она просто будет в памяти биты гонять.
Собственно рантайм для языка вроде немерла должен предоставлять только GC и динамическую загрузку модулей (сборок, длл-ей, со-шников) и создание типов из них с приведением к заранее известным интерфейсам.
Другое дело, что должна быть еще хоть какая-то стандартная библиотека: коллекции, строки, работа с файлами, сокетами, пайпами... Вот тут лучше брать интерфейс донтентых либ и реализовывать их на базе имеющихся АПИ. Или делать библиотеки доступные для всех платформ (те же коллекции и строки можно тупо написать на сомом языке, так как доступ к ОС им не нужен).
_>Я уже приводил пример, что допустим рантайму C++ необходим доступ к функциям типа VirtualAlloc, VirtualFree и т.п. Плюс там обычно используются различные синхронизации (типа критических секций) и некоторые нюансы многопоточности (типа tls).
Какие тут проблемы то? Это какие-то несусветные мелочи. GC будет несколько более сложным в реализации. А без него удобный язык трудно сделать. Блокировки опять таки это библиотечная сущность. Ну, надо будет реализовать аналоги функции Monitor.Enter/
_>Вообще пока что судя по твоим словам всё относительно позитивно, хотя есть и серьёзные проблемы. Из того, что я прочитал, какую-то реализацию сложнее прямых обёрток вокруг системного АПИ требуют только:
_>1. Своя библиотека контейнеров (в принципе элементарно)
Это вообще не проблема. Код оных уже есть. Остается только его скомпилировать.
_>2. Какое-то управление памятью — а это слооожно (если хотим эффективно).
Это — да.
С дженериками тоже придется повозиться. Но там тоже ясно что делать.
_>Остальное получается по идее портируемо в режиме Ctrl+C/Ctrl+V.
Это только на словах. По жизни там не не хилый объем работы. Ну, и естественно, будут разные "подводные камни всплывать" по мере погружения. Но задача вполне себе реализуемая.
Собственно действовать надо путем последовательных приближений. Сначала реализовать примитивныую реализацию на уровне С (без плюсов и классов). Потом добавить к ней классы. Отладить на этой базе ЖЦ или ее замену. Далее добавить поддержку дженериков. В конце получим полноценное решение.
Это позволит тестировать результат с самых ранних стадий.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_>>Ну а это всё по сути прямые обёртки над функциями ОС и пишется элементарно. VD>Все пишет элементарно. Вопрос лишь в том, что надо сесть и сделать. Вот рук которые это сделаю и не хватает. Плюс в данном случае это должны быть руки знакомые с целевой платформой и способные для нее написать эти обертки.
Ну вообще говоря обёртки над функциями ОС генерируются автоматически инструментами. Но при этом они естественно не могут служить удобной стандартной библиотекой языка (она должна быть как минимум кроссплатформенной). Так что потом естественно надо продумать какие-то удобные родные интерфейсы для базовых вещей (хотя бы в рамках стандартной библиотеки C++) и сделать их реализацию на каждой платформе (опять же через вызовы тех самых сгенерированных деклараций нативного АПИ). Но изначально, чтобы оно хоть как-то заработало можно обойтись и прямо функциями ОС.
_>>Кстати, раз вы таких специалисты по парсингу и т.п., то при переходе нативный код я бы на вашем месте первым делом решил такую простую задачу: автоматическую конвертацию заголовочных файлов из WindowsSDK (или Linux — разницы нет) в декларацию чужих импортируемых функций на вашем языке. Если будет такой простейший конвертер (кстати, помнится для каких-то языков я такое уже видел), то это решит огромное число проблем и сходу (даже без создания своей библиотеки языка) позволит писать полноценные приложения (в том числе и с GUI и всем остальным). VD>Мы конечно специалисты по парсингу и спарсить заголовочные файлы С не является особой проблемой, но опять же у нас не 100 рук. Плюс тут нужно не только парсить уметь, но и помнить все нюансы работы с этими АПИ. Если с АПИ Винды я еще знаком (хотя уже лет 15 с ними не возился), то с линукосовыми или iOS-ыми я не знаком совсем. Стало быть я плохой кандидат на эту задачу. А вот помочь с парсингом — это пожалуйста.
Кстати, как-то забыл упомянуть в предыдущем сообщение очевидную вещь — вам же надо продумать нормальную декларацию для внешних функций (типы, соглашение о вызове и т.п.). У вас же теперь будет прямой вызов таких функций, а не всякий там маршалинг .net'а.Это один из самых важных моментов в современных нативных языках. Потому что если в вашем коде будут легко доступны функции из подключаемых C библиотек и системного АПИ, то это мгновенно даст ему библиотеку (пуская и не родную в начале) на порядок мощнее любого .net'a.
_>>Тут наверное просто стоит определиться, для какой из известных кроссплатформенных IDE вы в первую очередь захотели бы написать плагин. Собственно их вообще таких не много. Но для начал достаточно одной, чтобы хотя бы демонстрация технологии была. VD>Тут опять таки лучше чтобы такой задачей занимались люди которые близки к этой платформе и этой IDE. Я шарю в MS VS. Для нее я реализацию написал. А вот написть тоже для Эклипса какого или IDEA мне будет проблематично. В то же время я могу элементарно объяснить что надо делать спецу в этих технологиях и он спокойно за месяцок-другой ненапряжной работы это сделает. Движок ведь уже отлажен.
Ну лично я про это ничего не могу сказать, т.к. не знаком с внутренностями ни одной IDE (я только их активный пользователь). Я просто говорю о том, что для того чтобы заинтересовать людей с других платформ вам желательно в начале самим сделать хоть один плагин для одной из топовых кроссплатформенных IDE. У вас же значительная часть киллер-фич находится не в самом языке или компиляторе, а именно в интеграции с IDE.
_>>Печально это конечно. Подсчёт ссылок — это ужасно (в смысле как универсальное решение для всей памяти). GC лучше, но тоже не очень (при этом его реализация очень не тривиальна). VD>Да нет ничего печально. Просто ты дико предвзят (причем не по делу) к GC. А для компилятора нет ничего впечатлительного и в тупейшем "нарезателе" памяти. Компилятор программа пакетная. Собрала данные, обработала, выплюнула исполнимый модуль. Основной объем памяти занимают АСТ и дерево разбора. VD>GC тоже не бином Ньютона. В LLVM есть вся поддержка GC. И есть готовые реализации GC. Состыковать все это вполне подъемная задача. За время компиляции ЖЦ дотнета почти не запускается.
Так я говорил не про компилятор, а про райнтайм для пользовательских программ. Именно это ключевое. А для компилятора действительно можно сделать что угодно, например банальный пул.
VD>Ну, а для своих нужды ты уже сам сможешь решить использовать тебе GC или вручную памятью управлять.
Вот это я что-то не очень понял. Так автоматическое управление памятью всё же опционально или нет? Речь про рантайм языка, который будет присутствовать в любой пользовательской программе.
_>>Тут тоже всё тривиально (по сути никаких внутренних отличий от C++, так что можно взять готовую эффективную реализацию). VD>Ты говоришь очевидные и банальные вещи. Я тебе заранее мог бы скзазать, что все что нужно сделать евляется известным и тривиальным. Вопрос только в том, что в совокупности это не кислый объем работ который а) надо сделать; б) требует знаний в целевой платформе. VD>Лично у меня просто нет ни времени, ни знаний в целевых платыформах отличных от Винды. А для винды и так есть дотнет.
Просто есть разные режимы работы. Может быть даже большой объём, но с гарантированным (успешным) результатом и отсутствием каких-либо вопросов по нюансам реализации. А может быть режим "ну давайте начнём и будем надеяться что всё получится". ))) Вот я и пытаюсь выяснить заранее, к какому режиму относится портирование ваших технологий из .net'a. Пока получается что основной объём работы относится к первому варианту, но не всё (по паре вопросов есть и второй вариант).
VD>Я, конечно, могу взять и сделать LLVM-версию бэкэнда для Винды. Но не ясно зачем она нужна, и не это отвлечет меня от развития Нитры и Немерла, так что в итоге все встроится в очередь и отдалит результат еще дальше.
Ну вот тут ты не совсем прав. Если допустим будет существовать нативная версия ваших инструментов под винду и её исходные коды будут доступны, то энтузиасты из других платформ смогут элементарно (!) портировать их к себе, даже "не включая мозг". В отличие от нынешней ситуации, когда для создания нативной версии требуется очень глубокое погружение во все нюансы языка.
_>>Только вот есть один вопрос, который я уже упоминал, но не увидел на него ответа. Что у нас с разделением на типы ссылки и значения? В .net у нас экземпляры классов только ссылочные — это не эффективно. Должны быть и ссылочные механизмы и нормальные объекты-значения. И в памяти и на стеке. VD>У нас — конструктор. Мы вольны добавлять в него все что захотим. Главное, чтобы в рантайме поддержка была. Для самого немерла используется дотнетное разделение на вэлью-типы и ссылочные. Ссылочные живут в хипе, вэлью на стеке и в внутри других объектов. При грамотном проектировании ник каким проблемам с производительностью это не влечет. Но если кому-то хочется это оптимизировать, то флаг ему в руки. Их можно оформить как расширение к компилятору и использовать в своих проектах или ключить в стандартную библиотеку (расширения компилятора — тоже библиотечные вещи).
На самом деле больше всего требуется достаточно простая вещь: тип-значение (как более эффективный) с возможностью нормальных классов (наследование и т.п.). Но лучше конечно это решать в рамках общего универсального подхода: ссылка или значение не должно зависеть от типа (класс или структура), а должно навешиваться поверх.
_>>А при полуавтоматическом (умные указатели и т.п.) могут всплывать различные проблемы типа "восходящего фунарга" и т.п. VD>Я как то с фунаргами не знаком (глянул википедию). Если речь о релизация ФВП (функций высшего порядка), то очевидно, что тут нужно делить их на два типа: VD>1. С копирующими замыканиями (значениями лежащими в стеке).
Не эффективно)
VD>2. Позволять захватывать ссылки только на объекты управляемые ЖЦ или рефкаунтингом.
Ну понятно что при GC этой проблемы вообще нет. ))) Это актуально именно для неуправляемых языков.
_>>В том же C++ эта проблем сейчас по сути решена благодаря введению в язык семантики перемещения. VD>Тоже полезная концепция. И не только для замыканий. Я сам думал об уникальных указателях.
Да, конечно же она придумывался для оптимизации многих нюансов (например засовывание тяжёлых объектов в контейнер), а не только этого. Просто по ходу дела ещё и гарантированно (раньше это решалось иногда, если срабатывала оптимизация RVO, что как бы существенно отличается от механизма языка) решила эту известную проблему.
_>>Но это уже по сути глобальная правка всего языка, а не просто изменение одной мелкой подсистемы (выделения памяти). _>>Речь о том, какие функции .net используются рантаймом (а не библиотекой) языка — их же придётся заменять на вызовы к ОС. VD>Рантайм на котором будет выполняется скомпилированная программа? Да нам как-то по фигу это. Хоть она просто будет в памяти биты гонять.
В смысле пофиг? Этот рантайм же должны предоставлять создатели языка (сейчас за вас это делает CLR).
VD>Собственно рантайм для языка вроде немерла должен предоставлять только GC и динамическую загрузку модулей (сборок, длл-ей, со-шников) и создание типов из них с приведением к заранее известным интерфейсам.
Т.е. никаких синхронизаций и т.п.?
VD>Другое дело, что должна быть еще хоть какая-то стандартная библиотека: коллекции, строки, работа с файлами, сокетами, пайпами... Вот тут лучше брать интерфейс донтентых либ и реализовывать их на базе имеющихся АПИ.
Нуу это конечно тоже вариант, но скорее для далёкого будущего. А для начала логичнее просто научиться удобно подключать C библиотеки и автоматом получить набор функций на голову превосходящий весь .net вместе взятый. Только при этом с неудобными типам, и разбродом в стиле API и документации.
VD>Или делать библиотеки доступные для всех платформ (те же коллекции и строки можно тупо написать на сомом языке, так как доступ к ОС им не нужен).
Да, про контейнеры я уже говорил, что их всё же лучше написать на самом языке.
_>>Остальное получается по идее портируемо в режиме Ctrl+C/Ctrl+V. VD>Это только на словах. По жизни там не не хилый объем работы. Ну, и естественно, будут разные "подводные камни всплывать" по мере погружения. Но задача вполне себе реализуемая.
Объём безусловно есть в любом случае. Но как я уже писал выше, тип работы может быть существенно разным.
VD>Собственно действовать надо путем последовательных приближений. Сначала реализовать примитивныую реализацию на уровне С (без плюсов и классов). Потом добавить к ней классы. Отладить на этой базе ЖЦ или ее замену. Далее добавить поддержку дженериков. В конце получим полноценное решение. VD>Это позволит тестировать результат с самых ранних стадий.
На мой взгляд план может быть таким:
1. подключение llvm (есть готовая инструкция) с каким-нибудь убогим готовым GC
2. разработка удобного подключения C библиотек и ОС АПИ, плюс написание автоматического трансформера заголовочных файлов
3. тут уже можно сделать первое hello world
4. попробовать решить проблему эффективного GC (а лучше ухода от GC)
5. своя библиотека контейнеров и алгоритмов
6. медленная пошаговая замена использования C библиотек на родные библиотеки
Здравствуйте, alex_public, Вы писали:
_>Вот это я что-то не очень понял. Так автоматическое управление памятью всё же опционально или нет? Речь про рантайм языка, который будет присутствовать в любой пользовательской программе.
Ты путаешь две вещи.
1)Компилятор и движок ИДЕ языка программирования который генерирует нитра.
Им для работы нужен ГЦ или заменитель.
2)Код который генерирует компилятор, написанный на нитре.
Тут может быть что угодно.
Этот код не зависит ни от нитры ни от компилятора языка.
Хочешь можешь использовать ГЦ. Не хочешь можешь не использовать ГЦ.
Тут у разработчика языка полный контроль.
А есть ли ГЦ в компиляторе никого волновать не должно от слова совсем.
Я не вижу ни одной причины по которой это могло бы иметь значение.
_>но не всё (по паре вопросов есть и второй вариант).
В случае с портированием только первый.
VD>>Рантайм на котором будет выполняется скомпилированная программа? Да нам как-то по фигу это. Хоть она просто будет в памяти биты гонять. _>В смысле пофиг? Этот рантайм же должны предоставлять создатели языка (сейчас за вас это делает CLR).
Вот так. Нитре совсем пофиг для какого рантайма генерировать код.
У нас есть некоторые требования для рантайма на котором может работать компилятор, сгенерированный нитрой.
Но нет никаких ограничений на рантайм языков которые компилируют компиляторы, написанные на нитре.
_>На мой взгляд план может быть таким:
Нет. Делать нужно так как Влад сказал.
Мы начинаем с примитивного рантайма который полезен сам по себе.
Ибо позволит на нитре создавать языки, работающие без ГЦ. Что-то типа С на стероидах.
Для того чтобы научить нитру генерировать нативные компиляторы, написанные на нитре (и компилятор самой нитры, ибо он написан на нитре) этого недостаточно.
Дальше можно добавлять возможности, которые можно либо использовать, либо нет.
Те, когда мы добавим поддержку нативного рантайма с ГЦ. С на стероидах просто не будет её использовать.
Но этого будет достаточно чтобы нитра смогла генерировать нативные компиляторы.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
_>>Вот это я что-то не очень понял. Так автоматическое управление памятью всё же опционально или нет? Речь про рантайм языка, который будет присутствовать в любой пользовательской программе. WH>Ты путаешь две вещи. WH>1)Компилятор и движок ИДЕ языка программирования который генерирует нитра. WH>Им для работы нужен ГЦ или заменитель.
ОК. Для компилятора тут обычный пул наверное подошёл был. Для плагина в IDE не знаю, наверное лучше нормальный GC.
Оффтопик. Просто экспериментальный факт: все испробованные мной IDE написанные на Java (т.е. GC) ощутимо (хотя работать всё равно без проблем можно) подтормаживают в сравнение нативными с такими же возможностями. Мой список сравнения, если что: Eclipse, Netbeans, CLion, VisualStudio, QtCreator.
WH>2)Код который генерирует компилятор, написанный на нитре. WH>Тут может быть что угодно. WH>Этот код не зависит ни от нитры ни от компилятора языка. WH>Хочешь можешь использовать ГЦ. Не хочешь можешь не использовать ГЦ. WH>Тут у разработчика языка полный контроль.
Это конечно выглядит отлично. Но если вы будете предоставлять подобную технологию "голой", то вряд ли у неё найдётся много пользователей. Потому что разрабатывать свой рантайм (вместо решения прикладных задач) — это сомнительное удовольствие. Вот если у вас в коробке будет идти нормальный эффективный (и возможно кастомизируемый (отключение/подключение GC и т.п.) или просто несколько штук под базовые варианты) рантайм, то таким инструментом уже можно эффективно пользоваться. И кстати в вашем нынешнем решение именно так всё и устроено, только рантайм один и не кастормизируемый (CLR). А вот в случае создания нативной версии это всё надо сделать, что и является одной из важнейших задач на мой взгляд.
WH>А есть ли ГЦ в компиляторе никого волновать не должно от слова совсем. WH>Я не вижу ни одной причины по которой это могло бы иметь значение.
Согласен.
_>>На мой взгляд план может быть таким: WH>Нет. Делать нужно так как Влад сказал. WH>Мы начинаем с примитивного рантайма который полезен сам по себе. WH>Ибо позволит на нитре создавать языки, работающие без ГЦ. Что-то типа С на стероидах.
Ну лично я то как бы только "за" языки без GC. Только вот хотелось бы увидеть не "C без GC", a "Nemerle без GC"...
И главное. На этом этапе ещё не получится написать даже "Hello world", потому как функции типа writeln очевидно не входят в рантайм, а относятся к подключаемой библиотеке ввода-вывода. И вот тут начинаются как раз основные игры с разработкой нормального подключения внешних библиотек и т.п. Т.е. один из основных моментов у тебя в плане вообще не озвучен.
WH>Для того чтобы научить нитру генерировать нативные компиляторы, написанные на нитре (и компилятор самой нитры, ибо он написан на нитре) этого недостаточно. WH>Дальше можно добавлять возможности, которые можно либо использовать, либо нет. WH>Те, когда мы добавим поддержку нативного рантайма с ГЦ. С на стероидах просто не будет её использовать. WH>Но этого будет достаточно чтобы нитра смогла генерировать нативные компиляторы.
Это всё понятно.
Кстати, хотя полезность нативных компиляторов для продукта очевидна (иначе сложно привлечь людей с других платформ), но в процессе разработки нативной версии я бы абсолютно спокойно пользовался .net компилятором. Т.е. природа самого компилятора думаю никого не волнует и если бы вы скажем сумели бы портировать (например с помощью .net core) прямо свой текущий компилятор на Linux и OSX, то думаю никто бы и не подумал требовать его нативную версию. Естественно подразумевая, что он при этом может генерировать нативный код для этих платформ.
Здравствуйте, alex_public, Вы писали:
_>ОК. Для компилятора тут обычный пул наверное подошёл был. Для плагина в IDE не знаю, наверное лучше нормальный GC.
Работы много, а преимущества мягко говоря не очевидны.
Возможно в очень отдалённом будущем оно и будет сделано, но эта задача совершенно точно находится в самом хвосте. И выпиливание ГЦ будет далеко не главной оптимизацией.
_>Оффтопик. Просто экспериментальный факт: все испробованные мной IDE написанные на Java (т.е. GC) ощутимо (хотя работать всё равно без проблем можно) подтормаживают в сравнение нативными с такими же возможностями. Мой список сравнения, если что: Eclipse, Netbeans, CLion, VisualStudio, QtCreator.
Если там что-то и тормозит, то точно не ГЦ.
_>Это конечно выглядит отлично. Но если вы будете предоставлять подобную технологию "голой", то вряд ли у неё найдётся много пользователей. Потому что разрабатывать свой рантайм (вместо решения прикладных задач) — это сомнительное удовольствие. Вот если у вас в коробке будет идти нормальный эффективный (и возможно кастомизируемый (отключение/подключение GC и т.п.) или просто несколько штук под базовые варианты) рантайм, то таким инструментом уже можно эффективно пользоваться. И кстати в вашем нынешнем решение именно так всё и устроено, только рантайм один и не кастормизируемый (CLR). А вот в случае создания нативной версии это всё надо сделать, что и является одной из важнейших задач на мой взгляд.
Естественно всё так и устроено.
Просто по тому что так было запланировано изначально.
Причём не только рантайм, но и промежуточные языки чтобы пользователи не возились с языками низкого уровня.
Но! Это всё большой объём работы, который должен кто-то сделать.
_>Ну лично я то как бы только "за" языки без GC. Только вот хотелось бы увидеть не "C без GC", a "Nemerle без GC"...
1)Многие конструкции немерле сильно завязаны на ГЦ. Чтобы сделать его без ГЦ нужно менять дизайн. А это будет уже другой язык.
2)Нитра изначально создавалась для создания модульных языков. В смысле модульного синтаксиса и семантики. Так что имея базовый "С без маразмов" можно будет очень легко нарастить на него очень много полезных плюшек.
_>И главное. На этом этапе ещё не получится написать даже "Hello world", потому как функции типа writeln очевидно не входят в рантайм, а относятся к подключаемой библиотеке ввода-вывода. И вот тут начинаются как раз основные игры с разработкой нормального подключения внешних библиотек и т.п. Т.е. один из основных моментов у тебя в плане вообще не озвучен.
По тому что это мелкая деталь реализации.
_>Кстати, хотя полезность нативных компиляторов для продукта очевидна (иначе сложно привлечь людей с других платформ),
Совершенно не очевидна. На многих платформах .НЕТ в нужном объёме присутствует.
А если что на Яву можно будет очень просто портировать. А она вообще почти везде есть.
_>но в процессе разработки нативной версии я бы абсолютно спокойно пользовался .net компилятором. Т.е. природа самого компилятора думаю никого не волнует и если бы вы скажем сумели бы портировать (например с помощью .net core) прямо свой текущий компилятор на Linux и OSX, то думаю никто бы и не подумал требовать его нативную версию.
Да там протировать нечего. Всё давно протировано.
Немерле под линухом давно работает.
_>Естественно подразумевая, что он при этом может генерировать нативный код для этих платформ.
Как только нитра сможет генерировать нативный код она естественно будет это делать везде.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
_>>Оффтопик. Просто экспериментальный факт: все испробованные мной IDE написанные на Java (т.е. GC) ощутимо (хотя работать всё равно без проблем можно) подтормаживают в сравнение нативными с такими же возможностями. Мой список сравнения, если что: Eclipse, Netbeans, CLion, VisualStudio, QtCreator. WH>Если там что-то и тормозит, то точно не ГЦ.
Я как бы не претендую на знание того, что там тормозит. ) Но подобное совпадение настораживает. )))
WH>Естественно всё так и устроено. WH>Просто по тому что так было запланировано изначально. WH>Причём не только рантайм, но и промежуточные языки чтобы пользователи не возились с языками низкого уровня. WH>Но! Это всё большой объём работы, который должен кто-то сделать.
Хотелось бы для начала получить хоть что-то работающее. Мне бы хватило для начала нативного "hello world" (собранного не важно каким компилятором (но с бэкендом llvm, для приличной оптимизации), пускай даже под одну винду), написанного на языке с возможностями Nemerle. Дальше уже понятно что и куда развивать.
_>>И главное. На этом этапе ещё не получится написать даже "Hello world", потому как функции типа writeln очевидно не входят в рантайм, а относятся к подключаемой библиотеке ввода-вывода. И вот тут начинаются как раз основные игры с разработкой нормального подключения внешних библиотек и т.п. Т.е. один из основных моментов у тебя в плане вообще не озвучен. WH>По тому что это мелкая деталь реализации.
Но требующая при этом весьма серьёзного времени. Собственно если делать упрощённый Си подобный язык, то это будет самая большая часть работы.
_>>но в процессе разработки нативной версии я бы абсолютно спокойно пользовался .net компилятором. Т.е. природа самого компилятора думаю никого не волнует и если бы вы скажем сумели бы портировать (например с помощью .net core) прямо свой текущий компилятор на Linux и OSX, то думаю никто бы и не подумал требовать его нативную версию. WH>Да там протировать нечего. Всё давно протировано. WH>Немерле под линухом давно работает.
Ну тем лучше, значит и думать надо именно о рантайме для пользовательских программ, а не про портирование компилятора. Как я собственно и говорил.
_>>Естественно подразумевая, что он при этом может генерировать нативный код для этих платформ. WH>Как только нитра сможет генерировать нативный код она естественно будет это делать везде.
Ну как бы если создание нативных приложение будет доработано до конца и ваши инструменты бутстрапятся, то совершенно логично сделать нативные инструменты (они даже по скорости скорее всего лучше будут, не говоря уже о таскание зависимостей и т.п.). Но это естественно совершенно не первоочередной вопрос — сейчас можно спокойно работать и на .net'их версиях.
Здравствуйте, alex_public, Вы писали:
_>Хотелось бы для начала получить хоть что-то работающее. Мне бы хватило для начала нативного "hello world" (собранного не важно каким компилятором (но с бэкендом llvm, для приличной оптимизации), пускай даже под одну винду), написанного на языке с возможностями Nemerle. Дальше уже понятно что и куда развивать.
Язык очень простенький и с ним можено легко разобраться не имея опыта ни в Нитре, ни в компиляторостроении.
Так вот можно для начала попробовать реализовать LLVM-бэкэнд для этого языка. За одно это будет знакомство с Немерле.
Nitra-Mini-C написал парень не знакомый с Немерлом до этого. Я консультировал его и немного помогал. На все про все у него ушло около месяца ненапряжной работы. Написать бэкэнд займет (думаю) от одного дня до недели.
Не хочешь попробовать? Я буду консультировать по Нитре и Немерлу. Ну, и помогу, чем смогу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_>>Хотелось бы для начала получить хоть что-то работающее. Мне бы хватило для начала нативного "hello world" (собранного не важно каким компилятором (но с бэкендом llvm, для приличной оптимизации), пускай даже под одну винду), написанного на языке с возможностями Nemerle. Дальше уже понятно что и куда развивать. VD>На сегодня есть вот такой игрушечный язык: Nitra-Mini-C VD>И статья
описывающая нюансы его реализации на Нитре. VD>Язык очень простенький и с ним можено легко разобраться не имея опыта ни в Нитре, ни в компиляторостроении. VD>Так вот можно для начала попробовать реализовать LLVM-бэкэнд для этого языка. За одно это будет знакомство с Немерле. VD>Nitra-Mini-C написал парень не знакомый с Немерлом до этого. Я консультировал его и немного помогал. На все про все у него ушло около месяца ненапряжной работы. Написать бэкэнд займет (думаю) от одного дня до недели.
Ну это в итоге получится немного не то, что я говорил. Это будет не нужный кому-то инструмент, а разве что первый тестовый шаг для построения чего-то приличного. Причём дальнейшее развитие будет для меня (как не проектировавшего пока ещё свои языки) не очевидно. В отличие от ситуации наличия уже нормального языка, который надо только перевести на нативные рельсы.
Но если в качестве развлечения и самообучения, то можно и попробовать такое.
VD>Не хочешь попробовать? Я буду консультировать по Нитре и Немерлу. Ну, и помогу, чем смогу.
Я? Ну технически я такое могу. И даже определённый интерес (правда пока только фанового типа) имеется. Но прямо сейчас я точно не могу. У меня тут сейчас как раз пик важного проекта, так что свободного времени нет вообще (причём большая часть проблем уже не технического уровня, а всякие контракты, поставки и т.п.). Так что я вот общаясь на форуме по сути немного отдыхаю от всего этого, но на большее времени нет. Можно будет попробовать поговорить об этом где-нибудь ближе к маю, когда надеюсь проект запустится. )))
Здравствуйте, alex_public, Вы писали:
_>Ну это в итоге получится немного не то, что я говорил. Это будет не нужный кому-то инструмент, а разве что первый тестовый шаг для построения чего-то приличного. Причём дальнейшее развитие будет для меня (как не проектировавшего пока ещё свои языки) не очевидно. В отличие от ситуации наличия уже нормального языка, который надо только перевести на нативные рельсы.
Речь идет лишь о том, чтобы попробовать, т.е. обучение, оценка на реальном примере, оценка LLVM, pet project.
_>Но если в качестве развлечения и самообучения, то можно и попробовать такое.
Именно. Это не займет много времени, но ты сможешь сам все оценить изнутри.
Ну, а потом, с полученным опытом можно будет взяться за полноценный язык. При этом наработки можно будет использовать почти без изменений.
Я сейчас занят на Нитре. А за это время, я надеюсь, что я с не закончу и вплотную займусь языками.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_>>Ну это в итоге получится немного не то, что я говорил. Это будет не нужный кому-то инструмент, а разве что первый тестовый шаг для построения чего-то приличного. Причём дальнейшее развитие будет для меня (как не проектировавшего пока ещё свои языки) не очевидно. В отличие от ситуации наличия уже нормального языка, который надо только перевести на нативные рельсы. VD>Речь идет лишь о том, чтобы попробовать, т.е. обучение, оценка на реальном примере, оценка LLVM, pet project.
Ну я то предпочёл бы получить готовый инструмент и ещё желательно на халяву. А тут такая суровая реальность... Эх, как тяжела жизнь.
_>>Но если в качестве развлечения и самообучения, то можно и попробовать такое. VD>Именно. Это не займет много времени, но ты сможешь сам все оценить изнутри.
ОК, тогда наверное что-то подобное попробую.
VD>Ну, а потом, с полученным опытом можно будет взяться за полноценный язык. При этом наработки можно будет использовать почти без изменений.
Слишком опасно. ) Особенно для меня (перепробовавшего множество языков, но так и не нашедшего идеала)... ))) Есть большой соблазн сделать "ещё один никому кроме тебя не нужный язык". ))) Безопаснее портировать на нужную тебе платформу какой-то приличный язык у которого уже есть сообщество и т.п.
Хотя если есть очень много свободного времени и желание поразвлечься, то... Но боюсь это не про меня. )
VD>Я сейчас занят на Нитре. А за это время, я надеюсь, что я с не закончу и вплотную займусь языками.
Тогда ближе к лету можем вернутся к этой дискуссии. )
P.S. Я на форуме общаюсь больше через почту (в смысле реагирую на пришедшие туда уведомления об ответах в темах).
Здравствуйте, alex_public, Вы писали:
_>Ну я то предпочёл бы получить готовый инструмент и ещё желательно на халяву. А тут такая суровая реальность... Эх, как тяжела жизнь.
Да. Реальная жизнь она такая.
_>ОК, тогда наверное что-то подобное попробую.
Тогда я я ниже опишу что нужно делать, и что нужно почитать для начала.
VD>>Ну, а потом, с полученным опытом можно будет взяться за полноценный язык. При этом наработки можно будет использовать почти без изменений.
_>Слишком опасно. ) Особенно для меня (перепробовавшего множество языков, но так и не нашедшего идеала)... ))) Есть большой соблазн сделать "ещё один никому кроме тебя не нужный язык". ))) Безопаснее портировать на нужную тебе платформу какой-то приличный язык у которого уже есть сообщество и т.п.
_>Хотя если есть очень много свободного времени и желание поразвлечься, то... Но боюсь это не про меня. )
Я, видимо, выразился недостаточно понятно. Я не имел в виду, что тебе придется создавать новый язык с нуля. Прод реальным языком я имел ввиду Native Nemerle 2.
Просто он пока еще не существует. По сем сейчас его переносом заниматься невозможно. Но в ближайшее время мы им займемся и можно будет параллельно с нами создавать нативный бэкэнд. Причем бэнэнд будет позволять завести на LLVM и другие дотнетные языки реализованные на Nitra. Например, Cx# (расширяемый C#), который на половину уже написан.
Но так как Nemerle — это конструктор, ты все же сможешь (позже) добавить в язык необходимы именно тебе фичи или отключить не нужные. Так что идея создать свой если не язык, то диалект, становится куда реалистичнее.
_>Тогда ближе к лету можем вернутся к этой дискуссии. )
Ну, чтобы попробовать, ждать лета нет нужды. Даже наоборот полезено было бы сделать это пока есть азарт.
Как я уже сказал можно потренироваться на Mini C. Это позволит понять что нужно бдудет сделать в реальном бэкнде, а так же немного освоиться с Нитрой и Немерле. Надеюсь тебе эти языки понравятся.
Сам код этого проекта находится тут: https://github.com/rsdn/Nitra-Mini-C
Здесь описны DSL-и для работы с AST и типизацией. Эту статью можно прочесть целиком, но скорее ее надо рассматривать как документацию. Так что если в ней что то будет не понятно — это не страшно.
Вот здесь
описание языка грамматик Нитры. Это вообще на всякий случай. Для работы с бэкэндом синтаксис вообще не важен.
Так же имеет смысл собрать Nitra с исходников (инструкция здесь). https://github.com/rsdn/nitra/wiki/Nitra-Build-process
и проект Mini C. Для этого его надо поместить в папку рядом с папкой Nitra и собрать Nitra-Mini-C.sln. Корневую папку лучше делать неглубокой. Но об этом сказано в Nitra Build process.
Ну, а дальше мой скайп vc.rsdn.ru Просто постучись по нему и вместе наметим план работ. Вопросы можно задавать как по скайпу так и на форуме.
В зависимости от выделяемого времени это может занять от недели до 1-2 месяцев. Надеюсь это будет увлекательно!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_>>Слишком опасно. ) Особенно для меня (перепробовавшего множество языков, но так и не нашедшего идеала)... ))) Есть большой соблазн сделать "ещё один никому кроме тебя не нужный язык". ))) Безопаснее портировать на нужную тебе платформу какой-то приличный язык у которого уже есть сообщество и т.п. _>>Хотя если есть очень много свободного времени и желание поразвлечься, то... Но боюсь это не про меня. ) VD>Я, видимо, выразился недостаточно понятно. Я не имел в виду, что тебе придется создавать новый язык с нуля. Прод реальным языком я имел ввиду Native Nemerle 2.
Ага, вот это уже интереснее. Причём я тут подумал — действительно наверное не получится просто перенести обычный Nemerle на нативную платформу. Точнее сделать это без проблем можно, но только результат будет мало кому интересен. А вот если сделать адаптацию, которая позволит использовать все возможности нативной платформы (чтобы грубо говоря было удобно и драйверы писать), при этом не потеряв в удобстве и безопасности, то это очень многим бы пришлось по вкусу. Хотя это и не так просто (см. например попытки в Rust'е).
VD>Но так как Nemerle — это конструктор, ты все же сможешь (позже) добавить в язык необходимы именно тебе фичи или отключить не нужные. Так что идея создать свой если не язык, то диалект, становится куда реалистичнее.
Угу, у меня как раз есть несколько идей в данной области. В том смысле что не какие-то оригинальные концепции, а скорее понимание того, какой конкретно набор известных концепций должен реализовать идеальный нативный язык.
_>>Тогда ближе к лету можем вернутся к этой дискуссии. ) VD>Ну, чтобы попробовать, ждать лета нет нужды. Даже наоборот полезено было бы сделать это пока есть азарт.
Я же говорил уже — сейчас времени нет совсем, т.к. у нас сейчас важный проект в стадии завершения разработки и выпуска. ) Вот запустится он удачно и можно будет расслабиться. )))
VD>Как я уже сказал можно потренироваться на Mini C. Это позволит понять что нужно бдудет сделать в реальном бэкнде, а так же немного освоиться с Нитрой и Немерле. Надеюсь тебе эти языки понравятся.
На Немерле я уже когда-то давно посматривал. Выводы были такие: макросы — очень приятно, синтаксис — мне в принципе сойдёт, есть минусы (в основном имеющие свои корни в .Net). Про Нитру только слышал, но ничего не видел.
VD>Собственно начать надо с изучения вот этой статьи: VD>http://rsdn.org/article/nitra/MiniC/Nitra-Mini-C.xml
VD>Сам код этого проекта находится тут: https://github.com/rsdn/Nitra-Mini-C VD>Здесь описны DSL-и для работы с AST и типизацией. Эту статью можно прочесть целиком, но скорее ее надо рассматривать как документацию. Так что если в ней что то будет не понятно — это не страшно.
Кстати мне в одном проекте требовалась интеграция в приложение исполнения вот такого https://www.compuphase.com/pawn/pawn.htm забавного язычка — в чём-то похоже, хотя он и не игрушечный. )
VD>Вот здесь
описание языка грамматик Нитры. Это вообще на всякий случай. Для работы с бэкэндом синтаксис вообще не важен. VD>Так же имеет смысл собрать Nitra с исходников (инструкция здесь). VD>https://github.com/rsdn/nitra/wiki/Nitra-Build-process
Хы, а зачем запускать VS от админа? ) Т.е. мне то не принципиально (если не считать конечно само отсутствие VS на данный момент на моей рабочей машине), но просто глаз зацепился и интересно. )))
VD>и проект Mini C. Для этого его надо поместить в папку рядом с папкой Nitra и собрать Nitra-Mini-C.sln. Корневую папку лучше делать неглубокой. Но об этом сказано в Nitra Build process.
Угу, и кругом sln файлы в качестве системы сборки. И тут (ну это ещё ладно, разово собрать и всё, можно даже не на рабочем компьютере) и у Mini-C... Это вот первым делом пришлось бы переделать, если переходить на кроссплатформенный уровень.
Кстати (отвлечённые рассуждения), вот казалось бы как раз при программирование под .net (для которого готовый компилятор и библиотеки есть на любом компьютере с виндой) люди должны были бы предпочитать использовать какие-то независящие от IDE системы сборки (любой проект просто копируется и собирается в консольке на любой машине, без установки какого-то дополнительного ПО), однако тут явное засилье проектов VS. В то время как у какого-нибудь C++, у которого для сборки надо установить на компьютер кучу всего (по отдельности или одного жирного монстра типа VS) и тут казалось бы должны были предпочитать работу в проектах для VS, но вместо этого как раз процветают системы сборки (тот же CMake) даже при использование VS.
VD>Ну, а дальше мой скайп vc.rsdn.ru Просто постучись по нему и вместе наметим план работ. Вопросы можно задавать как по скайпу так и на форуме.
Да думаю без проблем договоримся там. ) Можно даже и в реале пересечься (в одном городе живём всё же) со временем.
VD>В зависимости от выделяемого времени это может занять от недели до 1-2 месяцев. Надеюсь это будет увлекательно!
Ну я обычно занимаюсь подобными фановыми вещами "запоями", так что думаю скорее будет речь про неделю. ))) Но ближе к лету. )
Здравствуйте, alex_public, Вы писали:
_>Ага, вот это уже интереснее. Причём я тут подумал — действительно наверное не получится просто перенести обычный Nemerle на нативную платформу. Точнее сделать это без проблем можно, но только результат будет мало кому интересен. А вот если сделать адаптацию, которая позволит использовать все возможности нативной платформы (чтобы грубо говоря было удобно и драйверы писать), при этом не потеряв в удобстве и безопасности, то это очень многим бы пришлось по вкусу. Хотя это и не так просто (см. например попытки в Rust'е).
Проблема в том, что в этом случае от немерле мало что останется.
Уж слишком там всё на глобальный ГЦ завязано. А ты как я понимаю ГЦ не хочешь.
В принципе у меня есть понимание как сделать язык с опциональным локальным ГЦ. Те если писать аккуратно, то ГЦ вообще можно не включать. Либо включать только для части кода не останавливая остальной.
Но в этом случае от немерле останется ещё меньше.
_>Угу, у меня как раз есть несколько идей в данной области. В том смысле что не какие-то оригинальные концепции, а скорее понимание того, какой конкретно набор известных концепций должен реализовать идеальный нативный язык.
Вот это нужно написать перед началом работы над языком.
Причём чем раньше, тем лучше.
Ибо ты можешь чего-то не знать, забыть или просто не подумать.
Чтобы снизить риски появления концептуальных косяков концепцию нужно обсудить.
Перед тем как ты будешь формулировать свои мысли прочитай эти статьи (список по ссылке). http://joeduffyblog.com/2015/11/03/blogging-about-midori/
Букв много. Но всё по делу. Перед созданием нового языка читать обязательно.
В двух словах: Мужик работал над созданием полностью управляемой ОС и пишет какие были варианты, какие из них оказались рабочими и какие нет. А главное почему.
А вообще весь блог рекомендую.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, alex_public, Вы писали:
_>Ага, вот это уже интереснее. Причём я тут подумал — действительно наверное не получится просто перенести обычный Nemerle на нативную платформу. Точнее сделать это без проблем можно, но только результат будет мало кому интересен.
Уж если Go кому-то интересен, то уж Нативный Nemerle точно должен быть интересен. Языки и рядом не стояли. Вот только надо название сменить (наверно) и пиар-компанию продумать или найти брэнд через который язык двигать (как тот же Go).
_>А вот если сделать адаптацию, которая позволит использовать все возможности нативной платформы (чтобы грубо говоря было удобно и драйверы писать), при этом не потеряв в удобстве и безопасности, то это очень многим бы пришлось по вкусу.
Доводка напильником — это само собой. Немерл на то и задуман, чтобы это стало возможным.
_>Хотя это и не так просто (см. например попытки в Rust'е).
Я уже говорил. Беда Rust в том, что авторы отказались от GC и исключений. Это идиотизм. Вот наличие возможностей жить без них — это хорошо. А их полное отсутствие — это идиотизм.
Удобство не должно приноситься в жертву эффективности. Если для каких-то задач GC и исключения — зло, то надо просто дать возможности их не использовать. Проконтролировать это не сложно. Нужно только альтернативные механизмы сделать.
_>Угу, у меня как раз есть несколько идей в данной области. В том смысле что не какие-то оригинальные концепции, а скорее понимание того, какой конкретно набор известных концепций должен реализовать идеальный нативный язык.
Ну, вот и сможешь осуществить свои задумки. При этом не придется городить язык с нуля. Это, конечно, задача неподъемная.
_>На Немерле я уже когда-то давно посматривал. Выводы были такие: макросы — очень приятно, синтаксис — мне в принципе сойдёт, есть минусы (в основном имеющие свои корни в .Net). Про Нитру только слышал, но ничего не видел.
Ну, вот почитав статейки можно хотя бы общее впечатление оставить.
_>Хы, а зачем запускать VS от админа? ) Т.е. мне то не принципиально (если не считать конечно само отсутствие VS на данный момент на моей рабочей машине), но просто глаз зацепился и интересно. )))
Откровенно говоря уже не помню. Возможно что-то регистрируется. У Немерла такое требование потому, что при сборке файлы копируются в %ProgramFiles%\Nemerle\Net-4.0, она новых версиях Винды закрыт на запись для смертных.
Но если VS не запустить из под админи, то даже приатачиаться отладчиком к другому процессу не выйдет. При попытке это сделать VS сама тебе предложит запуститься под админом.
_>Угу, и кругом sln файлы в качестве системы сборки.
И что? Это стандарт в дотнете. Студия работает именно с ними, потому и sln. При этом их без проблем можно собирать MSBuild-ом, который входит в донет и запуска IDE не требует..
_>И тут (ну это ещё ладно, разово собрать и всё, можно даже не на рабочем компьютере) и у Mini-C... Это вот первым делом пришлось бы переделать, если переходить на кроссплатформенный уровень.
В дотнете с этим нет никаких проблем. sln — это не более чем список проектов. Можешь заменить его на proj-файл MSBuild-а. Но при этом ты лишишься возможности открывать его в VS. Именно по этому никто так не делает.
Вот когда тебе придется собирать компилятор под LLVM на платформе где дотнета нет, то вместо него придется что-то другое брать. А в дотнете MSBuild — стандарт, а sln — один из его стандартных форматов.
_>Кстати (отвлечённые рассуждения), вот казалось бы как раз при программирование под .net (для которого готовый компилятор и библиотеки есть на любом компьютере с виндой) люди должны были бы предпочитать использовать какие-то независящие от IDE системы сборки
Ты просто явно с дотнетом много не возился. Не зависит от IDE этот формат. Просто у VS форматом проектов служат файлы MSBuild.
С этим есть проблемы на Mono. Там есть аналог MSBuild, но он не полностью совместим с прототипом (рукожопье в Моно процветало). Но сейчас МС на всех парах опенсорсит дотнет. Они создали .Net Core в который переводят все что можно. MSBuild не стал исключением. Сначала они запилили велосипед, но разум востержествовал и MSBuild тоже двинули в Core, попутно сделав MSBuild стандартом проектов и для Core. Так как лицензия на Core очень либеральная (Апач 2, если не ошибаюсь), то Моновцы уже сказали, что будут брать тулы из Core и перейдут на MSBuild.
_>Да думаю без проблем договоримся там. ) Можно даже и в реале пересечься (в одном городе живём всё же) со временем.
Да, можно и так. Я всегда "за".
_>Ну я обычно занимаюсь подобными фановыми вещами "запоями", так что думаю скорее будет речь про неделю. ))) Но ближе к лету. )
ОК
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Уж если Go кому-то интересен, то уж Нативный Nemerle точно должен быть интересен. Языки и рядом не стояли. Вот только надо название сменить (наверно) и пиар-компанию продумать или найти брэнд через который язык двигать (как тот же Go).
И зря ты так Go "обижаешь". Go никому не интересен как язык (ибо какашка полная), он интересен как инфраструктура для быстрой и простой разработки сетевых приложений (сайты, сервисы, всё что угодно), и в этом он реально крут. А какая будет ключевая фича у "нативного Nemerle"? То что он классный язык – этого слишком мало, как бы и не нативному Nemerle это не шибко помогает даже при наличии всей той прорвы библиотек, что доступна благодаря .NET.
Здравствуйте, kaa.python, Вы писали:
KP>И зря ты так Go "обижаешь". Go никому не интересен как язык (ибо какашка полная), он интересен как инфраструктура для быстрой и простой разработки сетевых приложений (сайты, сервисы, всё что угодно), и в этом он реально крут. А какая будет ключевая фича у "нативного Nemerle"? То что он классный язык – этого слишком мало, как бы и не нативному Nemerle это не шибко помогает даже при наличии всей той прорвы библиотек, что доступна благодаря .NET.
А в чем эта "инфраструктурность" заключается?
Я на Nemerle и сейчас, и 10 лет назад мог делать "сайты, сервисы, всё что угодно".
То есть вся разница в том, что он не требует виртуальной машины?
ЗЫ
Давай будем честными. Главное достоинство Go это — Google.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Только вот хотелось бы увидеть не "C без GC", a "Nemerle без GC"... 
