и надо имплементировать немного разные вещи в зависимости от ErrorCaching

то есть это можно переделать на data family наверное

Теперь второй пункт, про статический выбор f1 или f2. Делать это в compile-time гарантированно невозможно, но если сделать класс, то со включенными оптимизациями скорее всего сработает инлайнинг/специализация. При условии, что f не рекурсивная

круто

а почему невозможно?

Потому что создав функцию с типом X x -> R x ты даешь возможность вызывающему определить x в рантайме.

А если твое рассуждение полагается на то, что никто этого делать просто не станет, то это уже оптимизация, а на них полагаться 100% нельзя.

опа, а вот это интересно

класс я конечно могу сделать, но сейчас в коде (для динамической реализации) есть вещи типа case errorCaching of NoErrorCaching -> blabla TimedCaching _ -> blabla2 и они раскиданы в разных местах, так что делать из этого класс ну как-то совсем стремно

но либо так либо GADT, получается

Ну если ты делаешь case errorCaching of, то это все равно рантайм-диспатчеризация

да, и вот я от нее хочу избавиться, потому что реально динамики там не будет никогда

это compile-type параметр по сути

Если это полностью статический параметр и ты не делаешь по нему индукции, то тогда похоже на юзкейс для Backpack

охЪ

тогда уж GADT

Потому что создав функцию с типом X x -> R x ты даешь возможность вызывающему определить x в рантайме.

спасибо, у меня только вопрос остался, как так x может определяться в рантайме?

Если экзистенциальную переменную распаковать. data SomeSX = forall x. SomeSX (SX x) main = do s <- getLine SomeSX (_ :: SX x) <- return $ if s == "hello" then SomeSX SX_A else SomeSX SX_B -- here 'x' is a type variable that -- was determined at runtime -- by whether the user has -- entered "hello" or something else

а! действительно

круто

как выше если множество открыто, если закрыто, то можно и как ты написал

data Request a where R1 :: x1 -> Request x1 R2 :: x2 -> Request x2 foo :: Request x -> x foo (R1 y) = ... foo (R2 y) = ...

если добавить к foo INLINE, или даже Rules то с ненулевым шансом будет статически разрулено, но гарантий нет

https://mobile.twitter.com/InputOutputHK/status/900275171793272834 s/provably/probably/ (trollface.jpg)

https://mobile.twitter.com/InputOutputHK/status/900275171793272834 s/provably/probably/ (trollface.jpg)

реально доказано?

я не читал, не знаю, ребята из Serokel говорят, что да

я не читал, не знаю, ребята из Serokel говорят, что да

это круто тогда

data Request a where R1 :: x1 -> Request x1 R2 :: x2 -> Request x2 foo :: Request x -> x foo (R1 y) = ... foo (R2 y) = ...

да, попробую как-нибудь так поиграться

если бы было доказано, написали бы "proved"

а "provable" — это "в теории можно доказать, но мы не смогли"

а "provable" — это "в теории можно доказать, но мы не смогли"

списибо

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

да

я тоже так понял

Check out @cyberglot's Tweet: https://twitter.com/cyberglot/status/900418418167492612?s=09

Check out @cyberglot's Tweet: https://twitter.com/cyberglot/status/900418418167492612?s=09

idris какой-то расплывчатый

ну так не в фокусе

на самом деле картинка не совсем верная, более верная картинка должна быть на грани обвинения в педофилии, так она будет лучше отражать состояние вещей

то есть idris это на грани педофилии?

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

ну не ребёнок конечно уже, но все ещё не хм.. как это сказать, в общем вы поняли

ах, теперь ясно о чём

не в возрасте согласия, штоле?

:)

"There is a function which directly answers the initial question, namely, unsafePerformIO . It is however not intended for conveniently getting rid of the IO constructor. It must only be used to wrap IO functions that behave like non-IO functions" что может быть IO like non-IO?

генерация top-level мутабельной переменной

чтение из окружения

Ой мда

Как раз это весьма questionable практики.

я не говорю, что так делать хорошо

но это единственный способ сделать так, если оно нужно

а бывает нужно

+ чтение из памяти, если доказано, data dependency достаточно

> behave like non-IO functions Вопрос был так проставлен. Самый простой пример -- какие-нибудь вызовы FFI-методов в библиотеках. Еще классический пример -- мемоизацию добавить через мутабельную структуру.

Или использование рандомности в детерменированных алгоритмах (случайный выбор pivot для quicksort, например)

да, это примеры получше

впрочем для FFI unsafePerformIO не нужно, можно сразу чистую привязку генерировать

если мне память не изменяет

обожаю этот чат :3

впрочем unsafePerformIO делает гораздо больше, чем стирает IO

она ещё локи делает чтобы действие было выполнено не более 1 раза

есть unsafeDupablePerformIO без локов, достаточно безопасное, но действие может более одного раза выполнится, если 2 трада решили использовать значение примерно одновременно

а можно просто взять с паттерн-матчнуть по IO, (или inlineIO) но это очень опасная штука

там нету data-dependency и учитывая float-out могут получаться смешные вещи

типа алиасинг все singleton bytestrings

как было когда-то

а напомните, в какой-то библиотеке был смешной синоним для unsafeInterleaveIO

что-то на тему "адскиОпасноеIO"

bytestring

собственно то, что я описал это оно и есть

да, accursedUnutterablePerformIO

http://hackage.haskell.org/package/bytestring-0.10.8.2/docs/src/Data.ByteString.Internal.html#line-564

лавкрафтовщина

@qnikst Привет. А запись твоего и остальных докладов будет?)

маловероятно, нужно организатором спрашивать

ну тогда хоть потом слайдами поделишься?)

да

надо бы их сделать

до конца

от начала