можно вот не только матчить, но и bang-паттерн использовать

По смыслу будет то же самое в этом случае, но при этом конструктор Can в контексте уже будет не обязателен

Можно анлифтед тип использовать :)

Непонятно почему serokell не подписана тема... И почему только один блок, там же вроде два доклада должно было быть

а как это поможет против отсутствия матчинга?

надо Ясперу написать!

{-# LANGUAGE ConstraintKinds, FlexibleInstances, GADTs, MultiParamTypeClasses, QuantifiedConstraints,
             RankNTypes, TypeApplications, UndecidableInstances, UndecidableSuperClasses #-}

module BottomDict where

data Dict c = c => Dict
class    c => Hold c
instance c => Hold c

bottomDictWithoutUnsafe :: Dict c
bottomDictWithoutUnsafe = go
  where
    go :: (Hold c => c) => Dict c
    go = Dict


class CanDelete

myWithCanDelete :: (CanDelete => a) -> a
myWithCanDelete v | Dict <- bottomDictWithoutUnsafe @CanDelete = v

При большом желании можно такой CanDelete даже без ансейфа "взломать"

в партнёрах указаны!

Поможет не передавать андефайнед

такой CanDelete можно взломать тупа через instance CanDelete

QuantifiedConstraints конечно все портит

Не знаю, насколько хорошая практика так делать. Но мою проблему решит

не совсем понимаю как он работают вообще

Я не серьёзно, конечно

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

Тупо матчить норм вариант

Всем спасибо. Буду дальше матчинг использовать

бтв это все еще сложнее чем undefined)

хмм, а хаскел эстетичнее лиспов

Я кажется понял, почему хаскель хорош для парсинга... Замени стрелочки на =, а | на <|> и получится почти что код парсека какого-нибудь :D