Alexander
так.. не понял, у тебя ж разные типы вылезают?
Alexander
в первой ветке SAllIntent IntentTask, во второй SAllIntent IntentChart`
Alexander
тут только если unsafeCoerce 😏
Alexander
но это странный путь
Alexander
вообще скорее надо так:
Viacheslav
ну так я хочу чтобы результат был полиморфен по b
Alexander
data SomeIntent = SomeIntent (forall s . SAllIntent s))
Alexander
как?
Alexander
если ты его таким делаешь то это значит, что юзер может попросить конкретный b какой хочет
Alexander
а не ты его определяешь
Alexander
пути решения:
1. колдовать с сиглетонами и eqT
2. написать instance SAllIntent SIntentTask и instance SAllIntent SIntentChart
3. сделать data SomeIntent
Alexander
про первое лучше к @int_index обратиться, поидее оно должно решаться, но я такой ад не люблю и не знаю точно
Alexander
@termina1 у тебя есть пример на 1 файлик, я могу поиграться тогда локально
Alexander
о, там ещё и type synonym
Alexander
ты точно делаешь то,что надо?
Alexander
@termina1 это компиляется:
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE TypeSynonymInstances #-}
{-# LANGUAGE OverloadedStrings #-}
import Data.Aeson
import Data.Singletons
import Data.Singletons.TH
singletons [d|
data AIIntent = IntentTask | IntentChart
|]
instance FromJSON (SAIIntent 'IntentTask) where
parseJSON (String "create_task") = return SIntentTask
parseJSON _ = fail "foo"
instance FromJSON (SAIIntent 'IntentChart) where
parseJSON (String "send_task") = return SIntentChart
parseJSON _ = fail "Unknown action"
Alexander
как я и говорил, но учитывая TypeSynonymInstances я бы наверное испугался это запускать 😏
Viacheslav
короче я кажется смог
Viacheslav
через какое-то подобие зависимой пары
Alexander
я задачу до конца не знаю так что..
Viacheslav
ну это я про другое
Ilya
Alexander
@Masteroid не удобно
Alexander
доабвлять удалять сортировать и диффы больше
Alexander
а переключаться между стилями ради пасты лень
Alexander
@termina1 https://gist.github.com/qnikst/5579254757eb7d40f1e50a2e4039c60d
Alexander
смотри, там инстансы для конкретных и неизвестно какого типа
Alexander
Just IntentTask
Nothing
Nothing
Just IntentChart
Just task
Just chart
Viacheslav
ты в итоге спрятал a
Alexander
выхлоп test
Viacheslav
а она мне нужна
Alexander
что значит спрятал, инстанса с неспрятанным a быть не может
Viacheslav
ну да, поэтому я в целом кажется по другому решил эту проблему
Alexander
ну вот у меня все решается, если юзер знает a он дает конкретное, если не знает до достает `SI`и делает case
Alexander
там внутри будут 2 ветки, в каждой из которых значение определено
Alexander
но вообще эта задача не похожа на разумную
Viacheslav
задача в целом разумная
Viacheslav
просто не для хаскелла
Viacheslav
@qnikst спасибо, идею кажется понял попробую так
Alexander
для хаскела подходит любая задача
Alexander
это ж у тебя должен был быть случай где запрос определяет ответ?
Alexander
просто если сформулируешь задачу, то возможно я знаю решение неплохое без синглтонов как библиотеки, но то же по принципу
Alexander
@termina1 вообще я нашёл исходный пост и подозреваю, что проще будет как писал @int_index просто ADT
data Action where
CreateChart :: String -> String -> Action
CreateTask :: String -> Data -> String -> Action
instance FromJSON Action where
parseJSON x = object "task" $ \o ->
asum [ CreateChart <$> o .: "create_chart"
<*> (o .: "params" >>=) .: "url"
, CreateTask <$> o .: "create_task")
<*> (o .: "params" >>=) .: "date"
<*> (o .: "params" >>=) .: "something"
]
что тут есть - возвращается правильный Action с правильными параметрами
Alexander
почему так, т.к. у тебя запрос формируется из данных в одном месте и здесь гораздо проще поддерживать консистентность таким образом
Alexander
GADT и DataKinds и Singletons нужны уже если нужно связывать между собой вещи в разных местах
Alexander
впрочем часто можно обойтись и без:
data SomeAction = CreateAction CreateChart | TaskAction CreateTask
Alexander
тогда посте паттерн матчинга можно таскать с собой объект
Aleksei (astynax)
Как в TH, имея reified тип, применить оный в сигнатуре выражения, вычисляемого в шаблоне?
Aleksei (astynax)
Мне нужно специфицировать тип для полиморфной функции, которую я дёргаю в шаблоне
Aleksei (astynax)
Хотя не, я хочу от TH того, чего он не может мне дать :(
Зигохистоморфный
ну что за убожество https://medium.com/javascript-scene/javascript-monads-made-simple-7856be57bfe8
Anonymous
>медиум
>что за убожество
Anonymous
тавтология
Aleksei (astynax)
Ну так на медиум такие статьи и пишут в основном. Кроме медиума ещё на dev.to такое часто встречается
Viacheslav
Alexander
а чем она точнее?
Alexander
у тебя тут явно связан тип запроса и параметры
Viacheslav
Тем что в объекте есть поле action, от которого зависит тип поля parameters
Viacheslav
Тип запроса я заранее не знаю
Viacheslav
А тут я эту связь типа действия и типа параметров никак не отражаю
Viacheslav
Поэтому она менее точная
Vasiliy
CreateChart :: String -> String -> Action - по-моему, вполне точная связь между CreateChart и парой строк
Alexander
у меня в коде абсолютно точная связь между action и parameters
Alexander
и предположения о том, что мы знаем тип запроса нет
Viacheslav
Нет, никакой связи, она только на уровне кода выражена
Viacheslav
А на уровне типов нет
Viacheslav
То есть я из типа общего результата не могу сказать какие параметры он содержит
Alexander
ложь
Alexander
точнее не так
Alexander
из *типа* результата, ты знаешь какие параметры он содержит
Alexander
с другой стороны с + одним слоем индирекции уже можешь
Alexander
как я написал выше
Alexander
решение с дата кайнд не приносит ни единого плюса по сравнению с таким решением в этой задаче
Viacheslav
Alexander
но ты и с синглетонами это не знаешь
Alexander
максимум ты можешь вернуть это dependent pair или аналог
Alexander
это *ничем* не отличается от того, что ты вернёшь data Action = ActionTask AITask | ActionChart AICHart ; data AITask = AITask TaskParams ; data AIChart = AICHart CHartParams
Alexander
dependent pair не дает никакого плюса по сравнению с этим решением
Alexander
т.к. конструктор в ActionTask, ActionChar играет ту же роль, что и синглтон
Alexander
а пишется все на порядок проще