Спасибо) Удачи тебе с твоим проектом! Я пытался читать репозитории GCC, Swift, Go, Rust, правда все что я понял - там слишком много страшного кода, который совершенно не понятен :( Приходится как-то выкручиваться и самому изобретать велосипед, хоть и уже и так видно, что он получился так себе. Надо будет почитать книжек по компиляторам
Вы абсолютно правы, и я бы не хотел повторять историю гошки, то есть без GC. Думаю, сделать операторы new/delete как в плюсах потому что они как по мне более красивые что-ли. Однако создание объектов в куче может быть полезным только в том случае, если в языке будут добавлены указатели. Сейчас указателей нет, хотя в скором времени планирую добавить. Спасибо за поддержку, я обязательно буду продолжать писать про свой язык) Ждите следующую пачку обновлений!
Многопоточки пока что нет, но хотелось бы добавить её. Для начала мне стоит самому разобраться полностью как она работает и как воссоздать довольно удобное решение в IR дракона
Спасибо за книги, я обязательно их прочитаю. Ридми и примеры программ я пока что не писал, ведь изначально целился в создание языка для себя, а не только для статьи. В скором времени будет улучшен ридми!
Вы безусловно правы, и я тоже понимаю, что всё самое интересное LLVM прячет за своей спиной. У меня в планах помимо разработки оникса написать ещё и ВМ и компилятор, который транспилируется сразу в асм. Возможно даже сделаю свою реализацию фреймворка, похожего на LLVM, но явно проще. Вполне возможно что-то из этого буду писать не на плюсах, а на си. У меня всё ещё впереди
Спасибо за критику, я обязательно учту эти замечания ☺️
У вас на самом деле крутой проект, хорошая фантазия, я уверен, что он у вас получится
Что касаемо лексера как конечный автомат, то я не совсем понял, что вы имели ввиду. Если вы имеете ввиду сделать так, чтобы лексер возвращал список токенов, а не один токен как сейчас, то моя реализация экономически выгодна и более производительна, чем возврат списка, который до этого будет много раз реаллоцироваться и занимать больше места, чем реально необходимо. В принципе подход не важен, но мне было интересно попробовать сделать именно такой подход
Да, кодогенератор уже ожидает созданную структуру из VisitStructStmt, также как и вызов функции ожидает явное определение выше. В будущем планируется допускать использование функций и структур до их явного определения. В текущей реализации семантики возвращается нулевой i32 для того, чтобы не ломалась семантика (а еще мне просто лень везде проверять выражения на .has_value(), где-нибудь я бы его точно потерял и узнал об этом через какое-то время)
Спасибо) Удачи тебе с твоим проектом! Я пытался читать репозитории GCC, Swift, Go, Rust, правда все что я понял - там слишком много страшного кода, который совершенно не понятен :(
Приходится как-то выкручиваться и самому изобретать велосипед, хоть и уже и так видно, что он получился так себе. Надо будет почитать книжек по компиляторам
GC - не мой случай, так что либо буду пытаться добавлять владение, либо всё будет на совести разработчика :)
Это очень круто проект, так держать!
Вы абсолютно правы, и я бы не хотел повторять историю гошки, то есть без GC. Думаю, сделать операторы new/delete как в плюсах потому что они как по мне более красивые что-ли. Однако создание объектов в куче может быть полезным только в том случае, если в языке будут добавлены указатели. Сейчас указателей нет, хотя в скором времени планирую добавить. Спасибо за поддержку, я обязательно буду продолжать писать про свой язык) Ждите следующую пачку обновлений!
Понял, спасибо, попробую представить примерный концепт того, как это будет выглядеть. Правда реализовывать я это буду очень нескоро
К этому я и пытаюсь стремиться) Но пока что не знаю как это делать без LLVM апи. Наверное придется траслировать код в IR
Многопоточки пока что нет, но хотелось бы добавить её. Для начала мне стоит самому разобраться полностью как она работает и как воссоздать довольно удобное решение в IR дракона
Я с самого начала был нацелен и настроен на то, что нужно будет написать не только стд, но и приятную стд, а не как у плюсов)
У меня такой стиль
Спасибо за книги, я обязательно их прочитаю. Ридми и примеры программ я пока что не писал, ведь изначально целился в создание языка для себя, а не только для статьи. В скором времени будет улучшен ридми!
Спасибо за критику, буду учитывать всю критику
Спасибо) Как только появится шанс - вы обязаны попробовать свою идею, это всё очень и очень интересно!
Спасибо большое)
Вы безусловно правы, и я тоже понимаю, что всё самое интересное LLVM прячет за своей спиной. У меня в планах помимо разработки оникса написать ещё и ВМ и компилятор, который транспилируется сразу в асм. Возможно даже сделаю свою реализацию фреймворка, похожего на LLVM, но явно проще. Вполне возможно что-то из этого буду писать не на плюсах, а на си. У меня всё ещё впереди
Вы правы, не знаю под чем я был, когда писал это 😅
Спасибо за критику, я обязательно учту эти замечания ☺️
У вас на самом деле крутой проект, хорошая фантазия, я уверен, что он у вас получится
Что касаемо лексера как конечный автомат, то я не совсем понял, что вы имели ввиду. Если вы имеете ввиду сделать так, чтобы лексер возвращал список токенов, а не один токен как сейчас, то моя реализация экономически выгодна и более производительна, чем возврат списка, который до этого будет много раз реаллоцироваться и занимать больше места, чем реально необходимо. В принципе подход не важен, но мне было интересно попробовать сделать именно такой подход
Проект интересный, явно надо продолжать!
Он есть:
TkI64Lit, в семантике и кодгене он тоже учитывается, а вот в лексере забыл сделать суффикс, спасибо, что нашли косякPS: Я уже исправил недоработку, ещё раз спасибо!
Вы правильно заметили) Но я тоже это учел и в семантике всё это запрещается, так что до LLVM дойдет только "правильный", скажем так, код
Да, кодогенератор уже ожидает созданную структуру из VisitStructStmt, также как и вызов функции ожидает явное определение выше. В будущем планируется допускать использование функций и структур до их явного определения. В текущей реализации семантики возвращается нулевой i32 для того, чтобы не ломалась семантика (а еще мне просто лень везде проверять выражения на .has_value(), где-нибудь я бы его точно потерял и узнал об этом через какое-то время)