Tomorrow, 2023-12-20, at 1930 UTC, Edsko and I will do the final #Haskell Unfolder episode of the year 2023. This time, we're going to take a bit more time and talk about "circular programs", i.e., programs that depend on their own result.
I feel like although for nerds like me putting more types in a language is a cool thing, what would be much more important as a topic of research, in practise, is reducing the syntactic overhead of type systems. I recently heard so many complaints about this, I feel like we’re not there yet; I do agree. #haskell
@mangoiv Interesting. I feel that you can probably get a similar level of conciseness if you're doing everything structurally and rely on inference everywhere, but I wouldn't want that? To me, it often helps to just write down types in order to understand a problem, or understand it better. If you want to introduce nominal types, then Haskell syntax already seems nearly optimal. I think these are extra lines well spent. If you make any of that implicit, then the benefit is gone.
@kosmikus the issue I see here is that for “trivial” things, the overhead is not justified; I’m not talking about the cases where types do actually help solving an issue (and I’m of the strong opinion, they do solve problems!).
To refer to the example again; think about writing Python in script-ish settings; most times you don’t need any types to oversee the situation, in these cases you probably don’t want to deal with their overhead, either; this starts by having to use fromIntegral, T.(un)pack, explicit lifting into monadic contexts, dealing with ambiguous types, and so on.
Another example is effect systems for that matter, every time you just “propagate” constraints, you end up with a flat record of effects that are mostly just syntactical noise, there’s no actual benefit in them, you’re just wrangling with the compiler. (Surely this is also a matter of design, think small functions with many effects and large functions with almost no effects, but this is something that exhibits in practice)
Time for my #introduction to the Fediverse! :masto_love:
Clash is an open source functional hardware description language built on #Haskell.
The Clash compiler allows you to use Haskell features like its strong and powerful typesystem as well as use existing Haskell code and libraries in your #FPGA and #ASIC designs! You can test your designs right inside the REPL, simulate it alongside other Haskell code or output #VHDL / #Verilog / #SystemVerilog code for synthesis.
Just ~90 minutes until the start of episode 16 of The #Haskell Unfolder. This time about some Haskell history (the Applicative Monad Proposal), a recent Mastodon thread by @MartinEscardo , and about DerivingVia!
You explained how to make the new world to accommodate the old world.
But what if back in 2015 people wanted to use Classical Monads with Functor and Applicative, without changing the ghc library for monads/applicative/functor?
Could this new technology you discussed today be used for that, if it were available at that time? So that we could still have the classical definition of monad today and at the same time please people who wanted to make the change?
@MartinEscardo I am dreaming of a time when we don't have superclasses anymore in the way we currently do and just have "rules" that state "we can create an X instance out of ..." which are getting invoked. Unfortunately, it is still a dream, because practical concerns remain: there's an implementation aspect of superclasses (they're just projected out of the dictionary, so you know they're cheap to compute), and there's a constraint simplification aspect, because you can just write Ord a rather than having to write Eq a, Ord a, because you knowOrd a really implies Eq a in all cases. I don't think these things are insurmountable, but I don't have a research job these days, so I don't have a whole lot of time to work on it.
So to answer your actual question: DerivingVia could have used by saying "here's a quick way to give you Functor / Applicative instances for a type that already has a Monad instance such that they're compatible, even without making Applicative a superclass". I think that e.g. for me, that would probably have been good enough. But as superclasses are somewhat special (see above), the discussion in principle still remains, and we'll probably have more such discussions in the future (selective applicative functors were mentioned in the chat, but there are other examples).
a #haskell question. Is there an active community around here?
I can understand how typeclasses are implemented for typeclass functions that have the implementation type as first argument (such as (>>=) in the Monad typeclass).
But for signatures like return (a -> m a) is there some special magic happening?
I currently assume its compile time type inference from return being used in a context of (>>=), as >>= expects a function (a -> m b)
@kephalos Due to the type signature of >>=, all the m type variables have to be the same in your example. The type checker then has to unify m a (from the argument of >>=) with Just 1 :: Maybe Integer and concludes m = Maybe.
@johnny > drop the transaction if we’ve had no luck for x seconds
That would be registerDelay. It’s in IO, but it gives you a TVar, that will flip to True when the time comes. You can readTVar it to decide retry or bail.
Also, you can wrap pretty much anything in timeout (in IO proper).
Anyone want to guess how many errors this code generates:
{-# LANGUAGE DerivingVia #-}
module T where
newtype OrdList1 a = OrdList1 [a]
deriving (Functor, Foldable, Traversable) via []
newtype OrdList2 a = OrdList2 [a]
deriving (Functor, Foldable, Traversable) via Maybe
Any cool open source #haskell projects? I would like to start taking a look about what a real project looks like. I know about pandoc (which I will check out), but is there something maybe related to databases or data streaming of sorts?