IPB
ЛогинПароль:

 
 Ответить  Открыть новую тему 
> Дизайн парсера, планы на будущее, Для ознакомления
сообщение
Сообщение #1


Большевик–концептуал
***

Группа: Пользователи
Сообщений: 180
Пол: Мужской
Реальное имя: Иван Левашев
Jabber: octagram@jabber.ru
Skype: i.levashew
QQ: 3152538431
WeChat
Ада: Сторонник
Embarcadero Delphi: Сторонник
Free Pascal: Разработчик
Turbo Pascal: Установлен

Репутация: -  1  +


Хотел бы обрисовать некоторую канву для понимания, чего я хочу.

Сейчас мне нужно наполнить окружение Ada 95 библиотеками, сделанными как мне удобно.

Это сильные ссылки, сделанные правильно.

Правильность можно увидеть здесь на 134ой строке.

      ----------------------------
-- Sample_Referenced.Plus --
----------------------------

function Plus
(Left : access Sample_Referenced;
Right : Sample_Reference'Class)
return Sample_Limited_Reference
is
Right_Access : constant Sample_Access := Operations.Get (Right);
begin
return Create (Left.Value_Field + Right_Access.Value_Field);
end Plus;


То чувство, когда OSDN поддерживает адский синтаксис, а собственный форум — нет



Во многих других реализациях здесь всё ссылки будут голыми, но в правильной обнажается только одна, Left : access Sample_Referenced, или часто это будет «Object», по которой производится диспетчеризация. И результат тоже не голый. Соответственно, обёртки, реализующие сильную ссылку, обнажают только один указатель, а не все.

При помощи таких ссылок мне понадобятся сначала потоки. Абстрактный поток и одна реализация, которая заворачивает Ada.Streams.Stream_IO.File_Type. Деструктор этой реализации должен закрывать File_Type.

Чтобы такой поток можно было применять со стандартными адскими встроенными атрибутами, понадобится обёртка, заворачивающая сильную ссылку (по идее, ничего не стоит, кроме +1 указателя-тега) и делегирующую ей вызовы своих методов. Ещё будет полезно сделать более легковесную обёртку, с access дискриминантом на сильную ссылку, и тоже с делегацией. Это должно решить все вопросы интеграции с другим адским кодом.

Поверх потоков делается аналог http://docwiki.embarcadero.com/Libraries/R…ses.TTextReader и его потомок TStreamReader, декодирующий UTF-8. Всё с использованием сильных ссылок. То есть, Stream_Reader заключает в себе сильную ссылку на Stream.

Соглашение об именовании: сильные ссылки (обёртки) называются как-нибудь попроще, например, Text_Reader, а в названии реализации есть суффикс _Referenced, например, Text_Reader_Referenced.

Sample_Reference / Sample_Referenced в примере не соответствуют этому соглашению. По этому правилу следовало бы назвать Sample / Sample_Referenced, но вот не стал.

Про Юникод: Ada 95 не поддерживает UTF-32 нативно, то есть, литералы такие писать нельзя так просто, но всё равно должен быть UTF-32. У меня есть частичная реализация UTF-32 для AdaMagic, где Wide_Wide_Character объявлен как новый численный тип. Не знаю, как ещё сделать тип, который видим извне как перечисляемый, то есть, в for, case и in работает. Если требуется написать литерал, это может выглядеть так: Wide_Wide_Character'Val (Wide_Character'Pos ('(')). Увы. Для текстовых строк, может быть, придётся сделать генератор выражений типа Wide_Wide_Character'Val (34), Wide_Wide_Character'Val (65), … GNAT, будучи совместимым с Ada 95, поддерживает UTF-32 как-то так, и мы тоже справимся.


Дальше начинается интересное. Получив абстрактный Text_Reader, я бы хотел иметь возможность сохранять точки останова парсера. Точка останова — это, грубо, позиция в тексте. Но на эту точку останова навешены события при уничтожении. Точка останова даёт возможность читать текст с сохранённой позиции снова и снова. Это возможно за счёт того, что есть некий буфер, и этот буфер отслеживает, где есть точки останова, например, сбалансированным деревом. Если какой-то чтец забегает вперёд, то новые данные подгружаются из Text_Reader и добавляются в буфер, и отдаются чтецу.

Это примерно похоже на интерфейс парсер-комбинаторов:
String → (Type, String)

То есть, парсер-комбинатор берёт на вход недочитанную строку, пытается прочитать из неё то, что умеет читать, и возвращает пару из прочитанного значения типа Type, и String с тем, что осталось.

Например, жадное чтение числового литерала сработает так: "123, abc, …" → (123, ", abc, …")

Точки останова, которые я хочу, чтобы были — это как раз String на входе и на выходе. В Haskell String — это ленивый список символов, в нашем случае это «буфер+Text_Reader+облако точек останова».

Когда точки останова уничтожаются, текст, который остался позади, можно выбросить. Не знаю, получится ли, но хотелось бы попытаться писать так, чтобы точка останова в начале файла не висела в памяти до победного, а освобождалась как можно раньше, и так по всему или почти по всему коду. Например, в программном интерфейсе это может выражаться в том, что процедуры, читающие отдельные блоки, принимают на вход точку останова не в режиме in, а в режиме in out с возможностью уничтожения как только стало понятно, что в данном конкретном месте может сработать только этот конкретный блок и никакой другой. Например, в C, если прочитано "void something (void) {", то после "{" уже точно понятно, что это процедура.

Есть ещё идея поверх Text_Reader сделать лексер, чтоб производил поток лексем, и точки останова уже в потоке лексем, а не потоке UTF-32 символов оставлять.

Задача не предполагает написания кода. Ознакомление и дискуссия

Сообщение отредактировано: OCTAGRAM -


--------------------
If you want to get to the top, you have to start at the bottom
 Оффлайн  Профиль  PM 
 К началу страницы 
+ Ответить 

 Ответить  Открыть новую тему 
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 





- Текстовая версия 23.10.2019 9:43
500Gb HDD, 6Gb RAM, 2 Cores, 7 EUR в месяц — такие хостинги правда бывают
Связь с администрацией: bu_gen в домене octagram.name