Clean 2'0

1
Clean 2.0
At last..
Rinus Plasmeijer University of Nijmegen www.cs.ku
n.nl/clean
2
Clean version 2.0

• New compiler rewritten in Clean (instead of C)
• Lots of small improvements in language
• - import mechanism (more precise, cyclic)
• - rank 2 polymorphism
• - multi-parameter type constructor classes
• Support for Lazy / Strict / Unboxed lists
• Experimental feature dynamics
• IDE easy switching between different compilers /
  linkers
• Sparkle !
• Not finished on time support for Generic
  Programming

3
Clean version 2.0

• New compiler written in Clean (instead of C)
• Lots of small improvements in language
• - import mechanism (more precise, cyclic)
• - rank 2 polymorphism
• - multi-parameter type constructor classes
• Support for Lazy / Strict / Unboxed lists
• Experimental feature dynamics
• IDE easy switching between different compilers /
  linkers
• Sparkle !
• Not finished on time support for Generic
  Programming

4
Lazy lists in Clean 1.3

• Lazy lists are predefined data structures
• Special syntax, list comprehensions, lots of
  predefined functions
• map (a ? b) a ? b
• map f
• map f x xs f x map f xs
• One can also define user-defined lists using an
  algebraic data type
• List a Cons a (List a)
• Nil
• mapl (a ? b) (List a) ? (List b)
• mapl f Nil Nil
• mapl f (Cons x xs) Cons (f x) (mapl f xs)
• Different type as lazy list cannot use nice
  syntax, nor any predefined function
• But one can make eager and unboxed list
  variants in this way

5
Lazy lists in Clean 1.3

• Lazy lists are predefined data structures
• Special syntax, list comprehensions, lots of
  predefined functions
• map (a ? b) a ? b
• map f
• map f x xs f x map f xs
• One can also define user-defined lists using an
  algebraic data type
• HList a HCons !a (HList a)
• HNil
• maph (a ? b) (HList a) ? (HList b)
• maph f HNil HNil
• maph f (HCons x xs) HCons (f x) (maph f xs)
• Different type as lazy list cannot use nice
  syntax, nor any predefined function
• But one can make eager and unboxed list
  variants in this way

6
Lazy lists in Clean 1.3

• Lazy lists are predefined data structures
• Special syntax, list comprehensions, lots of
  predefined functions
• map (a ? b) a ? b
• map f
• map f x xs f x map f xs
• One can also define user-defined lists using an
  algebraic data type
• EList a ECons !a !(EList a)
• ENil
• mape (a ? b) (EList a) ? (EList b)
• mape f ENil ENil
• mape f (ECons x xs) ECons (f x) (mape f xs)
• Different type as lazy list cannot use nice
  syntax, nor any predefined function
• But one can make eager and unboxed list
  variants in this way

7
Clean 2.0 syntax for lazy, strict, unboxed lists

• map (a ? b) a ? b // default lazy list
• map f
• map f x xs f x map f xs
• Syntax added for strict lists ! , !, !!
  and unboxed lists , !
• maph (a ? b) !a ? !b // head strict list
• maph f ! !
• maph f !x xs !f x maph f xs
• mapu (a ? b) Int! ? Int! // head
  unboxedtail strict list of Int
• mapu f ! !
• mapu f x xs! f x mapu f xs!

8
Overloading for lists using the class List

• map (a ? b) (m a) ? (n b) List m a List n
  b
• map f
• map f x xs f x map f xs
• This overloaded definition can be used for all
  representations
• , ! , !, !!, , !
• Overloading is used in the pattern match !
• Overloading mechanism takes care of
  specialization
• Automatically within the same module
• Exported overloaded functions can be specialized
  on demand
• No loss of efficiency

9
Measurements
10
Clean version 2.0

• New compiler written in Clean (instead of C)
• Lots of small improvements in language
• - import mechanism (more precise, cyclic)
• - rank 2 polymorphism
• - multi-parameter type constructor classes
• Support for Lazy / Strict / Unboxed lists
• Experimental feature dynamics
• IDE easy switching between different compilers /
  linkers
• Sparkle !
• Not finished on time support for Generic
  Programming

11
Why Dynamics ?

• Exchange of data as well as code (!)in an easy
  and type-safe way
• get rit of boring code for trivial I/O
• Output convert to some (string) format
• Input parser needed
• typical 30 of program code
• be able to store, retrieve and exchange code
• add and combine plug-ins in a type-safe way
• support the development of persistent programs
• allow communication of arbitrary expressions
  between distributed applications
• more expressive power

12
Hybride Type System

• Use keyword dynamic to change an expression of a
  static type ? into the dynamic type Dynamic
• 3 Int dynamic 3 Dynamic
• map (a ? b) a ? b dynamic map Dynamic
  
• map square Int ? Int dynamic map square
  Dynamic
• Use pattern matching to examine if an argument
  of dynamic type Dynamic is of a particular
  static type
• transform Dynamic ? Int
• transform (n Int) n
• transform (f Int ? Int) f 1..100
• transform other abort dynamic type error

13
Dynamic Type Unification

• dynApply Dynamic Dynamic ? Dynamic
• dynApply (f a ? b) (x a) dynamic (f x
  b)
• dynApply df dx abort dynamic
  type error
• dynApply2 Dynamic Dynamic ? b TC b
• dynApply2 (f a ? b) (x a) f x b
• dynApply2 df dx abort dynamic
  type error
• Run-time type checking, unification, type errors

14
Communicating Dynamics

• write read Dynamics with one instruction
• writeDynamic Dynamic File ? File
• readDynamic File ? (Dynamic, File)
• sendDynamic Dynamic Channel ? Channel

15
Clean System 2.0

• .icl

• .dcl

• .pcl

• I ntegrated
• D evelopment
• E nvironment
• Project Manager
• Editor
• Clean

• Time Profiler
• Clean

• Compiler Clean /C

• .abc

• .chp

• Heap Profiler
• Clean

• Code Generator C

• RTS
• C

• .obj

• .obj

• Sparkle
• Clean

• Static Linker Clean

• Application
• Clean

16
Clean Dynamic Linker

• .icl

• .dcl

• I ntegrated
• D evelopment
• E nvironment
• Project Manager
• Editor
• Clean

• Compiler Clean /C

• .abc

• Code Generator C

• RTS
• C

• .obj

• .obj

17
Dynamics Easy to use, hard to implement !

• Writing of a Dynamic
• Expression is stored, sharing maintained, nested
  dynamics allowed
• Type of the Dynamic is stored
• Store references to applications images
  containing the code type definitions
• Reading of a Dynamic is done lazily
• Nothing happens until its type is required in a
  pattern match
• Linking of code only happens if all types in the
  rule match and can be unifiedand all type
  definitions involved in the Dynamics and the
  application are identical
• If the rule matches, the expression is
  constructed as far as needed
• Constructors of the same type must have the same
  address !
• The code needed for evaluation not yet linked in
  will be linked in (Plug-in)

18
Demo applications using Dynamics

• Visual Editor (work in progress)
• Resource editor for defining dialogs, windows,
  menus
• Stores its definitions in a Dynamic
• Definitions are a plug-in for the application
• Application can change its look by using the
  Visual Editor as plug-in
• FAMKE - Functional Micro Kernel Experiment (work
  in progress)
• Very Tiny Operating System only type safe
  operations !
• Special File Manager Files contain Dynamics
• Executables ( a -gt b), Data ( T a b c)
• Process creation and communication using Dynamics
• Type safe Unix-like shell (pipes) using process
  combinators
• Data Base support

19
Clean Compiler version 2.0

• Status
• Front end compiler completely rewritten in Clean
• We have added some interesting new features
• All Clean 1.3 applications (IDE, Sparkle,
  compiler) ported and tested
• Speed about 1.7 slower than C version
• See www.cs.kun.nl/clean (13.2 Mb zipped, open
  source)
• Work to do
• Test compiler for new features, wrong programs
• Dynamics uniqueness typing, universal
  quantified types
• Add support for generic programming
• Improve fusion algorithm to reduce generics
  overhead
• Port to Mac OS X (carbon/PEF), Linux

20
The Clean Team

• STW crew
• Diederik van Arkel (16-9-2003)
• Integrated Development Environment
• Fusion Algorithm
• Martijn Vervoort (16-9-2003)
• Dynamics Dynamic Linker
• Arjen van Weelden (1-10-2002)
• Demo Application Famke
• KUN crew
• John van Groningen
• Compiler, Code generator
• Ronny Wichers - Schreur
• Compiler
• Testing
• KUN PhD researchers
• Maarten de Mol
• Sparkle Proof System
• Artem Alimarine
• Generic Programming

• KUN MSc students
• Arvid Nicolaas
• Demo Application Visual Editor
• KUN staf
• Peter Achten
• Generics / IO / Visual Editor
• Pieter Koopman
• compiler (parser/checking)
• Sjaak Smetsers
• compiler (typing, testing)
• Marko van Eekelen
• Semantics Clean Sparkle
• Rinus Plasmeijer
• Project leader