On Thu, Jan 8, 2015 at 4:31 PM, Keean Schupke <[email protected]> wrote:
> This has nothing to do with instance coherence, I was just trying to improve
> on the global state in the earlier example.
>
> Actually I'm all for passing runtime state as part of the comparison
> function, did you see the c++ signature for sort I posted earlier, that
> would default to a function (defined on the value-type of the iterator, so
> behaving like a type class) unless a function-object was passed in.
>
> My point is that typeclasses have no constructor/destructor, so they should
> not have state. A function-object is the correct place for the state.
>
> Here is the C++ definition again:
>
> template <typename R, typename F>
> requires RandomIterator<R>, Ord<typename R::value_type>
> , BinaryOperator<F>, Argument<F, 1, typename R::value_type>
> , Argument<F, 2, typename R::value_type>, ResultType<F, bool>
> void sort(R first, R last, F cmp = compare<typename R::value_type>) {
> ...
> }
Apologies for missing this earlier. However, doesn't this require an
object to have an Ord instance in order to allow a function object to
be passed in. That is, if you want to use a function object, you need
to specify two orderings, one of which is ignored?
> I think there should be some unification between records and type-classes.
> Coherence is not a problem for values, only for resolution of type-classes.
> Imagine we can lift records to type-classes:
>
> data Ord x = Ord {
> (<) :: x -> x -> Bool
> }
>
> int1 = Ord {
> (<) = \x y -> primitive_int_less(x, y)
> }
>
> int2 = Ord {
> count = 0;
> (<) = \x y -> do
> ++count
> return primitive_int_less(x, y)
> }
>
> l =[5, 4, 3, 2, 1]
>
>
> printStrLn $ sort i int1
> printStrLn $ sort i int2
>
>
> using int1
> printStrLn $ sort i // implicit parameter gets int1
>
> using int2 // error incoherent
>
>
> To me emulating type-classes with records and implicit parameters solves all
> the problems, as long as you have to bring instances into dynamic scope.
> Instances only have to be coherent if they are implicit.
Agreed. I may have been muddling the discussion by conflating
"sufficiently flexible incoherent type classes" with "implicit
parameters", since they are the same at the implementation level
modulo partial evaluation vs. polyinstantiation.
Geoffrey
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
