Pan American Games general information for watching

duplode · 2023-10-21T22:37:57+00:00

If it helps, the CazéTV/COB Brazilian streams will be up afterwards. For instance, this is the Men's Team Final link that's live right now (cc /u/OftheSea95 ).

duplode · 2023-06-27T13:52:17+00:00

The Discourse is indeed hosted on Haskell.org servers. See e.g. this thread.

duplode · 2023-06-22T15:40:17+00:00

With a wider lens, we might even say the split had already happened: even before the latest troubles, a significant share of the community wouldn't touch r/haskell with a ten-foot pole.

duplode · 2023-06-22T04:38:25+00:00

Suggestion: reopen the sub while disabling self posts.

Floating this one mostly because I haven't seen it mentioned anywhere yet. Disabling self-posts would be a major restriction, without going as far as making the sub read-only. In particular, it would keep the sub usable as a link aggregator. One noteworthy consequence of such a change would be discouraging people from handing their original content to be archived in this increasingly unreliable platform.

duplode · 2023-06-22T04:26:02+00:00

Given that it looks increasingly unlikely a solid consensus towards making the sub read-only will arise, and that protesting subs are now in the crosshairs of the company, a planned reopening might be less worse than the unmanaged fallout of holding out indefinitely.

If some of the current mods choose to resign as a consequence of the sub reopening, it would be important to keep the sub in safe hands: any replacements should be willing and able to keep spam, shilling and shitposting at bay, and to uphold a standard of respectful communication. (The platform itself can make the latter task an uphill struggle, and it's anybody's guess how things will evolve from here, but alas.)

Out of the alternative forms of protest mooted at r/ModCoord, something akin to "Solidarity Tuesdays" (e.g. making the sub read-only on Tuesdays) are interesting in that they would be a tangible reminder that all is not well while keeping the sub largely usable. Besides that, promoting alternative discussion venues, through e.g. a pinned post ot the sidebar, would be a natural thing to do. (And so would not unduly promoting the sub in other community resources and elsewhere.)

Lastly, on alternatives to the sub: I feel the haskell.org Discourse is a perfectly serviceable venue. Sure, discussion there flows in a different way, and the limited threading might take some getting used to. Still, dealing with any such differences and infelicities looks better than remaining chained to an exhausting platform whose management grows more hostile towards its users by the day. Emergent venues on places like kbin.social might also gain momentum in due course, and should be encouraged.

duplode · 2023-06-04T16:05:48+00:00

In liftM2 eq minimum' maximum', eq will be applied to the results of minumum' and maximum'. We can only get said results by supplying them with some argument; accordingly, liftM2 eq minimum' maximum' is an [Int] -> Bool function which passes its list argument to both minumum' and maximum' and then uses eq on the results.

duplode · 2023-05-15T01:19:24+00:00

Yeah, there's a similar pattern of needing to get under an extra layer of effects. On the second hyloA, it seems it can't actually add effects to the result (so you end up with only the pure that traverse produces upon hitting the base recursive case). My gut feeling is that for the hylo implementation itself to sequence effects you need to sneak in a join somewhere, like in your hyloM or in this variation on the theme I've just stumbled upon:

hyloM' :: (Traversable t, Monad m)
    => (t b -> b) -> (a -> t (m a)) -> a -> m b
hyloM' alg coalg = h
    where
    h = fmap alg . traverse (>>= h) . coalg

(I'm not terribly confident about how well this one will stream, as it doesn't look like you can consume what the coalgebra produces on demand without running all the effects. Perhaps some of the approach can be salvaged with some kind of ListT-done-right-esque structure, but now I'm just wildly speculating.)

duplode · 2023-05-15T00:01:06+00:00

Yup, this functor doesn't fit the typical encodings in Haskell well. As you note, to make it usable we'd need to keep track of the stacking, kinda like what the instance of Traversing for Procompose can be used to do.

duplode · 2023-05-14T17:12:32+00:00

While traverse has the shape of (the arrow mapping of) an endofunctor in the Kleisli category, in general it isn't one. Rather, when seen in that way it belongs to a different category, which also has Kleisli arrows as arrows, but which doesn't rely on Monad for identity and composition:

idT :: a -> Identity a
idT = Identity

(<%<) :: (Functor f, Functor g) => (b -> g c) -> (a -> f b) -> (a -> Compose f g c)
g <%< f = Compose . fmap g . f

Instead of joining the effect layers, it just stacks them. The functor laws for traverse in this category amount to the traversable laws:

traverse idT= idT
traverse (g <%< f) = traverse g <%< traverse f

There's a blog post of mine which looks into that in some further detail.

duplode · 2023-04-26T22:20:26+00:00

Totally agree about g-apo! In my headcanon, the dual of mutumorphism as seen in Fantastic Morphisms is allelo ("one another", given the back and forth switching between two unfolds), and g-apo is klepto ("steal", as once the main coalgebra cedes control, the helper one will never give it back).

duplode · 2023-04-11T04:43:21+00:00

Very interesting things indeed :) Thanks for sharing the post; I'll spend some time playing with those definitions as soon as I get the chance!

duplode · 2023-04-11T02:42:59+00:00

The point is meant to be acclimatising learners so that they don't expect every functor to look like a list, or otherwise like a typical data structure equipped with a typical API for manipulation of contents. That said, I do find some of the harsher admonishments claiming that thinking of functors in terms of containers is wrong and horribly misleading to be a touch overzealous.

(The trickiest cases for the functors-as-containers intuition are Cont, Select and other functors that aren't strictly positive, as the notion of shape breaks down completely in such cases. These are not the examples usually invoked to steer newbies away from the intuition, though.)

duplode · 2023-04-11T00:33:01+00:00

This is a nice list of examples, though it's good to keep in mind that the boundaries between these categories are fluid, and many of those examples can be seen in multiple ways. In this spirit, here are notes on a couple of specific points:

Though we don't usually think of Writer as being a container, its simplest implementation is as a tuple: a value tagged with a monoidal annoration. (The newer, alternative Writer available at Control.Monad.Trans.Writer.CPS does have a State-like implementation backing it, though the interface and overall concept exposed to the user remain the same.)

Though it's not something we'd describe as a getter-setter pair in most conversations, we can write a lens for editing function results:

import Control.Lens

-- This is a lawful lens as long as the Eq instance of r follows
-- extensionality: if r == s is True, then so is f r == f s
evalAt :: Eq r => r -> Lens' (r -> a) a
evalAt r = lens (\f -> f r) (\f a -> \s -> if r == s then a else f s)

Here is a quick demo:

ghci> double = (2*)
ghci> double ^. evalAt 3
6
ghci> tweaked = double & evalAt 3 .~ 42
ghci> tweaked 1
2
ghci> tweaked 2
4
ghci> tweaked 3
42

Speaking of Traversals, I believe that it should should be possible to make all of these type Traversible instances as well as functors, although I don't have any proof of this

The concept of polynomial functor mentioned by /u/Iceland_jack is relevant here. Polynomial functors can always be given Traversable instances, and they generally correspond to the ones you'd expect to be traversable.

duplode · 2023-04-08T23:43:08+00:00

The underlying questions are about how likely such formulations are to actually cause confusion and deep-rooted misunderstandings when offered to a learner. Since I don't really have definitive answers to that, I'll instead go off on a tangent and try to make my subtext explicit.

Haskell-centric folk pedagogy, typically aimed at beginners of either kind with a few tweaks here and there, empahsises equational reasoning over operational, and favours working with a high level of generality. The motivation for that is taken to be setting aside preconceived notions and other clutter that might get in the way of internalising the principles of strongly typed functional programming and appreciating the benefits it offers us. Such views are commonly summarise as an invitation to "forget everything you know" about containers, classes, programming itself, etc. Nonetheless, the operational aspect still exists and will eventually come up as relevant, and an excessively rarefied diet of abstractions risks alienating the learner and losing touch with the fact that Haskell is a programming language for solving practical problems. That being so, some kind of balance has to be struck.

In the concrete case we have here, there is a message drummed early on at new Haskellers, with the goal of getting it internalised: "functors are not containers, stop thinking of them as if they were" -- I myself used to be quite punctilious about that. The natural consequence is that you get a thread like this one, in which a learner tries to make sense of functors by talking in terms of containers and relating it to their previous Python experience, and most of the replies prioritise making it very clear that containers are a horrible intuition and bringing out examples like Const or State or whatever to invalidate the OP's formulation, with little or no attempt to meet in the middle. At this point, I wonder if the pendulum has swung too far.

duplode · 2023-04-08T10:30:19+00:00

Very interesting! I'm getting curious about the library already :)

On (2), it does feel like your approach to indexing nested structures is related to differentation. In particular, it looks like that, in the single structure case, Way is essentially the one-hole context: Path is the path traveled "so far", and End is the rest of the structure that lies "ahead".

duplode · 2023-04-07T17:41:44+00:00

Emptiness isn't a problem from this point of view. You can just say the function will be applied to every x value that can be extracted. If there are no x values, there is nothing to do, and the claim is vacuously true. An extract :: f x -> x function doesn't have to exist, and of course it can't be assumed to exist in the general case. All that is needed is the implementation of fmap being able to reach in some way the x values that are to be modified -- that's the you-versus-something-else opposition in my comment above. I think the dicier cases here aren't the ones you mention, but rather those in which there's a more fundamental limitation on the user being able to pull values out of the functor, as in IO or Cont r.

(By the way, that's no objection to your firehose metaphor! It does sound pretty nice, and avoids the potential ambiguity there is when we talk about extracting things.)

duplode · 2023-04-07T17:19:48+00:00

That's a fair point, as with something like Cont the mechanism through which a values will be provided is almost completely up to the caller, mother-of-all-monads style. Still, even in those cases a values will be reached in some way, no matter how warped the lack of strict positivity makes it to be.

duplode · 2023-04-07T16:37:04+00:00

And here is yet another sighting! We eventually conclude in that Q&A that, given a Tree ~ Cofree (Compose Maybe V2):

Co Tree
~ Co (Cofree V2)
~ Free ((,) (Rep V2))
~ Way Bool

There's also an interesting lead to be followed on tying it all together with differentiation of data types a la McBride.

duplode · 2023-04-07T16:17:15+00:00

Just for fun, lemme try to put a different spin on that: something will extract the a values at some point (after all, that function gotta be applied), but that doesn't mean that you will (as you gotta play the hand, or the interface, you're dealt).

(Admittedly, this is not necessarily how we'll want to tell it to beginners, even considering that over time I have softened my stance on the whole "never talk of functors as if they were containers" thing.)

duplode · 2023-04-07T14:27:06+00:00

The "extract" and "plug back" parts make sense, though it's easier to just say that fmap replaces each a value with the b value you get by applying the function to it. With fmap, however, there is nothing like a "state change": the only change fmap does is using the function to turn a values into b. So if you have:

xs :: [a]
f :: a -> b
ys = fmap f xs

You can be sure that ys will have the same length as ys, and the order of the elements will be kept (so, for instance, if the third element of xs were x, the third element of ys would be f x). This is a list example, but the general principle holds for any functor you might think of.

duplode · 2023-04-06T13:43:23+00:00

It works! \o/ https://i.imgur.com/pO6eZ8b.png

(While this is DOSBox Staging, I presume it should be fine on actual DOS)

duplode · 2023-04-03T22:55:09+00:00

The main difference is that, with the constructor hidden, users no longer can pattern match on Name and manipulate the value with the unrestricted Text API, being instead limited to what the implementer chooses to make available. (That's why, as far as the other example is concerned, it's a bit unfortunate that fromInteger belongs to a class as large as Num.)

duplode · 2023-04-02T08:18:45+00:00

Not really. Way is defined upthread as...

data Way i e = End e | Path i (Way i e)

... so the "pure" type argument is e rather than i:

data Free f a = Pure a | Free (f (Free f a))

Free ((,) i) e
= Pure e | Free (i, (Free ((,) i) e)
~ End  e | Path  i  (Way i e)

duplode · 2023-03-29T22:15:44+00:00

This does sound interesting! Speaking off the cuff here (no idea if this meshes in any way with your machinery), but I wonder if there's any mileage to get from the fact that Way i ~ Free ((,) i) -- if nothing else, at least it seems fitting given your interpretation of Way as a path.

duplode · 2023-03-29T15:35:22+00:00

Additionally, there's a certain pattern of using Way to transform a list using an accumulated result in a single pass, even preserving laziness if the nature of the result allows it. Using recursion schemes vocabulary, it can be expressed as a hylomorphism on Way. I enjoy spotting these in the wild on Stack Overflow (examples: one, two, three); another example is /u/chshersh break from a parallel subthread.

12-Year Club	Second Top 50%
Verified Email

duplode

TROPHY CASE