overview for mrkeen

Type inference was a mistake in c/programming_languages@programming.dev

[–] mrkeen@mastodon.social 2 points 7 months ago (5 children)

Yes. Type-inference typically *knows better than me* what the types should be.

I frequently ask the compiler what code I need to write next by leaving a gap in my implementation and letting the compiler spit out the type of the missing section.

Monad (functional programming) - Wikipedia in c/functional_programming@programming.dev

[–] mrkeen@mastodon.social 3 points 7 months ago (1 children)

@demesisx @lysdexic No safety issues mentioned around ReaderT. The speaker was talking about how stacking monad transformers mtl-style can generate unnecessary closures that GHC can't optimise away.

I'm betting on Call-by-Push-Value in c/programming_languages@programming.dev

[–] mrkeen@mastodon.social 1 points 8 months ago* (last edited 8 months ago)

@tatterdemalion @armchair_progamer
No.
Elaborate?

Unification-free ("keyword") type checking in c/programming_languages@programming.dev

[–] mrkeen@mastodon.social 2 points 8 months ago (1 children)

@armchair_progamer no mention of (mutual) recursion? It's been a while since I worked on my type checker, but I thought that you needed to separate inference into unification variable generation and constraint solving so that you don't fall into an infinite loop (each function asking the other functions type - forever).