On 07/09/2012, at 3:18 AM, Dobes Vandermeer wrote:
> On Thu, Sep 6, 2012 at 7:45 AM, john skaller <skal...@users.sourceforge.net>
> wrote:
> I did some more work and got this to go:
>
> class Applicable[A,D,C] {
> virtual fun myapply : A * D -> C;
> }
>
> What if you declare it like this:
>
> virtual fun myapply : (A -> B) * A -> B;
>
Works fine but the argument can't be a tuple of functions, because a
tuple of functions isn't a function.
It's quite easy to make something (in the compiler) that works
for an actual tuple of functions:
(f,g) (a,b)
is easy to make work. Even this is easy to make work:
var F = (f,g);
var A = (a,b);
F A
As long as the types are manifestly tuples its easy. The problem is when the
type
isn't manifestly a tuple at binding time. This happens inside a polymorphic
function.
Consider for example:
// Class Eq: Equality
instance [T,U with Eq[T], Eq[U]] Eq[T ** U] {
fun == : (T ** U) * (T ** U) -> bool =
| (?ah ,, ?at) , (?bh ,, ?bt) => ah == bh and at == bt;
;
}
and suppose we want to return a tuple of bools instead of folding
equality over the argument tuples (with "and").
instance [T,U with Eq[T], EqVector[U]] EqVector[T ** U] {
fun == : (T ** U) * (T ** U) -> bool ** ????? =
| (?ah ,, ?at) , (?bh ,, ?bt) => ah == bh ,, at == bt;
;
}
See, I don't know the type ????. It's just a tuple (array) of bools so perhaps:
bool ^ N will do.
instance [T,U,N with Eq[T], EqVector[U,pred N]] EqVector[T ** U,N] {
fun == : (T ** U) * (T ** U) -> bool ^ N =
| (?ah ,, ?at) , (?bh ,, ?bt) => ah == bh ,, at == bt;
;
}
I really want to say this:
generic_map == (zip a b)
so inside the above function I want to write:
ah == bh, generic_map == (at,bt)
but the problem is at, bt have type U which isn't manifestly a tuple.
Clear as mud, sorry.
The problem arises because type classes CHEAT.
They allow you to make functions which pretend to be polymorphic for
the purpose of binding, but which actually have a constraint: the existence
of overloads to be found in instances. So you can bind a virtual function
to types which do NOT have the required overloads, which lets your
program bind.
The cheat may be discovered at instantiation time and then your program bugs
out. Because we're cheating on the "applicative tuple of functions" we can't
deduce the return type because the argument just has some type F: we have
to TELL the binding logic the return type. At binding time we don't know F is
a tuple of functions. It could be a string! It will still bind. Given:
class Applicable[A,D,C] {
virtual fun myapply : A * D -> C;
}
Applicable[A,D,C]::myapply
can apply ANY data type to ANY data type.
In particular given
open class Mutable [F, A] {
virtual proc mutate: F * A -> unit;
}
"Hello" 3.2;
will bind. It may not instantiate. This one, we can easily do with the
tuple consing stuff, i.e. "generic iterate" because we actually know
the return type.
This is why the generic "str" on tuples works.
The point is the generic tuple of functions considered as a function
actually works .. you just have to tell the return type (and, because of the
order of type variables in the class the tuple of functions type and argument
type as well).
Deduction of types, including the returns types, happens at binding time,
but the tuple consings stuff only resolves at instantiation time.
The lame solution is what you'd do in Java or Python. Do both the iteration
and type checking at run time. Then if you mess up you get a run time
type error. This is an example of why people use dynamic typing:
because they can't figure out how to make polyadic type systems work.
It's a cop out. The problem here is that type classes are the wrong mechanism.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
