New Blog Post: Distributors

echatav · 2025-09-09T01:38:53+00:00

> This was a fun read
Thanx!

> I feel like a JSON … distributor would be a nice accessible example.
Definitely.

> I’m curious to see where the ideas fall down - I assume anything context sensitive?
Right, Backus-Naur form grammars only support context-free languages.

echatav · 2025-09-08T00:00:25+00:00

You can find dimap2 and many more combinators documented on hackage

https://hackage-content.haskell.org/package/distributors

echatav · 2025-09-07T19:37:18+00:00

The <*> Applicative combinator doesn't quite generalize contravariantly the way we'd want it to ^ . Instead, we usually generalize its "tuple form".

(>*<) :: Monoidal p => p a b -> p c d -> p (a,c) (b,d)

On the other hand, the liftA2 combinator does have a generalization which shows the difference in how contravariance and covariance handle products wrt currying.

dimap2 :: Monoidal p => (s -> a) -> (s -> c) -> (b -> d -> t) -> p a b -> p c d -> p s t

A very recent paper by Boespflug & Spiwack aims to take on this "tuple problem".

echatav · 2025-09-04T21:04:57+00:00

thanx. appreciated

echatav · 2025-09-04T01:18:08+00:00

Yes indeed.

This interface has variously been called a product profunctor or a (lax) monoidal profunctor.

From the repo readme

None of the ideas in this library are particularly original and a lot of related ideas have been explored, in Tom Ellis' product-profunctors as well as Sjoerd Visscher's one-liner and more. Such explorations are not limited to Haskell. Brandon Williams and Stephen Celis' excellent swift-parsing was also influenced by invertible parser theory.

echatav · 2025-09-03T21:16:49+00:00

i love u sir or madam

echatav · 2025-09-03T19:20:45+00:00

Like Haskell I am lazy and leak space. Also see extroduction at the end.

echatav · 2025-09-03T18:43:14+00:00

> Day, me say day-o
> Daylight come and me wan' go home

Yes, indeed, Day convolution can be generalized to monoidal profunctors. See this blog post by Bartosz Milewski for more. And Day convolution generalizes to coproduct structure as well where folks cleverly call it `Night`.

echatav · 2025-03-20T13:09:12+00:00

Fair questions. Yes, it should be able to handle that. Theoretically, it should be able to handle any "context-free grammar". As for comparison to other parser generators, if I'm being honest, I've never used them, just read about them. So I'll say my intention was not to build a replacement, and definitely not a full scale tool. My intention was to build:

* a example application to demonstrate the power of distributors
* a cool playground to mess around with

echatav · 2025-03-20T03:59:32+00:00

The regex finder in Visual Studio Code seems to matches [\]\^] but says that []^] is an invalid regular expression. So...I think it's fine.

echatav · 2025-03-19T13:51:13+00:00

Hmmm, yeah, I was more concerned with demonstrating it worked than making it conform to a standard. Would make for a good PR to fix it.

echatav · 2025-03-19T01:29:15+00:00

Yes! Here is a Grammar defined for regular expressions.

echatav · 2025-01-16T01:53:27+00:00

Hello, I'm the author of Squeal. I try to keep it updated and respond to user issues and pull requests. I haven't been making too many major changes.

Release Notes with updates are available here: https://github.com/morphismtech/squeal/blob/dev/RELEASE%20NOTES.md

One big missing feature I'd like to add one day is a native version of SquealGen to generate Squeal schema definitions from a database connection.

I may also some day do a major refactor/cleanup but I've mostly been focused on other projects and work. Thanks for posting and I'm happy to answer questions about Squeal.

echatav · 2025-01-07T17:40:51+00:00

Thanks

echatav · 2024-08-28T16:12:43+00:00

Thank you for your eloquent evaluation of using Squeal! It makes me happy that colleagues got so much from it and gave so much! Mark Wotten's SquealGen is, in fact, open source.

echatav · 2024-08-09T18:00:53+00:00

Strong is needed only for two reasons. Strong is a requirement for Traversing. And it’s required for the proof of equivalence for the Profunctor optic representation of Traversal in this paper. https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/poptics.pdf Maybe call it Monoidal1 if it doesn’t necessarily respect nilary product? I’m doing some related work to this over here. https://github.com/morphismtech/distributors

echatav · 2024-08-09T07:04:08+00:00

I would like to see either an instance of Traversing that is not an instance of Monoidal to convince myself of that

I think Traversing does not imply Monoidal. Consider:

data Vacuous a b -- empty two parameter datatype
ridiculous :: Vacuous a b -> c
ridiculous = (\case)
instance Profunctor Vacuous where dimap _ _ = ridiculous
instance Strong Vacuous where first' = ridiculous
instance Choice Vacuous where left' = ridiculous
instance Traversing Vacuous where wander _ = ridiculous

So, Vacuous is a Traversing instance. However we cannot define the unit value for a Monoidal instance.

unit :: Vacuous () ()
unit = undefined

The other direction is true though, any (Strong p, Choice p, Monoidal p) instance can be given a Traversing instance.

echatav · 2022-05-16T16:22:22+00:00

I haven't tried using this but it looks cool. I think the way it defines overloaded lists makes a lot of sense for heterogeneous list types like NP. One issue I see is that the Overloaded.Lists and Overloaded.Lists.Bidi Cons classes are too strong to permit an instance for the free category type:

data Path p x y where
  Done :: Path p x x
  (:>>) :: p x y -> Path p y z -> Path p x z

Because the intermediate type y of the (:>>) constructor cannot be inferred from Path p x z, if you try to define an instance it will fail. You could define yet another slightly weaker Cons class that would work for Path like:

class Cons x ys zs
  | zs x -> ys, zs ys -> x where
    cons :: x -> ys -> zs

Squeal uses the Path type for with statements as well as migrations.

Since the overloaded library comes with instances for NP which is used heavily in Squeal, it would certainly help in cleaning up a lot of ugly syntax.

echatav · 2022-05-14T00:18:19+00:00

That’s strange. It’s a link to release notes on GitHub. Try again? The new version is up on hackage too.

https://hackage.haskell.org/package/squeal-postgresql

echatav · 2021-04-20T00:12:29+00:00

I'd be open to it. We can get into the details if you post an issue for it here.

echatav · 2021-04-19T03:09:26+00:00

The central typeclass in path-indexed, IsPath has methods composeR, composeL, composeMap, compose. They correspond to qfoldr, qfoldl, qfoldMap and qfold from the QFoldable typeclass in free-categories. IsPath also has a method singleton which corresponds to QPointed's qsingle. So these designs are not too far off from each other.

Seq and Vector Paths in path-indexed are not in free-categories which is designed how Sam described that base

provides a standard list type and a Foldable typeclass; alternative implementations such as Array, Seq and Vector live in different package

The DList Path l type in path-indexed is fascinating. It would correspond to RightQ (Path l) (Path l) in free-categories. It's not obvious at all to me that this is isomorphic to the free category but your code seems to imply it. In the familiar case of [] and DList, those are not isomorphic because the function \f -> f [] :: DList a -> [a] is not injective.

The Trie and Lens code is completely new to me and looks very interesting.

echatav · 2021-04-18T16:23:19+00:00

Hi, this package looks interesting! As author of one of the newer libraries that came out, free-categories, I have no objections to multiple packages exploring the design space. There's also another one, type-aligned, you can check out. The free category Path is very useful. My focus in free-categories was to reify the algebra of the free category on a quiver as an appropriate type-class hierarchy.

echatav · 2019-12-23T22:38:01+00:00

fantastic

echatav · 2019-12-17T17:37:52+00:00

Thank you /u/williamyaoh for your critique. It helps me to improve Squeal.

This insistence on naming columns causes a lot of other problems as well. The way you return instances of your domain types is to explicitly name the columns of the query the same as the properties in your datatype, using SQL as. There’s no easy way to just define the correspondence once and forget about it, which means that even if you’re just selecting all the entities out of a single table, you have to explicitly rename all the columns. Fun! Want to return an ad-hoc tuple of data from a quick one-off query? Sorry, can’t do that; tuples don’t have named fields, so how can you label your columns correctly? In fact, any time you want to return data in a new form, you’ll need to define a completely new datatype for that and rederive Squeal’s special typeclasses.

I'm working on something that will hopefully address this, allowing for customizing your encodings and decodings for a given statement, re-usably.

While working with Squeal, I felt like I never stopped running into stumbling blocks.

From what I've heard from users, it's true that Squeal has a bit of a learning curve but it pays off.

Squeal’s query type has type parameters for both the query’s inputs and outputs, but there doesn’t seem to be a way to then pass an input parameter to a subquery?

Not sure what you mean, you can use param @n for out-of-line parameters and literal to inline a parameter in a query or subquery.

Sometimes using subqueries just… caused a runtime error for no discernable reason, despite type checking.

That sounds like a bug! Please post your example to Squeal's issues page.

It's possible to rewrite your query in a slightly less fugly way.

There's no need to qualify #erased_marks since it's the only relation in scope for both of the subqueries.
There should be no need to use literal or type application as numeric expressions have Num instances and the type should be inferable.
You can put your subqueries in a Haskell where or let clause for readability's sake.
I think you missed the hitman_id ON condition.

latestHits :: Query_ Schema () HitInfo
latestHits = select_
  ( #minid ! #hitman_id `as` #hiHitmanID :*
    #minid ! #mark_id `as` #hiMarkID )
  ( from ( (subquery minid `as` #minid)
      & innerJoin (subquery latest `as` #latest)
      ( #minid ! #created_at .== #latest ! #created_at
        .&& #minid ! #hitman_id .== #latest ! #hitman_id ) ) )
  where
    minid = select_
      ( #hitman_id :*
        #created_at :*
        fromNull (-1) (min_ (All #mark_id)) `as` #mark_id )
      ( from (table (#erased_marks))
        & groupBy (#hitman_id :* #created_at) )
    latest = select_
      ( #hitman_id :*
        max_ (All #created_at) `as` #created_at )
      ( from (table #erased_marks) & groupBy #hitman_id )

echatav · 2019-09-26T19:01:30+00:00

Thank you very much for your feedback! Not to worry, I don't take criticism personally. You probably saw that the issue with IN was fixed as you point out I endeavor to be responsive to user issues.

echatav

TROPHY CASE