COP 4020 Lecture -*- Outline -*-

* Abstract data types (3.7)

** definition and examples 

------------------------------------------
        ABSTRACT DATA TYPES (3.7)

def: A *data type* or *type* is
     a set of values
     with a set of operations on them.

Examples: Integers with +, -, *, div, ...
          Bool with Not, And, Or

def: An *abstract data type* or ADT is
     a data type 


------------------------------------------
        ... whose behavior is completely specified.
            (in the sense that all and only the implementations with
            that behavior are correct)

     Q: How is an ADT different from a data type specification?
        It isn't. An ADT really *is* a specification.

------------------------------------------
           1 INCH = 1 MILE?

     ^^^^^^^^^^^^^)
   (  Abstraction  )
   (   1/2          )
   (        3/4    )
    (uuuuuuuuuuuuu)

          ^
          |
          | Abstraction Function
          |
          |
   |------------------|
   | [1 2]   [6 8]    |
   |------------------|
------------------------------------------


*** stacks (3.7.1)
------------------------------------------
        DECLARATIVE STACK (3.7.1)

Signature:

 NewStack: <fun {$}: <Stack T>>
 Push: <fun {$ <Stack T> T}: <Stack T>>
 Pop: <fun {$ <Stack T> T}: <Stack T>>
 IsEmpty: <fun {$ <Stack T>}: <Bool>>
------------------------------------------

   Q: Which are observers?
   Q: Which construct new stacks?

   How can we tell?  it's the declarative model...

------------------------------------------
          EXAMPLES USING THESE

declare
fun {StackSize Stk}
   if {IsEmpty Stk} then 0 else 1+{StackSize {Pop Stk _}} end
end

fun {StackElements Stk}
   if {IsEmpty Stk} then nil
   else local E Rest in
           Rest={Pop Stk E}
           E|{StackElements Rest}
        end
   end
end

fun {StackEqual S1 S2}
   {StackElements S1} == {StackElements S2}
end
------------------------------------------
        See StackTest.oz

------------------------------------------

Specification
 forall E:T, ST: <Stack T>:

  {IsEmpty {NewStack}} == true
  {IsEmpty {Push ST E}} == false
  {StackEqual {Pop {Push ST E} _} ST}
  
  local Y in _={Pop {Push ST E} Y} Y end == E
  

  try 
     _={Pop {NewStack} _}
     false
  catch _ then true
  end                     == true
------------------------------------------

     This specification technique, saying what all the observers do on
     all the constructors, is described by Guttag and Horning's
     article "The Algebraic Specification of Abstract Data Types",
     Acta Informatica 10(1):27-52, 1978.

     Q: What's going on with Pop?
        it's last argument is an output!
        So it has two outputs.

        The authors call this the "functional look",
            which means it looks like a function but isn't.

     Q: What do these last two equations mean?

     Q: What's an implementation of Stack that satisfies these specifications?
     Q: What's another one?

     Q: How do we specify that this is persistent?
        ... state that can push or pop the same stack again

*** A non-free type, Sample

------------------------------------------
      HIDDEN DATA WITH AN INVARIANT

Signature:
 NewSample: <fun {$ <Int> <Int> <Int>}:
                 <Sample>>
 Average: <fun {$ <Sample>}: <Float>>
 Median: <fun {$ <Sample>}: <Float>>

Specification
   for all I, J, K, L: <Int>, F: <Float>:

 try
   {Average {NewSample I J K}}
 catch X then F end
   == if 0 =< I andthen I < J
         andthen J < K
      then {IntToFloat I+J+K}/3.0
      else F end

 try
   {Median {NewSample I J K}}
 catch X then L end
   == if 0 =< I andthen I < J
         andthen J < K
      then J else L end

------------------------------------------

    Q: Suppose Inc is a value of type <Sample>, what can we say
       about {Average Inc} and {Median Inc}?
    That 0 =< {Average Inc} and 0 =< {Median Inc}
    This is an *invariant*.

    Q: Using only the operations on a value Inc of type <Sample>,
       can one figure out what the 3 arguments to the constructor are?


------------------------------------------
    Q: What are two possible implementations of this ADT?





------------------------------------------

    Invariants are also used in implementations...
    What are the invariants in these implementations?

    Q: Can someone figure out what the 3 arguments to the constructor
       are if they know how the implementation works?

*** dictionaries (3.7.1) (skip)

------------------------------------------
          DICTIONARIES (3.7.1)

Signature:
 NewDictionary: <fun {$}: <Dict>>
 Put: <fun {$ <Dict> <Feature> <Value>}:
           <Dict>>
 CondGet:
     <fun {$ <Dict> <Feature> <Value>}:
          <Value>>
 Domain: <fun {$ <Dict>}:
               <List <Feature>>>

where 
  <Feature> ::= <Atom> | <Integer>


Specification:

 {Domain {NewDictionary}} = nil
 {Domain {Put D F V} = F|{Domain D}
 {CondGet {NewDictionary} F V} = V
 {CondGet {Put D F V} F V2} = V
 {CondGet {Put D F V} F2 V2}
     = {CondGet D F2 V2}
 

------------------------------------------
        explain what these do

        Q: What would be an implementation?

        See the book for (a description of)
        3 implementations and a performance comparison.

** security (3.7.4)

*** problems
   Q: What kinds of problems could happen if
      an ADT is implemented as a collection of functions?

      discovery: access to components without use of ops
      impersonation: some object not created by ops acts as if it was.

      (See Morris's 1973 article in CACM on seals)
------------------------------------------
          SECURITY OF ADTS

Want to prevent:

   alteration = 


   discovery =


   impersonation =



-- James Morris, 1973


Encapsulation = 
   all code for an ADT is in one place
------------------------------------------

    ...	alteration = change of state without use of operations
	discovery = access to components without use of ops
	impersonation = some object not created by ops acts as if it was.

    Q: Why is alteration a bad thing?
        can't count on invariant
        
    Q: Why is discovery a bad thing?
        hurts maintenance

    Q: Why is impersonation a bad thing?
        can't count on invariant

    Q: Are the ADT implementations we've seen so far secure?

       Can't be altered in the declarative model.
       But consider the type Sample...

    Q: What's the connection between encapsulation and maintenance?
       easier if encapsulated

    Q: What's the connection between encapsulation and security?
       encapsulation prevents both
           maintenance problems
           and invariant problems

    Q: What's an open program?
       A program that runs some (untrusted) code loaded at runtime
    Q: Why is that a problem for security?
       The loaded code might try to steal secrets and forge data
       (discovery and impersonation)

*** solutions (3.7.4-5)

    Q: What are general approaches to securing your cell phone?
       stationary value: keep it hidden (don't let anyone else use it)
       mobile value: have a password, only your friends know it

       Who can you blame if something bad happens? you and your friends

    One way is to implement Morris's seal operation directly.
    This is what's done in Oz...

**** names (3.7.5)
------------------------------------------
     NAMES TO PROTECT VALUES (3.7.5)

Signature of Value type:

 NewName: <fun {$}: <Name>>
 == : <fun {$ <Name> <Name>}: <Bool>>

Specification:

 ({NewName} == {NewName}) = false
------------------------------------------

     Q: Is NewName referentially transparent?
     No

     Q: Is this possible in the declarative model?
     No, it's a real extension.

------------------------------------------
      WRAPPING AND UNWRAPPING

proc {NewWrapper ?Wrap ?Unwrap}
    Key={NewName}
 in
    fun {Wrap X}
       {Chunk.new w(Key:X)}
    end
    fun {Unwrap W}
       try W.Key
       catch _ then
         raise error(unwrap(W)) end
       end
    end
 end
------------------------------------------
        See NewWrapper.oz

        Chunks are read-only records.  They also have to be added to
        the kernel language...

------------------------------------------
           SAMPLE AS A SECURE ADT

declare
local Wrap Unwrap in
   {NewWrapper Wrap Unwrap}
   
   fun {NewSample I J K}
      if 0 =< I andthen I < J
	 andthen J < K
      then
	 {Wrap
           sample(average:
                   {IntToFloat I+J+K}/3.0
		  median: J)}
      else
	 raise badArguments(I J K) end
      end
   end

   fun {Average Sample}
      sample(average: AV ...)
           = {Unwrap Sample}
   in
      AV
   end

   fun {Median Sample}
      sample(median: MV ...)
         = {Unwrap Sample}
   in
      MV
   end
end   

------------------------------------------
                See SampleSecure.oz

        Q: How does this prevent discovery? Impersonation?

           Really need cryptography to make sure can't be forged

        Q: Can you write Stack using NewWrapper?

**** protecting undetermined variables

     Q: Does wrapping protect undetermined variables?
        No, e.g., streams, which are lists with undetermined variable at end.

------------------------------------------
    READ-ONLY VIEW OF VARIABLE (FUTURES)

!!X  means X, which can only be read from

------------------------------------------
     (These views are also called "futures")

     Q: What does read only mean in the declarative model?

        Can't bind it

     Q: How to implement this?

        !!X generates a new location in store,
            that location is in a special "read only part"
            return that location,

            modify bind operation:
                suspends on read of read-only location
                     until it's determined

     (Can test if something is a future using IsFuture)

*** capabilities (3.7.7)

    names are a special case of a "capability"

    A computation is *secure* if "it has well-defined and controllable
    properties independent of the existence of other ... entities"

------------------------------------------
          CAPABILITIES (3.7.7)

def: a *capability* is
     an unforgeable entity
     with an associated set of rights
------------------------------------------

   Q: How could we represent rights?

      as procedures

   Q: How can we implement the principle of least authority using
      capabilities? 

      Only give out capabilities as needed