|
Обсуждение языковой трансляции
|
|
| zamabuvaraeu | Дата: Среда, 01.07.2026, 09:30 | Сообщение # 16 |
|
Полковник
Группа: Друзья
Сообщений: 219
Статус: Offline
| к.с слово THEN спарсится только после выражения, а выражение может быть некорректным, что должно останавливать парсинг,
Нет, не должно останавливать. Иначе нельзя будет ловить несколько ошибок в тексте. Вот ошибка в строке 10 и 500, если остановиться на десятой строке, тогда не получим сообщение об ошибке на строке 500.
Корректность выражения нельзя определить на этапе разбора лексем. Потому что у нас ещё не все символы определены.
Например:
If foo(1) Then
foo — это массив? или функция? или макрос с параметрами? Или внешний символ из другого файла объявленный как extern?
Лексический анализатор должен выдавать на foo только лексему с типом Identifier.
А ещё у нас есть области видимости: Common, Shared, Private. Переменные внутри блока (функция, цикл, условие, Case, Scope) не должны быть видны извне. Возложить обязанности проверки области видимости на парсер лексем? не слишком ли много задач на себя берёт лексический анализатор?Добавлено (01.07.2026, 13:58)
---------------------------------------------
Цитата Если у меня будет готовый массив конструктов, то мне никакие деревья уже будут не нужны.
Код Dim x As Integer = 100
If x = ... Then
For i As Integer = 0 To 10
Do Wile y
For j As Integer = 0 To 10
Next
Loop
Next
For i As Integer = 0 To 10
Foo(i)
Next
End If
Это в чистом виде дерево:
Код Program
|
|
--> Dim
|
|
--> If
|
|
---> For
| |
| |
| ---> Do
| |
| |
| ---> For
|
|
---> For
|
|
---> Foo
|
| |
|
|
| DarkDemon | Дата: Пятница, 03.07.2026, 10:15 | Сообщение # 17 |
|
Генерал-майор
Группа: Друзья
Сообщений: 345
Статус: Offline
| Цитата foo — это массив? или функция? или макрос с параметрами?
Для этого я в начале темы как раз разобрал(и уже скодил) дерево символьных переходов. Которому надо отдать
этот самый Identifier. И мы сразу поймём оператор это, функция или переменная. Это можно делать даже
по ходу дела скармливая по символу, а разделитель будет лишь подводить черту. Это очень простая задача
сложность вообще не в ней, а в комплексности строки - учесть всё, что в строке есть.
Цитата zamabuvaraeu (  ) Иначе нельзя будет ловить несколько ошибок в тексте.
Так и не ставлю своей целью писать лексический анализатор. Для меня поиск нескольких ошибок в заведомо
некорректном коде - это какая-то магия, понятно что продвинутые анализаторы может и могут что-то там
найти по косвенным факторам. Но зачастую это не к селу не к городу, т.к. ошибки человек всё равно фиксит
последовательно.
Первичная задача понять как разобрать строку. Бейсик со всеми его операторами и возможностями
реализовать сразу невозможно, поэтому цели две: задокументировать хотелки полностью и понять как делать
анализ архитектурно дополняемым.
Цитата zamabuvaraeu ( ) А как вложенность обрабатывать? Возьмёт такой псевдокод:
Над этим пока не думал, там будет свой набор структур, возможно стек, возможно дерево.
Само собой вложенность операторов надо учитывать.
Цитата Это в чистом виде дерево:
Зачем? Ты помнишь как проверять скобки в выражении? По количеству закрывающих и открывающих.
Тут если надо просто проверить - изначально тот же принцип. Потом вторая проверка, чтобы оно было
в правильных местах. В детали пока не вдавался.
Цитата zamabuvaraeu ( ) А ещё у нас есть области видимости: Common, Shared, Private.
Это нужно, но невозможно обдумать сразу каждую подобную деталь. Совмещение архитектурных элементов
идёт последовательно. Фактически посимвольный разбор в том варианте, который избрал будет включать
в себя несколько стадий и останов по факту при первой же ошибке. Это самое базовое что хочу сделать.
Если это будет, то дальше можно уже будет говорить хоть о чём-то.
Сообщение отредактировал DarkDemon - Пятница, 03.07.2026, 10:16 |
| |
|
|
| zamabuvaraeu | Дата: Пятница, 03.07.2026, 16:41 | Сообщение # 18 |
|
Полковник
Группа: Друзья
Сообщений: 219
Статус: Offline
| Нам же надо строить ассемблерный код.
Если бы у нас была линейная программа которая выполняется сверху вниз без переходов, можно было бы обойтись массивом лексем. Одно выражение языка = несколько лексем, это транслируется в набор команд ассемблера. Идём сверху вниз по массиву, получаем плоское отображение массива лексем ассемблерный код.
Но у нас есть уровни вложенности: условия, циклы внутри циклов, функции, подпрограммы.
А какая структура данных отвечает за вложенность? Дерево.
Вот затем оно и нужно.
|
| |
|
|
| DarkDemon | Дата: Пятница, 03.07.2026, 17:59 | Сообщение # 19 |
|
Генерал-майор
Группа: Друзья
Сообщений: 345
Статус: Offline
| Цитата zamabuvaraeu ( ) А какая структура данных отвечает за вложенность? Дерево.
Структура сказать честно мало за что отвечает, отвечает алгоритм который работает со структурой.
А так есть и стек, там тоже есть вложенность. Т.к. стек это последовательность элементов, то
его можно маппировать на список и пользоваться данными с разным доступом. Алгоритмически
вариантов как и что использовать - довольно много. И если проще чем деревом никак не подлезть
- тогда конечно.
Стал бы я вообще связываться с этими деревьями если без них никак. Надо всё анализировать.
Может ты и прав и там будет жопа. Но хочу это выяснить и попробовать максимально упростить
процесс и сделать его итеративным, чтобы без проблем можно было отладить всё по шагам.
Потому что макаронинг чисто в самом процессе - будет(разбор сложный) и надо его максимально
контролировать и раскладывать на последовательные CASE-ы.Добавлено (03.07.2026, 18:07)
---------------------------------------------
Цитата Нам же надо строить ассемблерный код.
Пока я согласен лишь с одной стадией из общепринятой теории, это приведение к виду одной операции за раз.
После неё уже строим ASM код. А до неё идёт стадия разбора, самая геморная стадия.
С ASM кодом там тоже не так всё просто будет, надо будет в реальном времени проверять свободные регистры,
а вот что делать, если они закончатся - пока не придумал.
Разбор сделать важнее, т.к. после него есть вариант скодить стадию интерпретации - чисто для проверки
работы всей системы.
|
| |
|
|
| zamabuvaraeu | Дата: Пятница, 03.07.2026, 18:45 | Сообщение # 20 |
|
Полковник
Группа: Друзья
Сообщений: 219
Статус: Offline
| Ещё нужно написать библиотеку времени выполнения для языка.
Например, такие штуки как OPEN, CIRCLE, REDIM, COS и даже Dim s As String — это всё вызов функции из библиотеки.
|
| |
|
|
| DarkDemon | Дата: Суббота, 04.07.2026, 20:49 | Сообщение # 21 |
|
Генерал-майор
Группа: Друзья
Сообщений: 345
Статус: Offline
| Цитата zamabuvaraeu ( ) Ещё нужно написать библиотеку времени выполнения для языка.Например, такие штуки как OPEN, CIRCLE, REDIM, COS и даже Dim s As String — это всё вызов функции из библиотеки.
Первоначально без библиотеки, сами конструкции, но по хорошему - нужно много всего,
понятно что в одиночку это долго тащить, даже несмотря на кучу всяких наработок по разным вопросам,
разумеется если решусь это кодить. Пока непонятно. По идее все понимают зачем и почему.
Базовая цель разбор строки. Потом вертикальная логика, потом компиляция, потом только функционал.
На самом деле на прошлой неделе уже почеркал операторы со скрина в начале темы, но не сохранил
оно лежало на RAMDisk-е, комп подвис и теперь эту работу делать повторно...
|
| |
|
|
| DarkDemon | Дата: Воскресенье, 05.07.2026, 02:35 | Сообщение # 22 |
|
Генерал-майор
Группа: Друзья
Сообщений: 345
Статус: Offline
| Короче попытка №2:
Обоснование:
- Операции с вещественными числами мы пока уберём (там несколько месяцев ковырять только преобразование)
- Операции со строками пока уберём (тут не так всё жёстко, но базовое упрощение требует)
- Для отладки выражений нам потребуется CLS и PRINT (WRITE на будущее для строк)
- Для работы выражений и условий нам потребуются: DIM ... AS ... , IF и сопутств..
- Важно сразу начать прорабатывать SELECT CASE.
- Модульность в виде SUB и FUNCTION разумеется нужна со старта.
- GOTO включим как базу (ибо даже мозговик Вирт не осилил теор. выпендрёж Эдсгера)
- Циклы DO и FOR нужны со старта.
- UDT пока опустим для упрощения.
- Ключевые слова для логических и арифметич выражений временно опустим (жёлт).
|
| |
|
|
|
