RP
Size: a a a
2020 August 15
b
@tucnak а как ты сделал лексер и парсер?
ну в лексере ничего интересного нет, парсер пытается интерпретировать поток лексем в пропозиции. в это время подпрограмма парсера — дедуктор — попутно разгадывает пропозиции заменяя их типа ассемблерными транзакциями, которые как я вижу в будущем можно будет оптимизировать. (в кэше хранятся precomputed деревья для всех посчитанных диалектов)
AS
Vetro
b
в чем прикол почему логосу нужен свой ассемблер? (кстати: все угорают почему го нужен свой ассемблер, но на самом деле для их корутинной модели и растущие стэки у горутин это очень имеет смысл)
b
а логосу нужен свой ассемблер, потому что как я говорил ранее, под капотом у логоса автивка, а это децентрализованная виртуальная машина
b
и если смотреть на нее со стороны данных, то это транзакционный леджер (типа блокчейна) и графовая модель
b
короче на уровне логос–ассемблера намного проще оперировать лоу–левел кухней того, как должны меняться данные. можно думать, что промежуточный ассемблер тут выступает роль типа ORM
b
какие-то инструкции тупо добавляют определенные ребра bulk-ом, какие-то наоборот удаляют (дельты), а какие-то инструкции потенциально могут работатать как JIT conditionals
b
ну типа если у тебя есть кейс: if p, then A else B
b
пропозиция p реально может не меняться в графе. если между текущей транзакцией и последней транзакцией значение p не менялось, то нет нужды его пересчитывать
b
ну и опять–таки, какие пропозиции кэшить и как? где можно сэкономить, а где нет? вот для этого и есть ассемблер — это понятная промежуточная абстракция между стейтом и лексическими “предписаниями” что нужно с этим стейтом сделать
b
например, классическая тема если у тебя есть p and q и ты знаешь что q это ложь, то тебе не надо считать p and q, ты моментально знаешь что вся пропозиция ложь
b
и конечно каждая пропозиция имеет точный адрес в диалекте… эти адреса и выступают в роли ключей для кэша. вот так вот оно и работает (по крайней мере, пока.) блокчейн протокол, dgraph база, redis кэш
KR
Ну, это имхо правильнее IR называть, нежели асмом
b
Ну, это имхо правильнее IR называть, нежели асмом
ну ты понимаешь что в стандартном диалекте есть конечное множество элементарных знаков, таких как integer или real или string или alien
b
хоть на уровне логоса string это rune list с парой пропозиций сверху, в реальности никто не будет хранить это так 🙂
b
и есть графовая база, в которой можно хранить такие-то вещи. ты можешь добавлять ребра в граф, а можешь отнимать их. тебе реально это в конце–концов нужно будет делать только 1 раз в самом конце (текст = транзакция = два списка дельт)
b
у actor, map, enigma — у всех этих элементарных штук может быть совсем не элементарная структура данных в графе
b
помните что ещё разные условия можно раскладывать как графовые операции
b
например grandchildren или самые короткие пути, потоки и тд