Subject: Re: Cecil problems
From: Vassily Litvinov (vass@cs.washington.edu)
Date: Thu Feb 21 2002 - 12:13:20 PST
Marcin,
This is not exactly a timely response, but let's see if I can answer some
of your questions.
On Wed, 9 Jan 2002, Marcin Lostowitz wrote:
>
> Hello,
>
> My name is Marcin and I'm working as a programmer in Poland. I from time-to-time teach young people
> programming languages and methodology. I encountered much information about Cecil language and I read
> several articles on this topic. Cecil is interesting since its semantic mechanism not existing in other programming
> languages. Unfortunatly, this is the most mysterious language since Algol68 terminology days!
>
> I have some background on similar topic: Sather, Eiffel, and partialy Dee. I know what the dynamic dispaching,
> multimethods, predicates, prototype-based, covariant and contravariant mean, but still have trouble with simple
> understanding the relation of static typing to dynamic dispatching in Cecil.
>
> Well, have some stupid questions:
>
> 1. Why separate hierarchies of classes (inheritance) and typing?
There are some programming idioms (such as "binary methods", see, for
example, Bruce et al, "On Binary Methods." Theory and Practice of Object
Systems, 1(3):217-238, 1995) where it has been suggested to make
inheritance different from subtyping in order to achieve static
typechecking. While many traditional languages do not offer this kind of
facility, Cecil made it available to programmers for added expressiveness,
to allow such suggestions to be carried out and tested.
However, Cecil also includes other expressive type system features (such
as parametric F-bounded polymorphism) which, in our experience, obviate
the need to have inheritance diverge from subtyping in such cases. But
then we anticipate that with a real module system we will need this
facility again. For example, we'd like to keep subtype relation between
stack (or queue) and m_list in the Cecil standard library private to the
modules that define these datatypes -- and not visible outside, while
making inheritance between these classes universally visible.
> Or what is the difference between notion of Java
> interface to Cecil type hierarchy?
Java interface corresponds to a type in Cecil for which there is no
corresponding implementation object. For example, in the Cecil standard
library you can find "interface" types extension_evaluation_env and
runtime_extension_method in env.cecil; there are more examples in the
Vortex compiler, notably in its inter-procedural analysis framework.
You can see, say, in bc-cinterp.cecil, how these are used:
template object bc_frame subtypes extension_evaluation_env isa evaluation_env;
meaning that bc_frame type subtypes both extension_evaluation_env and
evaluation_env types, while bc_frame implementation object only inerits
from evaluation_env (there is no extension_evaluation_env object).
> 2. Is Cecil covariant or contravariant ? I know that non of them, but do not understand why.
Cecil has built-in co/contra-variance rule for closure types (such as
&(T1,T2):T3). Specifically, a closure type is contravariant in its
argument positions and covariant in its return position:
&(T1,T2):T3 subtypes &(S1,S2):S3
if
S1 subtypes T1, S2 subtypes T2 (contravariance) and
T3 subtypes S3 (covariance)
Cecil provides no other built-in co/contravariance. The users are free to
declare co/contravariance for their own types. You can see such
declarations (grep for "extend type"), for example, in pair.cecil
(covariance of immutable-container datatypes pair, triple, quadruple) and
in comparable.cecil (contravariance of F-bounded types comparable,
ordered, etc.).
Of course the job of the typechecker is to ensure that covariance and
contravariance is used soundly. This check is specified in our OOPSLA'98
paper, but Vortex currently does not implement it. In Eiffel they had to
come up with some check to ensure that their always-covariant rule is not
abused, but I think that check is not done in practice.
> 4. When I say:
> object int_rep inherits any
> object int_rep conforms int
>
> foo( x@int_rep:int) and foo( x@:int)
> are equivalent?
No, because the second method header is equivalent to foo(x@int:int),
whereby the argument dispatches on int. In the first method header the
argument dispatches on int_rep, thus it will be applicable to a different
set of objects.
While typechecking the body of the method, in both cases x will be
considered of type int.
> 5. A descendant class can have other type than its ancesor (superclass)?
Yes. This is exactly what your Question 1 addressed, if I understand it
correctly.
> Or can I see any readable source code in Cecil?
Ah yeah, you should go to our release page:
http://www.cs.washington.edu/research/projects/cecil/Release/
and download "Cecil front-end". It include the source code for Vortex,
including the Cecil standard library to which I referred above.
It's good to see that you are interested in Cecil. Please email us if you
have more questions. Good luck!
Vassily
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://majordomo.cs.washington.edu/mailman/listinfo/cecil
This archive was generated by hypermail 2b25 : Thu Feb 21 2002 - 12:14:07 PST