[m-users.] How to declare a set of typeclasses?

[Sean Charles (emacstheviking)]

I will study those modules.

The hash function for my objects would be as simple as returning the internal id value, it increases monotonically on creation of a new instance, guaranteed unique throughout the lifetime of the game, using int range should be enough, i don't think the game will be that addictive to cause a rollover situation!

3.8 crash course: correct, no mention of hashing.

It's amazing what you realise you need to know writing a game in a language like Mercury as opposed to straight smash-it-out in C/C++ land. Much more fun!

I looked at the `rtree` module too, but for now I think I will stay with what I have as I could see I'd need to reorganise a fair bit of code to fit both the typeclass interface it has and its API. Maybe version 2.0 ...

Thanks again.
Sean


> On 10 Oct 2023, at 23:42, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On 2023-10-11 09:19 +11:00 AEDT, "Sean Charles (emacstheviking)" <objitsu at gmail.com> wrote:
>> Then I did what I thought would work:
>> 
>> :- type l1_set(T) == set(hittable(T)) <= hittable(T).
> 
> If what you are after is "the type of a set of things where each thing is hittable",
> what you need to do is to simply use "set(T)" where you want this, *and*
> add the typeclass constraint "<= hittable(T)" to the declarations of the
> predicates and functions where such an argument appears. For an example,
> have a look at e.g. sparse_bitset.m in the standard library.
> 
>> And here is the actual code where I am trying to use it, I am operating on the assumption
>> that by default Mercury has some way of creating a unique hash for each object
> 
> That assumption is incorrect. The int.m, uint.m and string.m modules
> of the standard library define hash functions, but for other types,
> providing a hash function is up to you. And while there exist algorithms
> for creating perfect hash functions (i.e. hash functions that don't generate
> any collisions on a given set of input values),
> 
> - they guarantee the absence of collisions *only* for that set of values,
> - they require the values of that set to be specified in advance,
> - and even then they fail to generate a hash function for some sets.
> 
> Even cryptographically secure hash functions can have collisions.
> The pigeon-hole principle guarantees this for any hash function
> that generates a hash value of a fixed size for inputs of unbounded size.
> 
>> Ah.. it is section 3.8 of the online page https://mercury-in.space/crash.html#orga13c54a
> 
> That section does not talk about hashing.
> 
> Zoltan.