quarter
@quarter has joined the channel
anythingToString :: forall a. a -> String
Data.Convertible.Convertible クラス、別パッケージに分離してほしいなReaderT より ImplicitParams 使えよって記事と ImplicitParams 使うと危ないって記事が両方載ってるっぽくて興味深いですね :smirk:ImplicitParams 使うと危ないぞ」という記事 https://chrisdone.com/posts/whats-wrong-with-implicitparams/?param
ReaderT でいうところの param <- ask をさしているのかそれともよそで ask した結果の param を参照しているのか、型推論した結果からしか分からないところにあるみたいですね。listDirectory 関数が返すリストの順番に依存したコードを書くと、ある日突然何の脈絡もなく順番が変わってしまってバグり出す、という恐怖体験が続きました... :fearful:let ... in って面倒くさいなぁという気持ちになり、これまでの鬱憤もあってこんな乱暴なことをいってしまった :cold_sweat: んですが、 https://twitter.com/igrep/status/1381803450321661953let ... in を使いますか？do の let で実は実現できるけど、やっぱり違和感ありますかね... :disappointed:aes128gcmEncrypt :: Key -> (Nonce -> PlainText -> AddDat -> [CipherText])
aes128gcmEncrypt (Key key) =
let aes = throwCryptoError (cipherInit key) :: AES128
in \(Nonce nonce) plaintext (AddDat ad) ->
let aead = throwCryptoError $ aeadInit AEAD_GCM aes nonce
(AuthTag tag0, ciphertext) = aeadSimpleEncrypt aead ad plaintext 16
tag = Byte.convert tag0
in [ciphertext,tag]let と in の行頭をそろえちゃいけないと思っていたんですが（本件の元となった質問 https://teratail.com/questions/332942?rss でも質問者が間違えてそろえてしまってハマっています）、そろえていい場合もあるんですね... :cold_sweat: （むしろそろえるのが普通なのか）do の中で let .. in を使うのが鬼門なのか...let foo = bar in ...
let foo = bar in foo + 1
try が非同期例外を捕捉しなくて悩んでいたんだけど、非同期例外が連続して2回飛んでた。。。evacuate1 (p=p@entry=0x42005d49a8) at rts/sm/Evac.c:839 839 rts/sm/Evac.c: No such file or directory.