Alice ✨
@welltypedwit.ch
2.5K followers 330 following 4.4K posts
When the limestone of imperative programming has worn away, the granite of functional programming will be revealed underneath -Simon Peyton Jones https://welltypedwit.ch
Posts Media Videos Starter Packs
welltypedwit.ch
i wasn't expecting south african either lol

(fwiw i think you sound quite british ^^)
german: 42%, south african: 35%, albanian: 10%, accent sterngth: 71%
welltypedwit.ch
if you knew the types of your imports ahead of time, you could instantiate blah before each call as always, but if you keep them as unification variables you would try to unify the one for blah with `Int -> Int` and `String -> String` (and throw an error) wouldn't you?
welltypedwit.ch
e g. let's say you have (probably not correct grace syntax, sorry)

-- module1.grace:
let blah : forall a. a -> a = \x -> x

-- module 2.grace
let { blah } = import somethingThatResolvesToModule1() in

let x = blah(5)
let y = blah("a")
welltypedwit.ch
oh interesting. what happens if the imported module contains
functions with polymorphic types though? wouldn't binding unification variables to polytypes cause issues?
welltypedwit.ch
i'm so confused by what their politics are? like, misandry, environmentalism, anti-semitisim and anti-antifa are an... interesting combination lol
clearsky post from this person:

Decades ago when I worked with Citizen Action and Greenpeace many Americans mocked progressives. Same as this era. Thanks to those who took us in. Soros or antifas were never with us.
welltypedwit.ch
trees are nice too (and graphs but maybe not for someone's first inductive proof ^^)
welltypedwit.ch
like, if you've triple checked that a gadt actually helps with your problem go for it but can we at least try to prevent beginners from shooting themselves in the foot?
welltypedwit.ch
i just don't get this obsession. gadts are a pretty niche construct that is rarely very useful, sometimes pretty useless and most of a time an extremely easy way to code yourself into a corner that triples the complexity of your codebase
welltypedwit.ch
can ocaml people please stop recommending gadts when they're absolutely not appropriate omfg
welltypedwit.ch
i'm like 87% convinced the "no DMs" thing is a concealed code for the bots to find each other
welltypedwit.ch
hmm maybe? beating `Format.fprintf ppf "List: @[<v>%t@]@."` in ux doesn't seem that hard though tbh ^^
welltypedwit.ch
i don't think I'll ever understand why ocaml people use limited and weirdly complicated format strings for everything instead of something sensible like a wadler leijen printer
welltypedwit.ch
but the code that manipulates the IO action *is* pure so the compiler can perform all the purity and laziness optimizations it would perform on regular pure code
welltypedwit.ch
i mean, haskell's purity around IO works the exact same way. `IO a` is an abstract newtype over (morally) `() -> a` and so something like `putStrLn` is literally a curried impure effectful function that will eventually be run when you call it from main (like the effectful code in a react component)
welltypedwit.ch
flambda isn't lazy or pure is it?
welltypedwit.ch
to me it just seems obviously true tbh ^^
Reposted by Alice ✨
danabra.mov
i think the @react.dev Compiler team could include more of this type of messaging. i'm being a bit inflammatory here (and Haskell may not the best analogy), but the principle of "pure things are safe to move around" is fundamentally simple and has been known for decades. teach it to new generation!
You may not like it, but React is basically Haskell. 

The React Compiler works for the same exact reason that compilers for pure programming languages are able to make non-trivial optimizations.

If your code is composed of pure functions, it is safe to re-order their computation, or save the result for some inputs and reuse it for later for same inputs.  This is not some kind of a “workaround” or a hack — it’s one of the most exciting consequences of the functional programming paradigm which has been known and used for decades.

Purity and idempotency make it safe to move stuff around without changing the final outcome. Following the "rules of React" is just ensuring your code is safe to move around like this.
welltypedwit.ch
ohh you're right
welltypedwit.ch
something something effectful fixes this
welltypedwit.ch
i actually can't think of a single scenario where a (direct) view pattern would be more appropriate than a pattern synonym
welltypedwit.ch
idk, maybe it's fine and i'm just overthinking it
welltypedwit.ch
hmm the problem with pair syntax is that i'm running out of ascii parentheses/brackets ^^
existentials in lean are explicit, right? i wouldn't be opposed to pair or record syntax in that case but it seems a bit confusing if both

let y = x

and

let ⟨a, y⟩ = x

are valid
welltypedwit.ch
so where is the a bound here?
welltypedwit.ch
but written like this i can't give y a type signature because i don't have a way to name that `a1`!
in order to do that, i would need to unpack the existential explicitly with something like

let (a | y : List(a)) = x

but i'm struggling to come up with a syntax that isn't quite this awkward ^^
welltypedwit.ch
so, what is everyone's favorite syntax for explicitly "unpacking" an existential?
e.g. given `x : exists a. List(a)`, i can write `let y = x` and that will give y type `List(a1)` where `a1` is an implicitly created skolem that corresponds to the `a` in the existential