Uni vs Multy

Unityped languages: Making mistakes ist verboten. Any and all of human type errors will be manifest as late as possible, in the most unconvenient way. This is our way of disciplining the Untermensch. Also, you are responsible for any and all code refactorings. The only form of correctness assurance available to you is testing, even though it can never prove the absence of errors. Heil Dynamic! Unityping uber alles!

Multityped languages: Hey, I know you make mistakes, buddy. We all do, we're human, after all. That's why we made this type system for you. Now the compiler can be your buddy, it will get your back and catch most of your errors for you as early and quick as possible! And if you want to refactor something, it will help you out by pointing out the things you missed real quickly. Now you can eliminate most errors without even needing to run your program - how fast is that? And the type system will actually eliminate these errors, as in prove their absence! Now you'll have to do 3 times less testing! Just helping you out, bro.

Conclusion: unityped languages are for Supermensch possessing Aryan discipline and precision, multityped languages are for lazy dumb niggers.

>>2
Yes. In fact, most famous Lispers are/were White, while most famous Haskellers are sandniggers.

program in haskell and drone on about how safe it is
use unsafePerform and unsafeCoerce in your programs

>>4
They're only used in the internals of some important libs. The interfaces are pure. And the average Haskeller doesn't need them.

>>4
When you use them, you know that you're doing inherently unsafe things and you know where focus your effort when things go wrong.

A program that fails from an error that was handled as an exception with no reasonable recovery behavior is just slightly better than a c program that crashed from a segfault. It might not be vulnerable to buffer overrun attacks, but it is still vulnerable to denial of service. And if it's operating the fuel control of a rocket, it's going to malfunction if it encounters the exception again every time it tries to recover, costing money and possibly lives. Your type systems are puny. They speed development, but they do little for safety.

There's no way type idiocy is my friend

>>8
Is there a way you could read your TAPL?

>>9
I couldn't see a verification of the book anywhere so I'm afraid I can't read it.

>>10
The proofs are inside the book itself, so you CAN read it.

>>7
Still better than a unityped mess like Scheme.

>>12
back to 4chan, 0/10 you cant troll me.

>>13

LOL.

>>12
Prelude> let f x = x x

<interactive>:2:13:
Occurs check: cannot construct the infinite type: t1 = t1 -> t0
In the first argument of `x', namely `x'
In the expression: x x
In an equation for `f': f x = x x

# let f x = x x;;
Error: This expression has type 'a -> 'b
but an expression was expected of type 'a

>>16
Funny, wfm:
# let f x = x x;;
val f : ('a -> 'b as 'a) -> 'b = <fun>

$ ocaml -rectypes
OCaml version 4.01.0

(* SKI-combinator calculus *)
# let i x = x;;
val i : 'a -> 'a = <fun>
# let k x y = x;;
val k : 'a -> 'b -> 'a = <fun>
# let s x y z = x z (y z);;
val s : ('a -> 'b -> 'c) -> ('a -> 'b) -> 'a -> 'c = <fun>

(* Y-combinator *)
# let rec y f x = f (y f) x;;
val y : (('a -> 'b) -> 'a -> 'b) -> 'a -> 'b = <fun>

>>15
That crap is useless anyway. Thank goodness the type system prevents it.

>>18
My interest in ocaml is piked.

>>19
It's actually quite powerful. Fortunately for some, the y combinator doesn't have an infinite type, so you aren't missing out on everything. But you are missing a little. If you haven't dived head first into pure lambda calculus yet, I suggest doing it. It is a rearranging experience.

>>20
"Piqued", not "piked", you dipshit.

>>20
Quite powerful for what? Variadic functions? We have folds for that, thanks.

>>22
Functional coroutines are a lot simpler with rectypes. Haven't used them for anything else except writing the SKI-combinators as a joke.

>>21
ROB PIKE SAYS FUCK YOU BITCH

>>23
Looks pretty simple to me:
https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-of-the-week/coroutines-for-streaming/part-2-coroutines

When Arria to her Paetus gave the blade,
Drawn from the wounds that she herself had made,
She cried: "believe me, Paetus, there's no pain!
Flow not your tears! For they would flow in vain.
The damage has been dealt, the oath agreed,
And now thou must, with dignity, proceed.
But ah, I cannot bear to see the deed!
The wounds I made don't hurt, I find it true,
But yet, your wounds which are not made yet, do."

>>26
arria.blogriders.org/gofficpoetry

>>25
The ones I wrote were far simpler than that. They just tuck state away and produce the next yield and continuation on application to unit.

>>28
Well that's exactly what

data CoroutineState s m r
= Run (s (Coroutine s m r))
| Done r

does, minus the addition of the Done r clause for exit from the coroutine.

>>28
Or if you still don't understand:

Run (s (Coroutine s m r))
^ ^
| |
tuck state away |
|
produce the next yield and continuation

Damn, fucked up the alignment:

Run (s (Coroutine s m r))
^ ^
| |
tuck state |
away |
|
produce the next yield
and continuation

>>17,18
Real life code, sans -rectypes (stack-based language interpreter):
type 'a fx = Fix of ('a fx -> 'a)
let unfix (Fix a) = a

let y (r, f) =
let fnx x y = f (y, (unfix x x)) in
(fnx (Fix fnx) r)
Also install 4.02.1 already, mutable strings a shit

>>29-31
No shit. But you have written 2 lines and still don't have a running coroutine in your hands.

>>32
I'll upgrade OCaml when they get more work done on the GC.

>>33
That's not a priority at the moment, plus many libraries are being updated to 4.02, which is backwards-incompatible. You can keep using OCaml without libraries as some kind of Haskell-light if you want, but you'd have to be pretty autistic to refuse software updates based on the state of the GC.