lmondada / portmatching Goto Github PK

from @acl-cqc:

I'm also wondering whether the similarity between StringPosition and StringIndexKey (i.e. that they have the same representation, even though they are distinct types) is something that could be enforced by the framework, rather than in the application to strings. (E.g. it could provide + use two types SubjectPosition and PatternPosition and use the same specified for the kind of Data.) Of course this falls over if the Key/Value=Position types are different, which I think would mean if you wanted other/more-flexible kinds of pattern rather than just being in the same form as the data with atoms/characters/node-labels replaced by variables.
I note Position/Value == Key for both implementations of IndexingScheme so far (StringIndexingScheme and TestIndexingScheme), tho.

Patterns without constraints but a fixed length are not handled properly at the moment. Such patterns can be built by using distinct variables at every pattern position, eg $a$b$c.

See test_dummy_len_2_string_matching in the src/string.rs file.

Having the crate as a dependency causes portmatching::HashMap to be the suggested as a (frequently first) option for importing HashMap by rust-analyzer. What's even worse is that this is not the same hashmap in std::collections.

I'd suggest removing the public export, or renaming it so users don't mix it up with the std one.