часть переходов примитивные, а часть сами представляют собой автоматы. Нужно бегать по состояниям и, в некоторых случаях, просматривать подробнее, что за автоматы на переходе. Пока придумал такое решение: хранить на переходах идентификаторы и отдельно Map ID -> Automata. Но тут не очень красиво то, что Map и ID-шники на переходах вообще никак не связаны и поэтому каждый раз при lookup приходится бросать исключение, если не нашлось. Есть ли какой-нибудь сделать так, чтобы на уровне типов было ясно, что исключений тут не будет на самом деле? Понимаю, что, наверное, из соображений простоты и эффективности всё равно вряд ли что-то лучше Map придумаешь, но хотя бы просто в образовательных целях
на уровне типов исключений в любом случае нет
можно к Map применить (!), чтобы избавиться от Maybe, если вы уверены, что ключ всегда в словаре
можно на уровне типов доказать, что ключ в каком-то множестве, но если это множество формируется во время исполнения, то доказать это будет весьма тяжело
о, как-то не заметил такую полезную функцию. Естественно, сам написал подобное, но лучше стандартным пользоваться, конечно
она невразумительное исключение кидает, если программист всё-таки ошибся, и ключа нет, так что своё часто пишут
ну, я так и думал, на самом деле, что можно, но очень сложно :) спасибо
а, ну это да можно написать что-то вроде "несуществующий ID автомата", а не "ключ не найден"
и в линзах есть похожая штука (^?!)
Да, HasCallStack — то, что нужно. Только вот добавлять его, видимо, нужно не к вызывающей функции, а к самому (!). В общем, так заработало: (!) :: (HasCallStack, Ord k) => Map k a -> k -> a m ! k = case M.lookup k m of Nothing -> error "(!) given key is not an element in the map" Just a -> a странно, почему тогда бы HasCallStack в Data.Map не прописать. Это какие-то ограничения на использование накладывает?
HasCallStack: Pros: Can be used on all platforms; provides precise backtraces Cons: Requires manual modification of the source program; runtime overhead
Вообще есть вот такой пропосал, который пилится https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exception-backtraces.rst
в данном случае мешает runtime overhead, да?
На самом деле хз, можно вот это почитать https://gitlab.haskell.org/ghc/ghc/-/issues/17040 там как раз предлагали добавить HassCallStack для всех частичных функций в base
Обсуждают сегодня