Skip to content

Instantly share code, notes, and snippets.

Avatar
🤫

Paul Phillips paulp

🤫
  • CAZ, Inc.
  • Cascadia Autonomous Zone
View GitHub Profile
@paulp
paulp / integer-division.z3
Created Jul 4, 2021 — forked from Rufflewind/integer-division.z3
Truncated integer division in Z3
View integer-division.z3
(declare-fun a () Int)
(declare-fun b () Int)
(declare-fun c () Int)
;; (assert (= a (div -7 -3)))
;; (assert (= b (div 7 -3)))
;; (assert (= c (div -7 3)))
;; (assert (= a (mod -7 -3)))
;; (assert (= b (mod 7 -3)))
;; (assert (= c (mod -7 3)))
@paulp
paulp / package.scala
Created Jan 16, 2016 — forked from zraffer/package.scala
a few operations with functors
View package.scala
package object types {
import scala.language.reflectiveCalls
import scala.language.higherKinds
// quantifiers aka (co)ends
type Forall[+F[_]] = { def apply[X]: F[X] }
type Exists[+F[_]] = F[_]
// basic categorical notions
View 01-name-collision-example.sh
# DYLD_LIBRARY_PATH library variables break linking of standard system libraries by forcing dyld to ignore
# everything but the library's basename when performing what would otherwise be successful library
# resolution.
mkdir rust-lib
echo 'void my_libjpeg_api (void) { }' | clang -dynamiclib -x objective-c -o rust-lib/libjpeg.dylib -
echo 'extern void my_libjpeg_api(void); int main (int argc, char *argv[]) { my_libjpeg_api(); return 0; }' | clang -x objective-c -o example - -framework ImageIO -Lrust-lib -ljpeg
env DYLD_LIBRARY_PATH=`pwd`/rust-lib ./example
#dyld: Library not loaded: /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
# Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
View como.scala
package p {
object Test {
import construction.Monadic
import execution.Bimonad
def main(args: Array[String]): Unit = {
val expression = Monadic[List](10) flatMap (1 to _ toList) coflatMap (_.sum)
View proxies.scala
package proxy
import language.dynamics
abstract class Param[T] { type Type }
object Param {
def apply[T](name: String) = new Param[name.type] { type Type = T }
}
class Proxy(underlying: Map[String, Any]) extends Dynamic {
View Leibniz.scala
abstract class Foo {
trait BarT { this: Bar => def zomg: String }
type Bar <: BarT
def newBar: Bar
}
// Or not sealed if you reject axiom K? :)
sealed abstract class FooEqual[X <: Foo, Y <: Foo] {
val x: X
View notes.md
  • Thesis: Problem is the language as much as the implementation of the compiler
    • Big problem is cyclic dependency in the typer where type inference and type-checking and implicit search mutually depend on each other. In other words: Can you write an interpreter without also writing a typer that at least implements type inference and implicit search. Can you do implicit search without implementing all of the type checker? Type inference and implicit search must be disentangled. They know that in scala too, except that it will be close to impossible. Note that disentanglement doesn't preclude interaction, but it has to flow through much narrower, explicit, disciplined channels.
    • Consequence if this is true: If you want to simplify the compiler you would have to identify how to simplify the language to break up those cycles **There are innumerable simplifications available in the compiler which require nothing but sane software engineering. If you want to minimize the ESSENTIAL complexity
View Tuple.scala
package tuple
import language.experimental.macros
import language.dynamics
import scala.reflect.macros.Context
sealed trait ~[+A, +B]
private[tuple] object TupleMacros {
View HOF.scala
// Say we have a List of names and we would like to find all those names where "am" occurs:
{
// LINQ
// string[] names = { "Sam", "Pamela", "Dave", "Pascal", "Erik" };
// List<string> filteredNames = names.Where(c => c.Contains("am"))
// .ToList();
// Java Streams
// String[] names = {"Sam","Pamela", "Dave", "Pascal", "Erik"};
// List<String> filteredNames = stream(names)
@paulp
paulp / devirtualized.md
Created Oct 1, 2012 — forked from c9r/devirtualized.md
De-virtualized Collections
View devirtualized.md

De-virtualized Collections

De-virtualizing abstract collections would increase performance and decrease bytecode bloat for common use cases–without tying the hands of implementors. Conceptually, operations on abstract collections become syntactic sugar for inlined code templates. You opt-in to dynamic behavior by choosing subtypes that override extension methods with virtual ones. The root collections then become an encapsulation of their elements, but not an abstraction over operations on those elements; you can still perform such operations on these collections, but the compiler statically binds the implementation rather than indirecting to the run-time type's vtable-provided version. Collection sub-families–parallel, non-strict, and the like–override generic extension methods with virtual ones, and any value statically typed to such a collection works in the usual object-oriented way.

Sample de-virtualized collection hierarchy

import collection.generic.CanBuildFrom
import language.im