Paste: how to sub-type in clay

Author: guest
Mode: text
Date: Tue, 19 Oct 2010 05:39:19
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?

Annotation: Re: how to sub-type in clay

Author: ksreeram (cited by guest from chat log)
Mode: text
Date: Tue, 19 Oct 2010 12:16:03
Plain Text |
guest, I understand sub-typing is a popular feature in many 
other programming languages, but Clay doesn't have it. I 
personally find sub-typing to be an unsound feature in the 
presence of mutation. And, mutation is definitely a far more 
important feature than sub-typing. If you do have a very 
practical and concrete use case for sub-typing where Clay's 
other features don't suffice, then I will think about it.

Annotation: Re: how to sub-type in clay

Author: guest
Mode: text
Date: Tue, 19 Oct 2010 13:28:52
Plain Text |
i think that you both don't hit the point. yes, qx, i agree 
that extending the vector type is not a good idea. but, if 
you remember, i first asked you about the existence of 
isAlias?() before i tried to derive a MultiVector (in face 
of not having a different solution.)

ksreeram, i guess that i can't show you a 'very practical 
and concrete' use case (to just fill a gap in the language)
because the types i'm talking about are generally 
understood as being patterns, and thus data, rather than 
types. in oo-languages they could be derived classes but 
that's a different point. the point is that i don't know 
how to use the powers of compile-time predicates on 
patterns.

patterns are no types in terms of programming languages 
though they are handled very similar - at runtime. think of
basic polygons for drawing or of basic text templates 
with placeholders for quick website creation. all these
'types' of patterns have one thing in common: they very 
often fit into a simple storage type, profit from its given
interface and only need a small selection of extra handlers.
only because they must be distinctable and configurable 
they are rather implemented as own types or as pure data 
accompanied with meta-data and stored in a struct. however, 
that's not the generic way.

in clay, i'd implement the pattern types and the 
configuration types separately because the configuration 
types (for color etc.) can also be used generically. the 
only left 'redundancy' is the identifier. that's the point. 
if i could turn that identifier into an alias and check for 
it with isAlias?(), the struct could be dropped, and 
overloading the storage-type interface would do the job -
at compile-time. this is the efficiency i want to gain from 
clay. otherwise i'm forced to create runtime overhead 
without a hard reason.

if you know a better way to reach this goal, i'm fully open.

New Annotation

Summary:
Author:
Mode:
Body: