A simple, powerful, efficient typesystem
Wed, 24 Apr 1996 17:16:18 +0200 (MET DST)
>>> 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
>>[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 -- firstname.lastname@example.org -- 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/"