Pull to refresh
12
40.1
Send message

Вы абсолютно правы, и я бы не хотел повторять историю гошки, то есть без GC. Думаю, сделать операторы new/delete как в плюсах потому что они как по мне более красивые что-ли. Однако создание объектов в куче может быть полезным только в том случае, если в языке будут добавлены указатели. Сейчас указателей нет, хотя в скором времени планирую добавить. Спасибо за поддержку, я обязательно буду продолжать писать про свой язык) Ждите следующую пачку обновлений!

Понял, спасибо, попробую представить примерный концепт того, как это будет выглядеть. Правда реализовывать я это буду очень нескоро

К этому я и пытаюсь стремиться) Но пока что не знаю как это делать без LLVM апи. Наверное придется траслировать код в IR

Многопоточки пока что нет, но хотелось бы добавить её. Для начала мне стоит самому разобраться полностью как она работает и как воссоздать довольно удобное решение в IR дракона

Я с самого начала был нацелен и настроен на то, что нужно будет написать не только стд, но и приятную стд, а не как у плюсов)

У меня такой стиль

Спасибо за книги, я обязательно их прочитаю. Ридми и примеры программ я пока что не писал, ведь изначально целился в создание языка для себя, а не только для статьи. В скором времени будет улучшен ридми!

Спасибо за критику, буду учитывать всю критику

Спасибо) Как только появится шанс - вы обязаны попробовать свою идею, это всё очень и очень интересно!

Спасибо большое)

Вы безусловно правы, и я тоже понимаю, что всё самое интересное LLVM прячет за своей спиной. У меня в планах помимо разработки оникса написать ещё и ВМ и компилятор, который транспилируется сразу в асм. Возможно даже сделаю свою реализацию фреймворка, похожего на LLVM, но явно проще. Вполне возможно что-то из этого буду писать не на плюсах, а на си. У меня всё ещё впереди

Вы правы, не знаю под чем я был, когда писал это 😅

Спасибо за критику, я обязательно учту эти замечания ☺️

У вас на самом деле крутой проект, хорошая фантазия, я уверен, что он у вас получится

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

Проект интересный, явно надо продолжать!

Для 64-битного целого не завели литералы, дискриминация!

Он есть: TkI64Lit, в семантике и кодгене он тоже учитывается, а вот в лексере забыл сделать суффикс, спасибо, что нашли косяк

PS: Я уже исправил недоработку, ещё раз спасибо!

Вы правильно заметили) Но я тоже это учел и в семантике всё это запрещается, так что до LLVM дойдет только "правильный", скажем так, код

Да, кодогенератор уже ожидает созданную структуру из VisitStructStmt, также как и вызов функции ожидает явное определение выше. В будущем планируется допускать использование функций и структур до их явного определения. В текущей реализации семантики возвращается нулевой i32 для того, чтобы не ломалась семантика (а еще мне просто лень везде проверять выражения на .has_value(), где-нибудь я бы его точно потерял и узнал об этом через какое-то время)

Это просто, но не дает полного контроля над созданием AST. Мне больше по душе свобода действий. К тому же создавая парсер с 0 ты сам понимаешь как он работает

Спасибо за оценку)

Никто не учит, я самоучка, а первый язык написал в конце февраля прошлого года. Языков у меня довольно много, каждый раз пытаюсь сделать лучше и вроде как даже получается. Описывать грамматику я пока не хотел, потому что был занят созданием результата, а не продукта для всех с документацией. Естественно когда проект будет доведен до MVP будет и дока и возможно даже книга

Спасибо, в дальнейшем я обязательно учту эти замечания ☺️

Information

Rating
187-th
Registered
Activity

Specialization

Системный инженер
ООП
C++
C#
C