A simple, powerful, efficient typesystem

[Francois-Rene Rideau]

>>> Types -- roughly a C++ class
>>> Interfaces -- an abstraction that states how an instance of a type may
>>>               be implemented.
>>> Views -- A mapping between the functions of a type, (possibly also of
>>>          data) and the expected layout of an interface.
>
> A quick rephrase.  An interface in my terminology I meant like
> something out of group or field theory.  Where you define what you can
> do with a type but not what type type is.  I.e. it's operators and
> perhaps some of their characteristics.
>
> The View does the mapping between the functions that actually
> manipulate types, and the interface's which are what we manipulate
> them with (at least when we want genericity).


> My enthusiasm for this is that in the worst case it can be implemented
> with approxiamently the same efficiency as C++ only degrading
> slightly.


>>[To my Type/Functor way of saying things]
> I have no limit that I know of to date in this scheme.
   Well, I think our two formulations are almost the same.
What you call "types", I call them concrete types,
and make them implementation dependent instead of a language feature
(though separate standards for implementations should provide them).
   What you call "interfaces" I name "types", or "abstract types",
(perhaps "module" would suit better, after the ML tradition).
Such an interface is a set of named slots, corresponding to
constructors/accessors/destructors/whatever for the type,
whose bound objects must verify some declared properties.
   Concrete types are a particular case of types to the programmer;
the only difference is that a given implementation makes them basic.
   I call "functor", after the ML tradition,
a higher-order function that takes types as parameters and yields new types.
   I'm not sure what you call "view", but I think you mean a couple
of an abstract type and an object of the given type.
   Your definition of "view" implies the application of functors
(though not forcibly functors being first-class citizens).
   I just hope we won't be fighting with terminology for too long ;-)


>>> The only penalty for this method of organization is that object
>>> pointers are twice as big (unless you seperate views from objects ?)
>> I'd definitely say separate views from objects. A same object can
>> be viewed in several ways, and a same set of abstractions should be
>> used to manipulate several objects.
>
> OOPS ( I meant seperate views from object pointers!!!!!)
>
> The implementation in g++ has them as second class citizens hiding
> behind the scenes and doing all of the dirty work.  They are bound to
> the reference of to an object.  Whether that binding should be relaxed
> was my question.  Sorry.
   My feeling is that C++ mixes up too many things,
and has a too inexpressive type system,
so that C++ programmers learn complicated techniques
to circumvent its braindead design.
   If our "views" are a couple of a (level-n) object and a (level-n+1) context
in which to manipulate it,
then object references are (level-n) objects themselves,
and views on references are a couple as above.
When you follow an object reference, you get no particular view on the
referred object, unless it's an *explicitly reflective* object.
However, when you follow *a view* on an object reference,
you automatically get *a view* on the referred object,
the context most likely being essentially (if not exactly) the same
as for the original object, unless somehow specified otherwise.


> What I meant was in a situation where all you know about an object is
> that it conforms to interface y,  interface y happens to be compatible
> with interface z with appropriate mappings.  z & y grew up in
> different neighborhoods.  Then to view the object as a z you need to
> create a new view, from the view of it as a y.   This is not the same
> as in C++.
   Ok. Building a view from other ones is precisely what I called functors.
Now, I don't quite get the difference to you between "Views" and "Interfaces"
(which I both called "types", what you called "types" from C/C++ being
particular implementation-dependent concrete types to me).

--    ,                                         ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
                 TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"