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

SCM Repository

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

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 3564 - (download) (annotate)
Thu Sep 30 13:33:05 2010 UTC (8 years, 10 months ago) by dbm
File size: 2799 byte(s)
initial import
Ideas

* static "effects"
  - sealing and generativity (fresh types)
  - reln with nominal typing

* conflict between HO functors (type functionals) and ...

* clean semantics of "true" HO functors 

* signature calculus
  - ordering, merging, extension, restriction
  - signature functions

* recursion in a module system (RMC?) [self recursion unnecessary]

* comparisons
  - Scala, Dreyer/Rossberg mixins, OO class mixins, problem of open recursion

=> towards a successor ML

* pragmatic principles of module system design
  transparency, "obviousness", declarative semantics

* boundary between core type system and module system
  - extent to which module system can be "abstracted" over core type system

signature S0 = sig type t end
signature S1 = sig type u type v end
signature S2 = S0 andalso S1

signature S2' = S0 andalso (S1 as S moving S.u => S.t)
why do we need "as"?

Terms
------

Generative: fresh abstract types each functor application no matter what the argument is

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

- how to define module equivalence

True HO: 
  functor Apply(functor F(X:sig type t))

Apply(F,X) = F(X)
Apply(F,G,X)  = F(G,X)

functor Apply(functor F(X:S):S, structure A:S):
  sig type t = F(A).t end

module LiftProd = 
  functor (X: sig type t end) -> struct type t = X.t * X.t end

module H =
  functor (G:functor (X:T)->T)
    -> struct
         module Apply =
           functor (X:sig 
                        module F:FS
                        module M:T
                      end)
                   -> X.F(G(X.M))
         module R=Apply(struct
                          module F=Id
                          module M=struct type t = unit end
                        end)
       end

include S0 include S1

include S0 
include S1
versus
structure M0:S0
structure M1:S1
sharing type M0.t = M1.t
open M0 M1

alternatively Limited Shadowing Semantics

terminology: mergeable, compatible, signature consistency 

How does that relate to realizability, inhabitability of a signature and general type inhabitability

There is also the category of signatures (universal algebra)
Goguen before OBJ (LISP conference 81 (modules for HOPE))
Look also at MacQueen 81

CLEAR specification language Goguen & Burstall (functor & abstractions models/theories)
Maude descended from OBJ from CLEAR

Siek on multiple inheritance

    int -> int
\/a.a->int   \/b.int->b
      \/ab.a->b

sig
  structure M:S0
  structure N:S1 where type t = int
end
union
sig 
  structure M:S1

Idea: use where clause to explicitly reconcile types in include

Category-theoretic embedding of signature in sig (category of interfaces)

sig S0 U S2

semantics of CLEAR OBJ family

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