paulp

(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

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

paulp

# 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

paulp

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)

paulp

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 {

paulp

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

paulp

• 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

paulp

package tuple

import language.experimental.macros
import language.dynamics
import scala.reflect.macros.Context

sealed trait ~[+A, +B]

private[tuple] object TupleMacros {

paulp

// 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

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