RS
Тогда нужно будет идти по пути Си и делать разделение объявления и реализации и заголовочные файлы, чтобы за один проход можно было компилировать.
У Оберона в однопроходном компиляторе не как в Си подход, а гораздо лучше. Почитайте книгу Вирта.
Size: a a a
2020 April 04
а
Ну, вот в firefox-е libxul.so - это 100MiB, при чём, для armv8. Тоже, так сказать, не утончённо. Полная сборка Linux меньше размером.
а linux и не на плюсах
VM
Тогда нужно будет идти по пути Си и делать разделение объявления и реализации и заголовочные файлы, чтобы за один проход можно было компилировать.
Хм, модули в C++ ведь узаконены с месяц назад?
Для сравнения: Modula-2 ( 1979)
Для сравнения: Modula-2 ( 1979)
p
@fulcanelly кстати, можешь сделать синтаксис лиспа, тогда вообще не придется париться с парсингом, там LL1 грамматика😁
RS
В Обероне тоже LL1
p
Не слышал про такой
ИЧ
а как же lua, очень нишевый язык, с динамической типизацией, имеет jit, а питон блин тормоз :с
МБ
а linux и не на плюсах
Это и демонстрирует, что мономорфизация - удовольствие не бесплатное. В Linux функциональности больше, чем в Firefox, а кода меньше.
Мономорфизация хорошо будет работать для мелких синтетических тестов и показывать высокую скорость, но когда кода много, уже всё не так очевидно становится.
Мономорфизация хорошо будет работать для мелких синтетических тестов и показывать высокую скорость, но когда кода много, уже всё не так очевидно становится.
M
а как же lua, очень нишевый язык, с динамической типизацией, имеет jit, а питон блин тормоз :с
Lua значительно проще питона, кроме того LuaJIT значительно отстал от интерпретатора насколько я помню.
Основная проблема питона в дизайне его рантайма и байндинга с C, который мешает сделать нормальный JIT
Основная проблема питона в дизайне его рантайма и байндинга с C, который мешает сделать нормальный JIT
ИЧ
MaxGraey
Lua значительно проще питона, кроме того LuaJIT значительно отстал от интерпретатора насколько я помню.
Основная проблема питона в дизайне его рантайма и байндинга с C, который мешает сделать нормальный JIT
Основная проблема питона в дизайне его рантайма и байндинга с C, который мешает сделать нормальный JIT
Давайте его чинить 🌚
DP
Имхо причины чисто экономические: если тормозит код на руби/питоне, проще и эффективнее найти в нем узкое место и переписать его на си. А вот для приложений на джиесе альтернативы нет
а почему никогда не рассматривается третья альтернатива — метапрограммирование, когда _каждая прикладная программа_ является неким узкоспециализированным компилятором? (кодогенерация, биндинг на LLVM)
т.е. вообще не важно, на каком языке писать, и насколько он быстр, так как работает только один раз в compile time
т.е. вообще не важно, на каком языке писать, и насколько он быстр, так как работает только один раз в compile time
DS
Это и демонстрирует, что мономорфизация - удовольствие не бесплатное. В Linux функциональности больше, чем в Firefox, а кода меньше.
Мономорфизация хорошо будет работать для мелких синтетических тестов и показывать высокую скорость, но когда кода много, уже всё не так очевидно становится.
Мономорфизация хорошо будет работать для мелких синтетических тестов и показывать высокую скорость, но когда кода много, уже всё не так очевидно становится.
Ну совсем не обязательно всю программу проектировать с упором на мономорфизацию.
Если понятно, что она в данном случае мешает производительности, то всегда можно, что в плюсах, что в том же расте, делать явные динамические вызовы.
Если понятно, что она в данном случае мешает производительности, то всегда можно, что в плюсах, что в том же расте, делать явные динамические вызовы.
DP
Кстати, а где можно почитать про подходы парсинга языка и трансляции его в ассемблер ?
А то эти АСТ мне пока-что совершенно непонятны, кажется не с них начинают.
По идее же есть какие-то простые/примитивные способы парсинга и трансляции ?
А то эти АСТ мне пока-что совершенно непонятны, кажется не с них начинают.
По идее же есть какие-то простые/примитивные способы парсинга и трансляции ?
можете вообще убрать парсинг — в качестве фронта пишите на том языке, на каком удобно, и дергайте бэк в виде биндинга LLVM к вашему языку
DP
Кстати, а где можно почитать про подходы парсинга языка и трансляции его в ассемблер ?
А то эти АСТ мне пока-что совершенно непонятны, кажется не с них начинают.
По идее же есть какие-то простые/примитивные способы парсинга и трансляции ?
А то эти АСТ мне пока-что совершенно непонятны, кажется не с них начинают.
По идее же есть какие-то простые/примитивные способы парсинга и трансляции ?
примитивный парсинг — язык Форт
DP
но как это получить...
берете за базу:
и строите дерево программы как хотите, никакого парсинга
class Object:и прямо в Python (или на чём там пишете) наследуете от Object -> Primitive -> Number, Object -> Control -> ForLoop и т.д.
attr = {} # атрибуты, см. атрибутные грамматики
nest = [] # ветви AST
и строите дерево программы как хотите, никакого парсинга
а
Dmitry Ponyatov
берете за базу:
и строите дерево программы как хотите, никакого парсинга
class Object:и прямо в Python (или на чём там пишете) наследуете от Object -> Primitive -> Number, Object -> Control -> ForLoop и т.д.
attr = {} # атрибуты, см. атрибутные грамматики
nest = [] # ветви AST
и строите дерево программы как хотите, никакого парсинга
хмммм
а
можно пример ?
а
рабочий
IJ
MaxGraey
AST это дерево. Вершины - это правила, ребра - это символы. Строиться из потока / списка токенов после лексического разбора. Нужен для постороения символьной таблицы, семантического анализа и дальнейшей трансформации (например в IR) или непосредственной генерации целевого низкоуровневого кода. Что здесь сложного?
Все же вершины соответствуют применению правил, а сами правила == типы вершин, если позанудничать
IJ
коллеги, мы говорим с человеком, который впервые столкнулся с парсингом, давайте не будем про ллвм, форт и прочее, это только запутывает