Это не оператор

ну разбор то всё равно происходит

Приоритеты расставляются после разбора, а не во время

Потому как приоритеты и фиксити кастомных операторов парсер не волнуют

А :: - это часть синтаксиса. Как скобки, например.

Какой приоритет у ( или у =? :)

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

Какой приоритет у ( или у =? :)

не важно, какой приоритет у =

Местная аннотация типов делается ДО разбора выражений на какие-то там $ и почее.

скобками на = в любом случае воздействовать нельзя, а на :: можно. Раз скобки изменяют выражение, значит можно говорить о приоритете

Тут нет никакого -1

Это приоритет парсинга

А не приоритет применения, который у $ равен 0

Местная аннотация типов делается ДО разбора выражений на какие-то там $ и почее.

ну вот тогда речь о том, что :: захватывает всё внутри скобок

Зачем это (приоритеты парсера и приоритеты применения функций) смешивать вообще?

значит его приоритет ниже, чем у $

Да блин, "жираф выше, чем крокодил длиннее"

И то и другое в метрах же!

Зачем это (приоритеты парсера и приоритеты применения функций) смешивать вообще?

разве приоритет операторов не влияет на итоговое AST?

нет

Потому как полиморфизм

1 + 2 * 3 могут давать разные AST в зависимости от приоритета, разве нет?

У парсера нет информации о приортетах ещё

или в корне будет стоять (+), или (*), в зависимости от

Смысл будет разный. А вот будут ли разные AST - не факт

Надо спросить у гуру :)

Парсер ничего не знает о том, что такое *

что такое AST тогда? если у 1 + 2 * 3 он не зависит от приоритета операторов. О каком дереве мы вообще говорим тогда?

AST cинтаксис Haskell описывает. А не семантику

Скобки - синтаксис. Приоритет кастомных операторов - семантика

ну вот тогда интересно посмотреть, в какое AST парсится 1 + 2 * 3

А что здесь 1 и +?

Int, или, скажем, Hour?

Инстансы Num будут разные

А если Num вообще скрыть и перегрузить + локально?

Это сколько же проходов парсера должно быть, чтобы понять, как парсить конкретное выражение?

Нужно распарсить - и "выполнить" - импорты. Потом тайпчекнуть всё, чтобы понять типы элементов выражения. Потом найти инстансы, предоставляющие конкретные версии операторов, если тайпклассы участвуют. И только потом строить AST выражения. Так что ли?

не знаю, я всегда думал, что приоритет операторов влияет на итоговое AST, возможно в Haskell это действительно не так

Призываются знатоки :)

@znatoky

Это сколько же проходов парсера должно быть, чтобы понять, как парсить конкретное выражение?

а компиляторописателям никто не обещал сладкой жизни:))

Надо лезть в код и понимать в какой момент infixr'ы всякие применяются. Можно эксперимент поставить (у кого компилятор под рукой) -- составить нетипизирующуюся конструкцию с двумя самописными операциями, сделать им одинаковый приоритет. Если раньше ругнётся тайпчекер, то значит AST разбирается без информации об операторах, если ругнётся на приоритет -- значит приоритет играет синтаксическую роль

https://stackoverflow.com/questions/29185467/parsing-with-user-defined-operator-precedence

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

> Infix operators are parsed as if they were all left-associative. The renamer uses the fixity declarations to re-associate the syntax tree.

> Infix operators are parsed as if they were all left-associative. The renamer uses the fixity declarations to re-associate the syntax tree.

кароч, после парсинга уже дерево перестраивается

Так что я был и прав, и лев: парсеру пофиг на приоритеты, но AST - итоговое - будет разное :)

Надо лезть в код и понимать в какой момент infixr'ы всякие применяются. Можно эксперимент поставить (у кого компилятор под рукой) -- составить нетипизирующуюся конструкцию с двумя самописными операциями, сделать им одинаковый приоритет. Если раньше ругнётся тайпчекер, то значит AST разбирается без информации об операторах, если ругнётся на приоритет -- значит приоритет играет синтаксическую роль

на приоритет раньше ругается!

Так, ребята, экзистенциальный вопрос. Функция - это структура данных?

$ cat foo.hs infixr 4 ## (##) :: Int -> Int -> Int (##) = undefined infixl 4 %% (%%) :: Int -> Int -> Int (%%) = undefined $ ghci foo.hs λ> 1 ## 2 %% "foo" <interactive>:1:1: error: Precedence parsing error cannot mix ‘##’ [infixr 4] and ‘%%’ [infixl 4] in the same infix expression λ> 1 ## (2 %% "foo") <interactive>:2:12: error: • Couldn't match expected type ‘Int’ with actual type ‘[Char]’ • In the second argument of ‘(%%)’, namely ‘"foo"’ In the second argument of ‘(##)’, namely ‘(2 %% "foo")’ In the expression: 1 ## (2 %% "foo")

смотри ка, @astynax, на приоритеты ругается раньше типизации

Главное, что это уже после парсинга делается :)

Ну, судя по всему парсинг двухстадийный

Но стадии идут непрерывно

> Sometimes the over-generous parsing is only dealt with by the renamer.

Так, ребята, экзистенциальный вопрос. Функция - это структура данных?

конечно, но она и морфизмом выступает также

смотри ка, @astynax, на приоритеты ругается раньше типизации

Тут мономорфные функции с известной фиксити

А морфизм - не структура данных?

Так, ребята, экзистенциальный вопрос. Функция - это структура данных?

ну, в питоне можно взять хэш от фунции, так что почему нет 😉

Хеш можно взять от чего угодно первоклассного

ну, в питоне можно взять хэш от фунции, так что почему нет 😉

такое себе значение получится :) >>> hash (lambda x: x) == hash(lambda x: x) True >>> hash (lambda x: x) == hash(lambda y: y) True >>> hash (lambda x: x) == hash(lambda y: y + 1) True

А еще от чего угодно, находящегося в памяти

А морфизм - не структура данных?

смотря в какой категории

такое себе значение получится :) >>> hash (lambda x: x) == hash(lambda x: x) True >>> hash (lambda x: x) == hash(lambda y: y) True >>> hash (lambda x: x) == hash(lambda y: y + 1) True

ага, скорее всего ещё и разное даже для одинаково объявленных функций

а что такое структура данных?

а что такое структура данных?

И это правильный вопрос!

такое себе значение получится :) >>> hash (lambda x: x) == hash(lambda x: x) True >>> hash (lambda x: x) == hash(lambda y: y) True >>> hash (lambda x: x) == hash(lambda y: y + 1) True

надо присвоить лямбды переменным. тогда разные значения пойдут. И разные даже для одинаковых лямбд

вот он, грязный язык во всей своей красе

а правильный ответ - 42

надо присвоить лямбды переменным. тогда разные значения пойдут. И разные даже для одинаковых лямбд

Это вообще дичь, ибо преременные - ссылки же.

надо присвоить лямбды переменным. тогда разные значения пойдут. И разные даже для одинаковых лямбд

Можно положить лямбды в мапу, а ключом-хешом использовать сгенеренный guid

И даже не так. Нужно же по хешу доставать лямбду, а как его узнать? Ну пусть она везде в программе идет кортежем вместе со своим хешом

Можно. Но сам факт хэшируемости функций - странный. Тем более что в питоне есть id - идентификатор объекта

Короче, ерунда получается

И даже не так. Нужно же по хешу доставать лямбду, а как его узнать? Ну пусть она везде в программе идет кортежем вместе со своим хешом

я серьезно встречал в статьях по питону предложение использовать фунции как ключи словаря, поэтому и запомнилось

тоже тогда подумал, что придётся же таскать везде хэш

ну когда-то это может быть полезно, например для имитиации switch-case

dict[lambda x:.. : ]?

ну когда-то это может быть полезно, например для имитиации switch-case

там функции как значения словаря. это совсем другое

Видимо, правильное решение было бы таким. Кладем лямбду в кортеж вместе с уникальным индексом, например, guid (или заворачиваем в другую лямбду, возвращающую guid + первую, что эквивалентно). Хеш от этого индекса и будет хешом лямбды. Но придется таскать индекс с собой везде

Видимо, правильное решение было бы таким. Кладем лямбду в кортеж вместе с уникальным индексом, например, guid (или заворачиваем в другую лямбду, возвращающую guid + первую, что эквивалентно). Хеш от этого индекса и будет хешом лямбды. Но придется таскать индекс с собой везде

а если через Data.Reflection?