My New/Old Agenda Dave MacQueen WG 2.8, Aussois, 2013 1 Sunday, - - PowerPoint PPT Presentation

my new old agenda
SMART_READER_LITE
LIVE PREVIEW

My New/Old Agenda Dave MacQueen WG 2.8, Aussois, 2013 1 Sunday, - - PowerPoint PPT Presentation

My New/Old Agenda Dave MacQueen WG 2.8, Aussois, 2013 1 Sunday, October 20, 13 From Ryerson Hall 2 Sunday, October 20, 13 To Silicon Valley 3 Sunday, October 20, 13 My To Do List 1 Maintain and improve SML/NJ 2 Writing projects 3


slide-1
SLIDE 1

My New/Old Agenda

Dave MacQueen WG 2.8, Aussois, 2013

1

Sunday, October 20, 13

slide-2
SLIDE 2

From Ryerson Hall

2

Sunday, October 20, 13

slide-3
SLIDE 3

To Silicon Valley

3

Sunday, October 20, 13

slide-4
SLIDE 4

4

My To Do List

1 Maintain and improve SML/NJ 2 Writing projects 3 Reviving Standard ML Definition Thoughts on Simplicity

Sunday, October 20, 13

slide-5
SLIDE 5

5

Maintain and Improve SML/NJ

  • type checking improvements
  • mostly improved error messages
  • module system internals rewrite
  • FLINT middle end cleanup or (better) replacement
  • modernizations
  • 64 bit
  • unicode
  • LLVM (replacing MLRISC)
  • regular bi-annual releases planned

Sunday, October 20, 13

slide-6
SLIDE 6

6

Writing Projects

  • Induction tutorial
  • from first principles
  • full and precise induction proofs
  • seeking further good examples (small, challenging induction proofs)
  • PL course notes packaging for the web
  • open source supplementary textbook
  • full and precise proofs as in the Induction Tutorial
  • simplified variant of Harper's book
  • Historical survey of module design and semantics
  • with prototype implementations of several key module papers
  • Modules vs Type Classes (supervised Master's thesis)
  • critical comparison: Haskell classes, SML modules, modular type classes

Sunday, October 20, 13

slide-7
SLIDE 7

7

Reviving the Definition of Standard ML, Revised (SML '97)

Negotiated permission from MIT Press to open the Definition for free

  • nline distribution.
  • 1. recreate SML '97 sources and make them available
  • nline as pdf version and github source repository.

SML '90 available now at: https://github.com/SMLDefinition

  • 2. make corrections and minor revisions that have been suggested
  • ver the years (e.g., clarify rules for overloading resolution).

Sunday, October 20, 13

slide-8
SLIDE 8

8

Reviving the Definition of Standard ML, Revised (SML '97)

  • 3. Definition and language evolution, e.g.:
  • cost semantics
  • higher-order functors
  • module definitions within the core language
  • modular type classes
  • parallel ML (Manticore)

See Bob Harper’s “Future of SML” talk at the 2013 ML Workshop: http://www.cs.cmu/~rwh/talks/mlw13.pdf Serious revisions will require new formalisms.

  • e.g. higher-order functors incompatible with current Defn and

probably with Harper-Stone style "type-theoretic" semantics

  • revised definitions should ideally be mechanized

What to call a revised language? Don’t want to use “Standard” anymore. “Successor ML”? “ML2K”? “ML”?

Sunday, October 20, 13

slide-9
SLIDE 9

9

Thoughts on Simplicity in Language Design

  • Language should be simple enough that competent programmers can

understand and use the whole language (without subsetting) ==> simple and accurate programmer's working model.

  • Simple enough to have a workable, pragmatic cost model.
  • [types] Simple enough to have "obvious" ("transparent") type checking
  • - should be possible to do type checking in your head as you

write/read programs.

  • Simple enough to be able to teach/learn the language to undergrad CS

students (working programmers) in a reasonable amount of time (e.g. << a 10 week quarter, say 3 weeks or 10 hours of lectures + homework)

  • Simple enough to "reason about" programs (informally)
  • Simple enough to have a reasonably accessible formal definition

Sunday, October 20, 13

slide-10
SLIDE 10

10

Design evolution tends to greater complexity

  • Very hard to eliminate features used in any existing code (no matter

how little code exists, even potential code!)

  • Hence, once a feature is added, it will almost never be removed, or even

improved/simplified. Instead, even more features may be added to try to correct deficiencies in earlier features, leading to

  • redundancy

** e.g. Lisp Machine lisp. Many ways to do the same thing, layered historically (like a software archeological tell)

  • unintended and undesirable feature interactions

Sunday, October 20, 13

slide-11
SLIDE 11

11

interesting

simple

HM ADT

the domain of the mathematician programmer

Sunday, October 20, 13

slide-12
SLIDE 12

12

interesting

simple

the domain of the mathematician programmer

Haskell Java C++ Scala SML

Sunday, October 20, 13

slide-13
SLIDE 13

13

interesting

simple

the domain of the mathematician programmer

Haskell Java C++ Scala SML Caml OCaml

Sunday, October 20, 13