Home My Page Projects Code Snippets Project Openings SML/NJ
Summary Activity Forums Tracker Lists Tasks Docs Surveys News SCM Files

SCM Repository

[smlnj] Annotation of /papers/modulespaper/dissertation/ideas-for-dissertation.txt
ViewVC logotype

Annotation of /papers/modulespaper/dissertation/ideas-for-dissertation.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 3564 - (view) (download)

1 : dbm 3564 Ideas
2 :    
3 :     * static "effects"
4 :     - sealing and generativity (fresh types)
5 :     - reln with nominal typing
6 :    
7 :     * conflict between HO functors (type functionals) and ...
8 :    
9 :     * clean semantics of "true" HO functors
10 :    
11 :     * signature calculus
12 :     - ordering, merging, extension, restriction
13 :     - signature functions
14 :    
15 :     * recursion in a module system (RMC?) [self recursion unnecessary]
16 :    
17 :     * comparisons
18 :     - Scala, Dreyer/Rossberg mixins, OO class mixins, problem of open recursion
19 :    
20 :     => towards a successor ML
21 :    
22 :     * pragmatic principles of module system design
23 :     transparency, "obviousness", declarative semantics
24 :    
25 :     * boundary between core type system and module system
26 :     - extent to which module system can be "abstracted" over core type system
27 :    
28 :     signature S0 = sig type t end
29 :     signature S1 = sig type u type v end
30 :     signature S2 = S0 andalso S1
31 :    
32 :     signature S2' = S0 andalso (S1 as S moving S.u => S.t)
33 :     why do we need "as"?
34 :    
35 :     Terms
36 :     ------
37 :    
38 :     Generative: fresh abstract types each functor application no matter what the argument is
39 :    
40 :     Applicative: Can specify in the signature that abstract type for new application is the same as the old one -- but only for "simple" functor/aopplications
41 :    
42 :     - how to define module equivalence
43 :    
44 :     True HO:
45 :     functor Apply(functor F(X:sig type t))
46 :    
47 :     Apply(F,X) = F(X)
48 :     Apply(F,G,X) = F(G,X)
49 :    
50 :     functor Apply(functor F(X:S):S, structure A:S):
51 :     sig type t = F(A).t end
52 :    
53 :     module LiftProd =
54 :     functor (X: sig type t end) -> struct type t = X.t * X.t end
55 :    
56 :     module H =
57 :     functor (G:functor (X:T)->T)
58 :     -> struct
59 :     module Apply =
60 :     functor (X:sig
61 :     module F:FS
62 :     module M:T
63 :     end)
64 :     -> X.F(G(X.M))
65 :     module R=Apply(struct
66 :     module F=Id
67 :     module M=struct type t = unit end
68 :     end)
69 :     end
70 :    
71 :     include S0 include S1
72 :    
73 :     include S0
74 :     include S1
75 :     versus
76 :     structure M0:S0
77 :     structure M1:S1
78 :     sharing type M0.t = M1.t
79 :     open M0 M1
80 :    
81 :     alternatively Limited Shadowing Semantics
82 :    
83 :     terminology: mergeable, compatible, signature consistency
84 :    
85 :     How does that relate to realizability, inhabitability of a signature and general type inhabitability
86 :    
87 :     There is also the category of signatures (universal algebra)
88 :     Goguen before OBJ (LISP conference 81 (modules for HOPE))
89 :     Look also at MacQueen 81
90 :    
91 :     CLEAR specification language Goguen & Burstall (functor & abstractions models/theories)
92 :     Maude descended from OBJ from CLEAR
93 :    
94 :     Siek on multiple inheritance
95 :    
96 :     int -> int
97 :     \/a.a->int \/b.int->b
98 :     \/ab.a->b
99 :    
100 :     sig
101 :     structure M:S0
102 :     structure N:S1 where type t = int
103 :     end
104 :     union
105 :     sig
106 :     structure M:S1
107 :    
108 :     Idea: use where clause to explicitly reconcile types in include
109 :    
110 :     Category-theoretic embedding of signature in sig (category of interfaces)
111 :    
112 :     sig S0 U S2
113 :    
114 :     semantics of CLEAR OBJ family

root@smlnj-gforge.cs.uchicago.edu
ViewVC Help
Powered by ViewVC 1.0.0