Skip to content

Instantly share code, notes, and snippets.

@skilpat
skilpat / Unsafe.kt
Created March 11, 2018 15:36
Example demonstrating that the Kotlin type system doesn't satisfy subject reduction and therefore type safety.
/*
* The following example code demonstrates how Kotlin's type system violates
* a conventional property of type systems, Subject Reduction. The Kotlin type
* system is therefore not "safe" according to the conventional notion in
* programming languages theory. See the code in the `main` function below.
*
* This notion of type safety relies on a reduction semantics for the
* language, which Kotlin doesn't purport to implement. However, any
* reasonable language's operational semantics would contain a rule like
* `f(e_arg)` evaluates to `e_body[e_arg/x]` when `f(x) = e_body` is the
@skilpat
skilpat / instances.md
Last active July 2, 2018 00:43
Which instances are visible in various Haskell modules?

Keybase proof

I hereby claim:

  • I am skilpat on github.
  • I am skilpat (https://keybase.io/skilpat) on keybase.
  • I have a public key whose fingerprint is 08A0 1014 F958 24D7 D360 B2E5 A954 3B6F 48DD BBF3

To claim this, I am signing this object:

@skilpat
skilpat / Client.v
Last active August 29, 2015 14:00
An example of a challenge for modularity in the context of dependent types: how to do useful stuff with only an *interface* of external components. Credit for this example goes to Neel Krishnaswami.
(* Here is some client code that needs to
construct a proof about fac. Because it doesn't
rely on any particular *representation* of
nats, it imports the abstract nat interface;
thus it could be linked against Peano, binary,
and other implementations of the nat interface. *)
(* Assume 'Nat' refers to the abstract spec, NatSpec. *)
Import Nat