Gilad Bracha's pluggable types

adda/gilad`pluggable types
summary:
12.26: varieties of encapsulation?
Typical language semantics depend on the type system
(e.g., casts, overloading, accessibility).
By eliminating this dependency,
we can make our languages more modular.

Class-based encapsulation
(relies critically on complex and fragile
typecheckers and verifiers)
-- very popular, but inherently less secure than
object-based encapsulation
(enforced only by context-free grammar).
Typecheckers are tricky and often buggy;
whereas, parsers are well understood.
--. optional typing simplifies language design,
to the benefit of the system as a whole.

12.27: understanding the concept:
. how can types be optional in smalltalk
when in fact smalltalk has an inheritance hierarchy?
aren't oop classes acting as types?
. oop typing is by definition "(optional);
because, it depends only dynamic typechecking .
. manditory typing (vs optional) is when
the code won't compile until after
the static typechecking system has verified
(by analyzing declared types and compatible assignments)
that any future object can handle
any of the messages they may be sent;
whereas,
smaltalk's oop never assumes future knowledge;
rather, every function call consists of
sending the object the name of the message,
and then that object can verify for itself
-- before accepting the current call --
whether it can handle a message of that name .

. the main idea of pluggable types
is that while smalltalk oop's
dynamic typechecking is a great idea,
static analysis has additional value
-- both can coexist together .
. a lang's type declarations are optional
when the lang's compiler can generate code
regardless of whether
the type declarations exist .
. type declarations are pluggable when
when developer tools support multiple
static type declaration analyzers;
a test run consists of
first sending the code to the current analyzers;
if there are no warnings,
then the code is sent to the compiler .
. given some warnings, the developer can still
opt to compile the code anyway,
which will run until at least until caught by
any run-in's with dynamic typechecking .

12.11 ... 12.12: news.adda/gilad`pluggable types:
. I found pluggable types mentioned in
a comment on a forum where Mark S. Miller
explained why capabilities rule and ACLs drool:

"(. Gilad, in his Pluggable Types manifesto,
talks about serialization as part of his
justification for why the vm's execution
shouldn't depend on types . )
-- z-bo
"(... the software systems equivalent of
Padlipsky's The Elements of Networking Style...
demonstrating why, in the software industry,
everything we do today is moronic and monolithic.)

ppt for bracha`pluggable-types.pdf:
. static type is characteristically mandatory;
types should instead be optional;
a paradox of using type systems for
reliability and security
is that while they can
mechanically prove properties,
they are making things complex and brittle;
eg, type systems for vm and lang collide .

. persistence works best with structural typing;
whereas, nominal typing (declared by a type name )
forces the serialization
(a subsystem for persistent filing)
to separate objects from their behavior;
it can't tolerate a type's name being
associated with more than one impl' .
[12.27: well,
that's why there are class clusters,
where the type mgt declares a std format
for all member types to file their state as .]

12.12 ... 12.13: gilad's complete paper:
Gilad Is Right:
. the talk notes need backing by this paper:
pico.vub.ac.be/~wdmeuter/RDL04/papers/Bracha.pdf
(found here)
class-based encapsulation
vs object-based encapsulation ? ...
. Class based encapsulation.
class C
{ private secret.int
; public expose( c.C).int { return secret;}
} -- there is no way to know
when access to encapsulated members is allowed
without a (prohibitively costly) dynamic check.
Instead, use object-based encapsulation,
as in Smalltalk or Self .
[12.26:
. keep in mind he's talking about
merging dynamic with static typing;
object-based encapsulation? how about:
"Object-Oriented Encapsulation for Dynamically Typed Languages":
"( Encapsulation in object-oriented languages
has traditionally been based on static type systems.
As a consequence, dynamically-typed languages have
only limited support for encapsulation;
this paper is bringing encapsulation features
to dynamically typed languages.) ]

[12.27: the point of the example of
class-based encapsulation
was showing how it allowed for declaring
-- in the interface (vs class body) --
the body of an accessor
that accessed an instance var;
whereas proper interface-body separation
doesn't allow any assumptions about
what an interface entry does with privates .]

. using the assumptions of smalltalk oop,
a method can be accessed without knowing
the obj's type or class;
ie, if it doesn't support that method
then it simply returns nil,
or otherwise raise a not-supported.exception .

. overloading functions implicitly requires
nominal typing of function parameters;
not good ...
bewildered? a concrete example is strongtalk!
(originally at www.cs.ucsb.edu/projects/strongtalk)

12.26: complete text (found on his site):
Pluggable Type Systems Gilad Bracha October 17, 2004

12.26: Strongtalk`history:
Dave Griswold was frustrated with the fact that
there were still a lot of obstacles to using Smalltalk
in most kinds of production applications.
. it was still way too slow, [but simple]
had poor support for native user interfaces
(but portable)
and lacked a [static] type system,
which although it makes the language flexible,
also means large-scale software systems
are a lot harder to understand .
. by 1996 the system was transformed
by Urs Hölzle's speedy compilation technology,
and Gilad Bracha's type system for
programming-in-the-large;
but then the Java phenomenon happened;
years later, Sun finally open-sourced Strongtalk .

New repository location for Strongtalk 4 Oct 2010
new repository location on github
You will also find the first steps on a
Newspeak port on branch nsreboot.

strongtalk overview:
. the type system is not concerned with
improving execution performance,
since it is based on interface types.
Optimization requires concrete
implementation type information.

key characteristics of the Strongtalk type system are :
* allows natural Smalltalk idioms to be typechecked:
1. Separates the subtype and subclass lattices.
2. Includes parameterized types and classes.
3. Supports parametrically polymorphic messages,
with a flexible mechanism for
automatically inferring actual type parameters.
4. Supports both subtyping and type matching.
6. Provides facilities for dynamic typing.

5. Preserves the subtype relations between classes
defined by the Smalltalk metaclass hierarchy
and relates them to the types of their instances.
A protocol is a collection of message selectors
and their associated signatures;
Every class C automatically induces a protocol,
The type hierarchy is defined using protocols.

* The system provides the same kind of
reflective access to type information
as Smalltalk does to other language constructs.
Note that if a program does access
type information reflectively,
then by definition its behavior is dependent on
the type annotations in it.

Strongtalk supports two relations on types:
# Subtyping (substitutability):
an element of a subtype can be safely used
wherever an element of a supertype is expected.
# Matching (common pattern of self reference):
. Every protocol definition specifies its supertypes.
Likewise, a class definition can specify
the supertypes of its protocol.
By default, a protocol is declared to be
a subtype of its superprotocol.