Здравствуйте, thesz, Вы писали:
T>Я не про разбор говорю, а про отображение обратно в исходный синтаксис для отчёта пользователю.
Даже если у тебя есть какие-то проблемы преобразования AST в текст, то всегда есть положение ветвей AST в коде и ты можешь просто выделить подстроку и поместить ее в сообщение об ошибке.
В общем, надуманная проблема.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
T>>Я не про разбор говорю, а про отображение обратно в исходный синтаксис для отчёта пользователю. Z>А не проще печатать исходную строку? — компиляторы обычно так и делают.
Сообщение об ошибке выводится в терминах внутреннего представления, а строка имеет внешний синтаксис.
Пользователю придётся переводить.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Я не про разбор говорю, а про отображение обратно в исходный синтаксис для отчёта пользователю. VD>Даже если у тебя есть какие-то проблемы преобразования AST в текст, то всегда есть положение ветвей AST в коде и ты можешь просто выделить подстроку и поместить ее в сообщение об ошибке.
У нас есть исходная подстрока "здесь мы сравниваем входной список с образцом, первый элемент которого цифра один, второй — цифра два и третий и последний — цифра три" и наше внутреннее представление (123:[]))). Ошибка связана с цифрой 2, считается, что она не может туда попасть, поскольку две другие цифры нечётные.
Можно показать исходную строку, внутреннее представление и показать ошибку во внутреннем представлении. Но это заставит пользователя переводить ошибку в термины программы.
VD>В общем, надуманная проблема.
сообщения об ошибках типов в Хаскеле очень сложны (хотя и не так сложны, как в C++).
Поэтому для Хелиума был разработан специальный алгоритм вывода типов путём поиска наименьшего пути по графу ограничений на типы, и вот по нему строится сообщение об оишбке.
И ещё. Правила вывода типов с классами типов специально были записаны в конкретном синтаксисе Хаскеля, а не в терминах гораздо более простого Core, как раз для того, чтобы давать внятные сообщения об ошибках.
Здравствуйте, thesz, Вы писали:
T>У нас есть исходная подстрока "здесь мы сравниваем входной список с образцом, первый элемент которого цифра один, второй — цифра два и третий и последний — цифра три" и наше внутреннее представление (123:[]))). Ошибка связана с цифрой 2, считается, что она не может туда попасть, поскольку две другие цифры нечётные.
T>Можно показать исходную строку, внутреннее представление и показать ошибку во внутреннем представлении. Но это заставит пользователя переводить ошибку в термины программы.
У тебя будет местоположение всего списка и местоположение места с ошибкой (двойки). Ты сформируешь сообщение в ктором говорится, что "в списки 'подстрока всего списка из исходного файла' недопустимо значение 2 так как ....". При этом ты установишь местоположение (Location) на на двойку.
VD>>В общем, надуманная проблема.
T>Товарищи из Helium с тобой не согласятся.
Мне честно говоря все равно, что думают там разные товарищи, но этот товарищь вообще вряд ли может высказывать свое мнение, так как он существо не одухотворенное .
T>сообщения об ошибках типов в Хаскеле очень сложны (хотя и не так сложны, как в C++).
Я бы даже скзал, что они сложнее С++-ных, но это уже отдельный разговор.
Пробелмы сообщений в Хаскеле совершенно очевидны. Они проистекают из его подсистемы вывода типов и его системы типов. К парсингу это отношения не имеет.
T>Поэтому для Хелиума был разработан специальный алгоритм вывода типов путём поиска наименьшего пути по графу ограничений на типы, и вот по нему строится сообщение об оишбке.
Молодцы. Идут в правильном направлении. Я бы на их месте еще бы ввел обязательную аннотацию типов для публичных функций и типов.
T>И ещё. Правила вывода типов с классами типов специально были записаны в конкретном синтаксисе Хаскеля, а не в терминах гораздо более простого Core, как раз для того, чтобы давать внятные сообщения об ошибках.
Тоже замечательно.
T>См. здесь http://homepages.inf.ed.ac.uk/wadler/topics/type-classes.html "Type classes in Haskell": "In contrast to an other work on type classes, the rules presented here relate directly to user programs."
T>Так что кому "надуманная проблема", а кому "критерий дизайна".
Надумана та проблема, которую озвучиваешь ты, а не проблема вывода сообщений об ошибках в Хаскеле.
PEG с точки зрения организации сообщений об ошибках парсинга ничем не отличается от рукописного парсера.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>У тебя будет местоположение всего списка и местоположение места с ошибкой (двойки). Ты сформируешь сообщение в ктором говорится, что "в списки 'подстрока всего списка из исходного файла' недопустимо значение 2 так как ....". При этом ты установишь местоположение (Location) на на двойку.
Паллиативное решение. Но, судя по всему, хорошего так и нет.
T>>Поэтому для Хелиума был разработан специальный алгоритм вывода типов путём поиска наименьшего пути по графу ограничений на типы, и вот по нему строится сообщение об оишбке. VD>Молодцы. Идут в правильном направлении. Я бы на их месте еще бы ввел обязательную аннотацию типов для публичных функций и типов.
Он выдаёт предупреждения об их отсутствии и сразу же показывает тип, который надо подставить.
T>>См. здесь http://homepages.inf.ed.ac.uk/wadler/topics/type-classes.html "Type classes in Haskell": "In contrast to an other work on type classes, the rules presented here relate directly to user programs." T>>Так что кому "надуманная проблема", а кому "критерий дизайна". VD>Надумана та проблема, которую озвучиваешь ты, а не проблема вывода сообщений об ошибках в Хаскеле. VD>PEG с точки зрения организации сообщений об ошибках парсинга ничем не отличается от рукописного парсера.
За исключением того, что его правила могут меняться, чего и хочется. Здесь у нас список [commaList], а здесь — список пар, где вместо запятой стрелка.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
VD>>У тебя будет местоположение всего списка и местоположение места с ошибкой (двойки). Ты сформируешь сообщение в ктором говорится, что "в списки 'подстрока всего списка из исходного файла' недопустимо значение 2 так как ....". При этом ты установишь местоположение (Location) на на двойку.
T>Паллиативное решение. Но, судя по всему, хорошего так и нет.
А что в нем плохого?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
T>>Я не про разбор говорю, а про отображение обратно в исходный синтаксис для отчёта пользователю. VD>И причем тут PEG? Пег — это формализм парсинга. Замена CFG.
Если мы его используем для "расширения синтаксиса" (как mixfix), то весьма причем.
(ушёл ставить себе camlp4 поиграться с расширениями синтаксиса. может, они успели что придумать.)
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
2
.