On Tue, 2007-05-01 at 20:54 -0400, Chris King wrote:
> On 5/1/07, skaller <[EMAIL PROTECTED]> wrote:
> > ** In the end, i hope to merge classes, typeclasses
> > and modules into a single 'class' construction.
>
> Yay!
>
> > typeclasses with variables (not just type variables)
> > make sense .. the functions are just methods and the
> > variables live in an dynamically created object.
> >
> > Woops.. that's just OO! And also .. it's dependent
> > typing!
> >
> > For example
> >
> > typeclass Array[t] {
> > val len: int;
> > ..
> > }
> >
> > would make 'len' the dynamic length of the array.
>
> Hm, I had thought about this once too, but thought instead of adding
> immutable values to typeclasses... the functions associated with
> typeclasses are immutable so it doesn't seem consistent to me that
> variables should be. Immutable values would be useful for e.g.
> constants in numerical classes. IMHO things like array length or
> other "instance variables" should be associated with the value itself,
> e.g.:
>
> typeclass Array[t] {
> val len: t -> int;
> ..
> }
>
> This is no different than most OO schemes. Is there something I'm
> missing that makes mutable typeclass variables more expressive than
> "get/set"-style functions?
'val' are immutable .. well from the programmers viewpoint
they're supposed to be.
The code I wrote above was crappy. At present a typeclass is
a class except all the methods are 'static': there's no object.
But for array, we don't want a static value such as 'pi'
in a floating point typeclass, but a *dependent* value.
For functional types, eg list of particular length,
the length isn't mutable because the type isn't,
but it is *variant*.
Just to explain this another way: Felix has
t ^ n = t * t * t ... t
// n times
where n must be an integer literal, interpreted as a unit sum,
for example:
3 = 1 + 1 + 1 = unit + unit + unit
Now the problem is you can't write a polymorphic concatenation
routine:
fun cat(x: t ^ n1, y: t ^ n2) => ...
because the result is type
t ^ (n1 + n2)
but n1 + n2 is not a literal integer. In fact, we really
want one piece of code, with the length being determined
at run time. For code like
zip: t ^ n * u ^ n -> (t * u) ^ n
you would elide the run time check the two lengths
are equal by proving it. More precisely the function
would only WORK if the length types were known to
be equal, and you'd use an explicit checking coercion
to ensure this (which would do a run time check).
Anyhow the point is that the array type t ^ n isn't
that useful because without dependent typing (or GADTs)
the n has to be known literally and can't be operated on.
Note that Felix CAN calculate _flatten$ 2 + 3 = 5,
but that ONLY works when the arguments are literals
or the result of another _flatten -- it doesn't
work for n, where n is a type variable.
Fact is .. the constraint that n is a unit sum can't
even be expressed, let alone represent polymorphic
addition of them .. ;(
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
