I’m also on Mastodon as https://hachyderm.io/@BoydStephenSmithJr .

  • 11 Posts
  • 39 Comments
Joined 1 year ago
cake
Cake day: October 2nd, 2023

help-circle




  • Most people never become auto-didacts. Most auto-didacts still benefit from formal training because above average gross performance can mask subtle mistakes until the mistake becomes root cause for a significant error.

    Under significant pressure (like a well-written dramatic fiction, but almost never IRL), most doctors will be willing to perform a procedure without formal training, but under normal conditions, they know it is not worth the additional risk.


  • Some people hate it, including some independent developers. I wouldn’t mind going without it, if there was a Free Software library management alternative. I want something to track what I have installed (because I’ve “lost” things and reinstalled them before) and something that has a decent uninstall.

    I also get some benefit from the store integration, but I can understand developers being annoyed at the 30% “steam tax”. I’d gladly purchase using some other method, if I didn’t have to sacrifice library functions from previous paragraph.











  • Might check out the Haskell layout rules.

    Basically, when you leave out the ‘{’ then Haskell uses your intendation to insert ‘;}’ on later lines between the leading whitespace and the first token.

    There some really old Haskell code out there that lines up the ‘{;}’ characters on the left under block-introduction keywords.



  • Which functions would you want to see?

    https://byorgey.github.io/blog/posts/2024/07/18/River.html

    Since it’s a (uniformly) recursive data type, I want to see the underlying functor

    data RiverF x r = CF !x | ConsF !x !r deriving Functor
    

    projection and embedding functions:

    project :: River a -> RiverF a (River a)
    project = \case
      C x -> CF x
      Cons x r -> ConsF x r
    
    embed :: RiverF a (River a) -> River a
    embed = \case
      CF x -> C x
      ConsF x r -> x ::= r -- Choosing to normalize, here.
    

    And then generalized fold / unfold:

    fold :: (RiverF a r -> r) -> River a -> r
    fold alg = f
      where f = alg . fmap f . project
    
    unfold :: (s -> RiverF a s) -> s -> River a
    unfold coalg = u
      where u = embed . fmap u . coalg
    

    Note that since we chose a normalizing embed, the result of an unfold is also always normalized.

    I would also not be opposed to a alternate definition that took a proof of normality for the Cons, but I know that would take some higher-rank types, at least.