[HN Gopher] Selective Applicative Functors
       ___________________________________________________________________
        
       Selective Applicative Functors
        
       Author : ibobev
       Score  : 19 points
       Date   : 2025-12-31 04:07 UTC (5 days ago)
        
 (HTM) web link (blog.veritates.love)
 (TXT) w3m dump (blog.veritates.love)
        
       | munchler wrote:
       | This is an interesting concept, but it is presented so abstractly
       | as to be opaque to even most functional programmers, I think.
       | 
       | The basic idea, as I understand it, is a typeclass that is more
       | powerful than an applicative, but still less powerful than a
       | monad, called a "selective applicative". I would summarize them
       | like this:
       | 
       | * Applicative: Fixed computation graph, but no conditional
       | structure.
       | 
       | * Selective applicative: Fixed computation graph with some
       | conditional "branches".
       | 
       | * Monad: Dynamic computation graph and control flow, can generate
       | new structure on the fly.
       | 
       | I'm sure I'm still missing a lot, but I think that's the 10,000
       | foot view.
        
         | Bjartr wrote:
         | That matches what I managed to glean, though I didn't get much
         | further.
         | 
         | It started making more sense though when I managed to fully
         | understand the AST comparison that was being made.
         | Specifically, this approach lets you do the LISPy "code is
         | data" thing where you can construct your program within your
         | program and then run it, but instead does it via "data is
         | execution+control-flow". Thus gaining the benefits of static
         | analysis on the constructed program since you wrote it all out
         | in the "normal"/static order rather than the "nested"/dynamic
         | view of a program that monads give.
         | 
         | At least that's the gist I got, though take it with a grain of
         | salt, the article went very over my head at times.
        
       | noelwelsh wrote:
       | Well... I enjoyed the author's enthusiasm. What I read was
       | interesting, but I didn't read all of it. Why not? I wasn't sure
       | where it was going. I think there is a tighter post to be written
       | that explains the new formulation without so much wandering
       | around in abstractions. I also think the post uses jargon where
       | it isn't necessary. I could just about follow it, but it made
       | reading unnecesarily hard work. For me a better post would
       | explain the new selective functor in the most concrete terms
       | possible, and only then talk about the abstract things it is
       | related to.
        
         | solomonb wrote:
         | I hear you but I think you are simply asking for an entirely
         | different blog post. I don't think Verity's aim here is to give
         | an introduction to `Selective`, but rather to introduce a
         | formalization for it; something which has been notably missing
         | for those who think about these sorts of things.
        
           | noelwelsh wrote:
           | I understand the original Selective Functor, so an
           | introduction to that is not what I'm after. I want to
           | understand this new formalization, because it's the kind of
           | thing I use, but I'm not a theoretician. If the goal of this
           | post is simply to explain the formalization to the small
           | number of people who are already deep into (category) theory,
           | I guess it does a fine job. However, I think a better post
           | would be more accessible.
           | 
           | I think the blog post does a good job describing the idea of
           | Selective ("finite-case" etc.) but for me it falls apart
           | shortly afterwards. If I was writing it, from what I
           | understood I would start with the overview, then describe
           | `CaseTree`, and then go into what abstractions this is an
           | instance of.
           | 
           | As a small example of how I think the writing could be
           | improved, take this sentence:
           | 
           | "This is in contrast to applicative functors, which have no
           | "arrow of time": their structure can be dualized to run
           | effects in reverse because it has no control flow required by
           | the interface."
           | 
           | This uses jargon where it's not necessary. There is no need
           | to mention duality, and the "arrow of time" isn't very
           | helpful unless you've had some fairly specific education. I
           | feel it's sufficient to say that applicatives don't represent
           | any particular control-flow and therefore can be run in any
           | order.
        
       | nick_g wrote:
       | I'm going to have to read through this again to really grasp it
       | 
       | I believe there's a minor error in the "Tensorful" section. When
       | describing that `CaseTree` is a profunctor, the type of the
       | contravariant map over `CaseTree` is written as `(i' -> i) ->
       | CaseTree f i r -> CaseTree i' f r`. I believe the last term
       | should be `CaseTree f i' r`
        
       ___________________________________________________________________
       (page generated 2026-01-05 23:00 UTC)