Paste: how to sub-type in clay

Author: guest
Mode: text
Date: Tue, 19 Oct 2010 05:37:06
Plain Text |
first i must distantiate myself from being a crack in clay. i am rather the functional guy with oop-experience. possibly all of the below is nonsense. please teach me a better insight!

common programming languages base on the idea of providing very basic types to derive from them. derivates are commonly layed out by using compound types (arrays, records, structs...). but there is a special case that is not well focused by most programming languages. often a set of types is so homogenous that implementing the types - and the necessary api's - individually would be overkill. instead, a basic container type stores the higher types as data sets, as if they were virtual types. simple examples are multidimensional versions of types or basic template types etc.

the virtual types are mainly treated via the real type's api, except of case-wise extensions. this api must do runtime checks for orientation, causing speed loss but also memory overhead because the meta-data. runtime checks can't securely detect specific (accidential) alterations of the meta-data, like when a virtual type's identity was overwritten.

in clay the situation should be far better because of strong typing and compile-time predicates. the compile-time evaluation should allow more subtle distinction than in primitive languages, and it generally does. however, clay doesn't seem to have a clever strategy for, say, sub-typing. the only way known to me to make the virtual types distinct at compile-time is to extend them to real types. this strips the original interfaces and thus compatibility, which can be re-gained by redundant or complex forwarding.

i wish to see sub-typing in clay - without relying on more complicated strategies like inheritance. one possible way is to extend "versions" of an original type by sharing an internal pointer to the original type's predicates and interfaces and downgrading the types to the original type when following the pointer. another solution is "tagging" of instances of the original type to make them distinctable via a predicate like isTagged?(T,Tag) without extending a new type and stripping all original interfaces. the only problem (except of implementation) is that an extended api should be able to inline and overgive values to overloaded original functions. one solution to the latter is to "hide" the tag via a special function like in index(noTag(x),12). the instance will find its way down to the original function, i guess.

possibly there is an even easier way but i don't know any.

what do you think?

New Annotation

Summary:
Author:
Mode:
Body: