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>) {
...
}
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.
Keean.
On 8 January 2015 at 23:55, Geoffrey Irving <[email protected]> wrote:
> It seems like something like this could possibly be made to work, but
> I do think it is more complicated than allowing the user to pass
> runtime state as part of the comparison function / function object /
> typeclass / etc. In particular, thread local state is a pretty hefty
> tool to have to use if the user just wants to call sort without
> causing race conditions. If the need for this thread local state
> stems from requiring instance coherence, it seems like a strong
> argument for finding a way to not require instance coherence.
>
> Geoffrey
>
> On Thu, Jan 8, 2015 at 3:48 PM, Keean Schupke <[email protected]> wrote:
> > Its just a namespace, hiding the name, so it has nothing to do with
> runtime.
> > I am not really sure of what I think the best way to handle thread-local
> > storage is. I can think of some different options:
> >
> > - a 'local' keyword to indicate count is thread-local
> > - dynamic scoping
> >
> >
> > But perhaps something like this would be good:
> >
> > class comparison_counter {
> > int count;
> >
> > public:
> > int report() {
> > return count;
> > }
> >
> > instance Ord int is
> > x < y = do
> > count <- count + 1
> > primitive_int_less(x, y)
> > }
> >
> > If you combined that with some kind of dynamic scoping of type class
> > instances, for example:
> >
> > void thread_start() {
> > comparison_counter cc;
> >
> > // here the instance of Ord for int from 'cc' would override.
> >
> > print cc.report
> > }
> >
> > Naively is seems better to restrict the dynamic scoping to type classes,
> > rather than having full dynamic scoping for variables.
> >
> >
> > Keean.
> >
> >
> >
> > On 8 January 2015 at 23:02, Geoffrey Irving <[email protected]> wrote:
> >>
> >> On Thu, Jan 8, 2015 at 2:56 PM, Keean Schupke <[email protected]> wrote:
> >> > Thinking more about this, it would be better to have some kind of
> >> > enclosing
> >> > namespace that hides 'count' from outside interference. Something
> like:
> >> >
> >> > namespace mine {
> >> > int count
> >> >
> >> > export:
> >> > int report() {
> >> > return count;
> >> > }
> >> >
> >> > instance Ord int is
> >> > x < y = do
> >> > count <- count + 1
> >> > primative_int_less(x, y)
> >> > }
> >> >
> >> > Something that isn't a class (which you have to initialise new
> instances
> >> > of), but is just hiding the definition of count. This would remove
> >> > concerns
> >> > about count being global, and is a bit like an abstract-data-type in
> >> > Ada.
> >>
> >> Can this system be extended to handle asynchronous access from
> >> multiple threads, each wanting their own copy of count?
> >>
> >> Geoffrey
> >> _______________________________________________
> >> bitc-dev mailing list
> >> [email protected]
> >> http://www.coyotos.org/mailman/listinfo/bitc-dev
> >
> >
> >
> > _______________________________________________
> > bitc-dev mailing list
> > [email protected]
> > http://www.coyotos.org/mailman/listinfo/bitc-dev
> >
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
