AT
/me читал (не полностью) две книги "про Haskell": "Жемчужины проектирования" и "Параллельное и конкурентное программирование".
Size: a a a
2021 March 12
a
/me изучал и в большой степени изучил Haskell, когда книжек по нему не было вообще...
me также. Мне кажется, имея опыт в программировании, хаскель не так уж и сложно расковырять самому
DG
Вроде, ещё не баян:
https://www.linux.org.ru/news/opensource/16203721
https://www.linux.org.ru/news/opensource/16203721
AT
me также. Мне кажется, имея опыт в программировании, хаскель не так уж и сложно расковырять самому
Не, "опыт в программировании" больше мешает... Даже знакомство с Common Lisp мне не помогло. Вот OCaml сильно помог, но тоже не на 100%, всё равно было больно "переламываться"...
МР
Пытаюсь разобраться с LLVM IR. С удивлением для себя обнаружил, что каждый фронтенд должен самостоятельно реализовывать целевой ABI. Это действительно так? Или я что-то не так понимаю?
МР
Если более конкретно, допустим я хочу вызвать (сгенерить вызов) функции
void f( struct{char* s;int low,high;} p); Смотрю, что clang генерит два параметра, соответственно, если написать .ll вида define i32 @f({i8*, i32, i32} %0) {... то работать не будетTP
Всем привет! Нисходящим парсером возможно реализовать разбор конструкций при которых нужно заглядывать на n токенов вперёд?
Наведу простой пример, vector<int64>() - expression, мы считываем токен Ident vector, затем следует токен Less < и у нас дилемма. То ли это InfixExpr (0 < 1), или же CallExpr ( vector<int64>(args) ) . При восходящем парсере это возможно было бы реализовать сверткой, но для этого требуется использовать уже существующие парсер-генераторы или писать свой (чего я не могу сделать, так как знаний очень мало в этой теме). Хотелось бы использовать LL(k) парсер, так как я его уже написал и хотелось бы его модифицировать под этим цели.
Наведу простой пример, vector<int64>() - expression, мы считываем токен Ident vector, затем следует токен Less < и у нас дилемма. То ли это InfixExpr (0 < 1), или же CallExpr ( vector<int64>(args) ) . При восходящем парсере это возможно было бы реализовать сверткой, но для этого требуется использовать уже существующие парсер-генераторы или писать свой (чего я не могу сделать, так как знаний очень мало в этой теме). Хотелось бы использовать LL(k) парсер, так как я его уже написал и хотелось бы его модифицировать под этим цели.
Знающие люди поправьте меня, но с вашим примером должно получится примерно следующее же.
Делая предположение что лексинг и парсинг это две разные стадии, получаем:
Имея такой набор токенов можно дальше сделать проверку типа такую: Если текущий токен = LESS, то попытаться распарсить следующую последовательность как (IDENTIFIER | (IDENTIFIER «,»)) GREATER. Если получилось то гуд. Если нет, то вернуться на токен LESS и парсить пробовать Infix
Делая предположение что лексинг и парсинг это две разные стадии, получаем:
Lexing
- - -
vector<int64>() =
IDENTIFIER «vector»
LESS
IDENTIFIER «int64»
GREATER
LEFT_PAREN
RIGHT_PAREN
- - -
Имея такой набор токенов можно дальше сделать проверку типа такую: Если текущий токен = LESS, то попытаться распарсить следующую последовательность как (IDENTIFIER | (IDENTIFIER «,»)) GREATER. Если получилось то гуд. Если нет, то вернуться на токен LESS и парсить пробовать Infix
TP
А если у вас в языке возможен только 1 параметр-тип, то вообще делать ничего не надо особо
2021 March 13
O
А если у вас в языке возможен только 1 параметр-тип, то вообще делать ничего не надо особо
Да, верно. Но для этого нужно реализовать функцию отката к заданному токену.
TP
Да, верно. Но для этого нужно реализовать функцию отката к заданному токену.
Думаю без такой функции вам будет тяжело парсер писать)
K
Да, верно. Но для этого нужно реализовать функцию отката к заданному токену.
K
откат там через try()
M
Вроде, ещё не баян:
https://www.linux.org.ru/news/opensource/16203721
https://www.linux.org.ru/news/opensource/16203721
Llhd llpm вроде есть кстати
ДК
Всем привет! Нисходящим парсером возможно реализовать разбор конструкций при которых нужно заглядывать на n токенов вперёд?
Наведу простой пример, vector<int64>() - expression, мы считываем токен Ident vector, затем следует токен Less < и у нас дилемма. То ли это InfixExpr (0 < 1), или же CallExpr ( vector<int64>(args) ) . При восходящем парсере это возможно было бы реализовать сверткой, но для этого требуется использовать уже существующие парсер-генераторы или писать свой (чего я не могу сделать, так как знаний очень мало в этой теме). Хотелось бы использовать LL(k) парсер, так как я его уже написал и хотелось бы его модифицировать под этим цели.
Наведу простой пример, vector<int64>() - expression, мы считываем токен Ident vector, затем следует токен Less < и у нас дилемма. То ли это InfixExpr (0 < 1), или же CallExpr ( vector<int64>(args) ) . При восходящем парсере это возможно было бы реализовать сверткой, но для этого требуется использовать уже существующие парсер-генераторы или писать свой (чего я не могу сделать, так как знаний очень мало в этой теме). Хотелось бы использовать LL(k) парсер, так как я его уже написал и хотелось бы его модифицировать под этим цели.
По этой причине, кстати, в D отказались от угловых скобочек для обрамления статических параметров в пользу круглых и квадратных, которые всегда парные и не являются самостоятельными инфиксными операторами.
AT
IP
По этой причине, кстати, в D отказались от угловых скобочек для обрамления статических параметров в пользу круглых и квадратных, которые всегда парные и не являются самостоятельными инфиксными операторами.
И получили те же проблемы относительно indexing operator
ДК
И получили те же проблемы относительно indexing operator
А какие с ним проблемы? Синтаксически то и то - массив.
IP
А какие с ним проблемы? Синтаксически то и то - массив.
Ну lookahead в парсере действительно не нужен, но выглядит очень двусмысленно