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.
Keean.
On 8 January 2015 at 17:42, Jonathan S. Shapiro <[email protected]> wrote:
> On Thu, Jan 8, 2015 at 4:02 AM, Keean Schupke <[email protected]> wrote:
>
>> Thinking about:
>>
>> instance Ord int is
>> x < y = do
>> count <- count + 1
>> primative_int_less(x, y)
>>
>> Its not nice that the instance is gobal, and that implies count is global.
>>
> Globals aren't always evil. Yet this instance is perfectly valid, and it
> can "instantiated through" in the way I have been talking about without any
> difficulty.
>
> And while I agree with you that perhaps this case should be a procedure,
> that isn't always possible. In this case we might have had a pre-existing
> arrangement of code that we are temporarily instrumenting.
>
> But the main point I was making is that we obviously can't think of a
> thing with state as something we can lift into a type.
>
>
> shap
>
>
> _______________________________________________
> 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
