
Unsafe Haskell (2015) - Cieplak
http://www.seas.upenn.edu/~cis194/spring15/lectures/12-unsafe.html
======
justinjlynn
So, essentially the Haskell compiler allows you to say "don't worry I've got
this, it'll be fine -- it's pure and semantically correct, I promise!" because
the developers of the compiler know that they can't think of everything and
want you to be able to do some really nasty hacks if you have to do so. It's
easy to check up that the authors of the libraries you're using aren't using
these escape hatches.

Of course, if they or you are using these escape hatches, and it's not correct
-- and it blows up -- you've only yourself to blame for subverting the
compiler.

~~~
Drup
Most strongly typed languages have such escape hatches ("Unsafe" in haskell,
"Obj" in OCaml, "trustme" in Idris,....) . It's something you always need at
some point when the typing is not sufficient to properly account for what you
are doing.

For instance, Coq code can be extracted to OCaml code. OCaml type system is
less powerful than Coq's, so Coq needs to cheat, and the emitted code is full
of "unsafe" features. But the program was typechecked with Coq's type system,
and is thus perfectly safe.

Of course, the goal of the language designer is to minimize its usage. That's
something the Rust people understood very well, and the unsafe blocks are an
extremely good solution to this problem.

~~~
pdpi
> It's something you always need at some point when the typing is not
> sufficient to properly account for what you are doing.

E.g. FFI becomes horrendously impractical without something of this kind.

~~~
nickpsecurity
There's even work to address that with linking types:

[https://dbp.io/pubs/2017/linking-types-
snapl.pdf](https://dbp.io/pubs/2017/linking-types-snapl.pdf)

If the component is externally type-checked, the integration can be type
checked against the language including it. They're also working on verifying
compilers that do that:

[https://dbp.io/essays/2018-04-19-how-to-prove-a-compiler-
ful...](https://dbp.io/essays/2018-04-19-how-to-prove-a-compiler-fully-
abstract.html)

Previously, others made the assembly languages themselves type-safe. Example:

[https://www.cs.cornell.edu/talc/papers/talx86-wcsss.pdf](https://www.cs.cornell.edu/talc/papers/talx86-wcsss.pdf)

We might eventually be able to drop a caveat or three when talking about where
type/memory safety ends. Cool stuff, eh?

------
habitue
This is the reason Safe Haskell exists

[https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_gui...](https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/safe-
haskell.html)

~~~
dmead
Also lambdabot.

------
FrozenVoid
Author calls the unsafe version x7 slower, yet such imperative, impure code
wins Haskell benchmarks Perhaps he didn't optimize it well?
[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/faster/haskell.html)

------
saintPirelli
Haskell is my guilty pleasure language. I have no idea what I personally would
ever use it for, but I admire it so much that learning it is higher up on my
bucket list than many other (arguably more useful) things.

~~~
nine_k
Learning Haskell definitely affected the way I write _and read_ code in other
languages.

------
jejones3141
Is there a point to this other than calling unsafe functions is unsafe?

~~~
JadeNB
Presumably, answering the question "Why does Haskell have all these
(seemingly) unnecessary restrictions on things that I can do when doing them
(seemingly) won't cause problems?"

