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
