Hash maps

[wclodius2]

Now that hash functions have been added to the standard library, it is time to add hash maps. Currently this PR only includes the documentation, doc/specs/stdlib_hash_maps.md, giving the proposed API. The proposed API has three module files: stdlib_key_data_wrapper.f90, which provides wrappers for the key and data components of the entries and some of the hash function; stdlib_chaining_hash_map.f90, which implements a chaining hash map with linked lists; and stdlib_open_hash_maps.f90, which implements a linear addressing open hashing map. After the (modified) API has been approved by two people I will add the required module files.

[awvwgk]

Three general questions:

1. Why represent the key / other type as array of int8 rather than as class(*), allocatable? At least for the other type the latter representation would be more flexible without the need for memory manipulations with transfer
2. Would the definition of a container type be useful? This one could be used for all data structures (e.g. lists).
3. Should the procedures for the maps be type bound? First this makes imports simpler and might also allow to define a common base class.

[awvwgk]

Regarding the naming of the modules I would propose to adjust the naming to be more concise:

• stdlib_key_data_wrapper -> stdlib_container
• stdlib_chaining_hash_map -> stdlib_hashmap_chaining
• stdlib_open_hash_map -> stdlib_hashmap_open

If we can define an abstract base class, stdlib_map_class (for both ordered and unordered maps) or stdlib_hashmap_class (for unordered maps only) module might be a good name.

[wclodius2]

@awvwgk

1. I have never used CLASS(*). I assume I can ask for the underlying type using select(type). Does it preserve array information so I can ask rank and array size array size? Are rank independent procedure arguments widely implemented?
2. I don't know if it will be useful to define a container type beyond what I define as the open_map_entry_type and chaining_map_entry_type. Would it be intended to replace the key and other components of those two types?
3. I had started to define a parent type (in a module stdlib_hash_maps) to the open_hash_map_type and chaining_hash_map_type. It had some non_overridable type bound procedures and a large number of deferred type bound procedures. Implementing it fully would require decisions as to whether we want the use of inheritance, and whether the detailed implementation of the subtypes would be in modules or sub-modules.

[wclodius2]

@awvwgk the proposed module names seem to me (and @milancurcic) better than what I currently have so I will change the modules and their files to what you suggest.

[wclodius2]

In thinking further I am inclined tho rename stdlib_key_data_wrapper to stdlib_hashmap_container.

[gareth-nx]

1. have never used CLASS(*). I assume I can ask for the underlying type using select(type). Does it preserve array information so I can ask rank and array size array size? Are rank independent procedure arguments widely implemented?

I believe that CLASS(*) objects cannot be arrays. If you want it to hold an array then you have to create a derived type that holds the array.

[gareth-nx]

So both of the hash maps are noted more for its diagnostics than its performance ? That's OK, just want to double check that is the intention.

[wclodius2]

I think the performance is not baad. Generating the information used in the diagnostics is, I suspect, a small amount of overhead, but it is an overhead other tables will lack.

[gareth-nx]

Does this rely on the compiler to automatically call the finalization subroutine when a derived type goes out of scope? Last time I checked (albeit not recently) gfortran still didn't do this.

[wclodius2]

Yes it relies on this to avoid memory leaks, though the largest amount of memory will be in arrays and not in the linked list used to avoid memory allocations. I don't think there are memory leaks with my most recent code compiled using the latest version of gfortran, though my testing was very indirect.

[awvwgk]

Another question, why is the index inmap part of the public API? Shouldn't this be an implementation detail of the map type and hidden from the user?

Is there a drawback to reference entries sorely with a key? To retain a reference we could have a pointer to the data returned, if we want to safe redundant queries on the map.

[gareth-nx]

Is this different to the version in stdlib_hash_32bit?

[wclodius2]

It is just giving access to the version in stdlib_hash_32bit.

[jvdp1]

If it is the case, then i suggest to to repeat the specs here. A link to the page of Fibonacci_hash should be enough,

[wclodius2]

Do you mean "then i suggest not to repeat the specs here."?

[gareth-nx]

Thanks, this is really important for stdlib. I don't have expertise in these data structures, but made a few minor comments.

[wclodius2]

I believe that CLASS(*) objects cannot be arrays. If you want it to hold an array then you have to create a derived type that holds the array.

Then I believe CLASS(*) will be of very limited use.

[wclodius2]

In thinking further I will rename stdlib_key_data_wrapper to stdlib_hashmap_wrappers.

[wclodius2]

@awvwgk I have changed the module names and revised the first paragraph to focus more on hash maps than hash functions., and have pushed the revised document.

[wclodius2]

@14NGiestas git shows that I still have one change request from you that I have not addressed. Do you know which one that is?

[14NGiestas]

I think you addressed all my issues with this PR, I have nothing to add so far, so I'm giving my approval.

[jvdp1]

@wclodius2 sorry for the delay. I opened a PR in your repo with some propositions for the specs.

[wclodius2]

@jvdp1 I believe I have checked in your changes.

[jvdp1]

@jvdp1 I believe I have checked in your changes.

Good. I am continuing the review.

[jvdp1]

@wclodius2 I opened a 2 PR in your repo with some propositions for the docstrings and the tests:

• PR 13 - addition of links
• PR 14 - addition of tests

[wclodius2]

@jvdp1 I have committed PR #13 and PR #14.

[jvdp1]

Thank you @wclodius2 for this feature.

[jvdp1]

@fortran-lang/stdlib @milancurcic @ivan-pi @LKedward @awvwgk @gareth-nx and others interested by hash maps:
There are now 2 complete reviews. I am sure that we can still discuss the API. However, I propose that we merge this PR as experimental such that users can test it and play with it, except if you still see a major issue that would prohibit its merging.

[milancurcic]

I haven't reviewed but agree for this PR to go forward.

[wclodius2]

I have also updated from fortran-lang/stdlib.

[jvdp1]

We discussed the status of this PR during the monthly call, and agreed to merge it such that users can test and play with this new feature. So, I will merge it.

@wclodius2 Thank you for this PR.