Although slightly off-topic, I think its useful to show two threading
examples:
using int2
thread_start() {
// all threads share the same counter
}
Or
thread_start() {
using int2
// each thread has a separate counter initialised on stread start
}
This is due to 'using' creating the state storage for the
dynamically-scoped implicit override on the stack (for small objects like a
single int, or heap-allocated forl larger objects controlled by a C++ style
'unique_ptr'' from the stack, so that it gets auto de-allocated on scope
exit).
Keean.
On 9 January 2015 at 07:26, Keean Schupke <[email protected]> wrote:
> Continuing thoughts about the behaviour of dynamic scoping of type-class
> instances lifted from records. Note the data declaration and of the record
> creates both the report type and an equivalent type-class:
>
> > > 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
> > >
>
> The alternative here is to push int2 into a dynamic scoping stack for this
> instance so it overrides int1. This is probably more useful as it allows
> local changed to type-class resolution:
>
> void f() {
> using int2
> // implicit int comparisons will use int2
> }
>
> // implicit int comparisons will use int1
>
> > > using int2 // error incoherent
>
> This is probably the best approach so far in my opinion, so I would be
> interested if anyone can see any problems. I like the concept of unifying
> type - classes and records, and it makes it intuitive that a stateful type
> class still needs a storage location. The 'using' statement can stack
> allocate that storage due to the dynamic scoping. Is also reduces the
> amount of syntax, so a single definition is needed, and avoids overlapping
> functionality between type-classes and records, whilst keeping the implicit
> resolution coherent (by always taking the top of the dynamic scoping
> stack). I think its important to have a keyword/operation that actually
> brings a type definition into dynamic scope giving a stack location for any
> associated state.
>
> Keean.
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
