Skip to content
This repository has been archived by the owner on Oct 9, 2018. It is now read-only.

Latest commit

 

History

History
54 lines (46 loc) · 3.02 KB

2011-10-25.md

File metadata and controls

54 lines (46 loc) · 3.02 KB
Raw

Attending

Brian, Dave, Marijn, Niko, Patrick

Objects

Discussed Patrick's draft design of an OO system based on zero-inheritance non-virtual classes (type + implementation), structural interfaces (type but not implementation), and traits (implementation but not type).

  • Patrick: everyone seems to agree it makes sense to make interfaces nominal; I didn't see how to do I1 + I2 but we can maybe do interface I3 = I1 + I2
  • Dave: if I is recursive, not sure what it means to add it to another interface, i.e., what the recursive references mean; might be solvable
  • Patrick: or maybe just punt; not sure it's a necessary feature
  • Patrick: stages of implementation, where we have something useful at each stage:
  1. classes
  2. interfaces
  3. traits
  • Niko: now what about unifying classes and records?
  • Patrick: yes, as Marijn says, !EIAO is a bad design smell
  • Marijn: unifying classes and records doesn't resolve the issue of other primitive types; you're still in Java-land
  • Patrick: solves some but not all; I'm not opposed to the idea of Scala implicits
  • Dave: my only concern is modularity issues with overloading
  • Niko: Scala implicits make coercions an importable thing; scoped imports restrict coercions to lexical scopes
  • Marijn: does it do operator overloading?
  • Niko: yes: they use extensively in collections library
  • Niko: also, implicit parameters; e.g., sort takes an implicit < function
  • Marijn: this sounds good; not necessary for first stage, but if everyone agrees it's a good goal, then the proposed object system sounds promising to me
  • Niko: implicits help with context passing too; A takes implicit, can implicitly pass to B too
  • Patrick: I'll send a description of the system to rust-dev

Regions

  • Patrick: background: subsumes some cases of alias analysis; precedent is from Cyclone
  • Patrick: basic idea: first-class reference types, type system enforces that references cannot escape their liveness
  • Marijn: can you send papers?
  • Patrick: yes
  • Dave: might help to write an overview, too, since the lit may go off on tangents
  • Patrick: yeah, the original lit tried to replace GC entirely, which ended up making it unnecessarily complex; we're only interested in safe references
  • Marijn: I'm open to ideas; just had to fix some of stdlib b/c of a hole in the alias analysis
  • Patrick: I also have ideas for doing safe pools and arenas

Kinds

Question about default kind bounds on polymorphic type parameters.

  • Marijn: pinned-by-default is most general, but you often want shared
  • infer by default?
  • warn if over-constrained?
  • Patrick: what about shared by default?
  • Marijn: lthat's what I did, but may over-constrain
  • Patrick: I'm nervous about inferring based on the body; we've avoided doing that anywhere else
  • Niko: almost always want shared
  • Marijn: except, not for datatypes
  • Patrick: shorten to pin and uniq?
  • Marijn: blech! but meh
  • Dave: you can't turn off the warnings
  • Marijn: so maybe we make shared default but warn if over-constrained; you turn off the warning if you explicitly say shared