In Servant, the ServerError type has an Exception instance https://hackage.haskell.org/package/servant-server-0.20/docs/Servant-Server.html#t:ServerError
You might speculate that when throwing a ServerError using liftIO . throwIO in a Handler, the ServerError is automatically caught and served as a response, but it ain't so: it's treated as just another exception, and the response code is 500.
@DiazCarrete That's what I do, yes. newtype Semantic2 = MkSemantic2 { unSemantic2 :: Semantic1 }
Though sometimes I do something different, like newtype Subset = AssertSubset { asSuperset :: Superset } for things where the rep. sharing is more practical, even if the syntax isn't actually the same, like Email/Text or PhoneNumber/Int64 since construction will generally be through something like isEmail :: Text -> Either ParseFailure Email or inputPhone :: Natural -> Maybe PhoneNumber
> none of the modifying functors are the same as the type being defined, that is, we do not consider non-linear non-uniform recursion
Oh, fiddlesticks. I've been trying to use this paper for non-linear recursion. I think I might have to invent/discover instead of just mimic. I'm not as good at that! :P
Please send me your best references for non-linear non-uniform recursion since Blampied2000. Bonus points for #haskell code, but categorical abstract nonsense is fine, too.
Johann, P. and Ghani, N. (2007). Initial Algebra Semantics Is Enough! seems to simplify things (by using Kan extensions, that I still don't feel like I ""get") but doesn't actually provide an example of a non-linear non-uniform recursive type / non-linear nested type.
@counterVariable The grammar is fairly simple, but custom binary operators and precedence can mean there's actually more to keep up with when reading.
As a big fan of Haskell syntax, that is constantly playing around with new languages, are there specific "mistakes" you feel were made, that I might try to avoid in any of my future languages?
No type equalities. For any fixed a, given c :: a -> f a and si :: (forall f r. Functor f => a -> f r -> f (a -> r) provide a runtime value (a Bool) that is True is a is isomorphic to Void and False otherwise.
@BoydStephenSmithJr I thought so too, but then I read your original post again and the hypotheses were stated clearly (well, except for the type mistake 😅 which did probably change quite a lot since it turned a negative a into a positive one)
What would probably have helped me better understand the question is the context, though: how did you encounter that problem?
@glocq I'm off in my own world trying to do some type checking for a dependently-typed core (GRTT) in Haskell but avoiding GADTs (and TypeEquality constraitns) and other GHC-only features.
I'm using bound, so I have a type parameter on terms, contexts, etc. to represent variables, but I'd like to test a context to see if it is empty (as part of checking well-formedness). It's somewhere between checking to see if a bound-style term is closed and seeing if the type parameter to Context is Void.
Anyone in my #haskell (or other, I guess) circles in charge of www.cs.nott.ac.uk ? It was working yesterday, but it keeps timing out (for me) today.
I need to re-read the section of blampied-thesis.pdf on the prefix functor, and especially how it works when the non-uniform type is self-nested in interesting ways.
Trying to do a "project :: t -> f t" and keep getting hung up on the Scope-modified recursions.
Alternatively, is that thesis available elsewhere? I searched, but haven't found.
The term 'telemetry' can raise a lot of concerns, especially within the realm of #OSS. In the latest episode of #TheHaskellInterlude, Joachim Breitner and Andres Löh interview @avi_press, the CEO of @scarf_oss. Learn more about the episode here: https://haskell.foundation/podcast/47/ #Haskell
This is a great blog post on the WellTyped blog on specialization in Haskell! It's a good reminder that I (or someone) should really get around to getting rid of -fexpose-all-unfoldings and -fspecialize-agressively in the Agda codebase.
Helsinki Haskell Users Group's first book club had its conclusion meeting today with Sockets and Pipes coming to its very end. It has been a ride, one with plenty of scheduling difficulties, but I think we only fell like a month and a half from the original planned schedule and actually had a member retention rate of 100% (of members who were there in the beginning, sadly we could not quite make it 133%)!
To talk a bit about the book as a whole, I do feel like I understand Monad Transformers a lot better now though I'll still need to reread the sections introducing them I am sure. ReaderT especially was something I could see was colossally handy, but given it was in the second to last chapter we were already quite deep with trying to understand everything else so the true utility of it remains somewhat hazy despite the quality of the chapter itself which felt higher than those surrounding it. The habit of reading RFCs and attempting to match the spec in the types one writes is also one I should include in my general workflow, though that is probably a no-brainer for most. It just wasn't a thing in my previous work, so bear with me while I call it a novel concept!
I'm still working on my personal project, but getting nix-build working seems difficult. I'll just have to bring it up in the next main group Office Hours meetup I suppose, lest I never get this show on the road!