Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Name collisions across spec and implementation #129

Open
Gozala opened this issue Jan 10, 2024 · 0 comments
Open

Name collisions across spec and implementation #129

Gozala opened this issue Jan 10, 2024 · 0 comments

Comments

@Gozala
Copy link

Gozala commented Jan 10, 2024

Summary

Implementation defines types Tuple and Fact to describe what I believe PomoLogic calls ground atom. This gets even more confusing given that PomoDB calls EAVT (4-tuples) facts

Problem

  1. This naming conflicts make it really difficult to build up and retain mental model of the implementation logic.
  2. I think Tuple and Fact also describe same concept but in different contexts and two names here which makes things even more confusing.

Impact

Makes it difficult to learn and contribute to the project.

Solution

  1. Rename Fact so it does not collide with a name "fact" when referencing EAVT tuples. I would propose calling it Association as it associates multiple attributes and makes intuitive sense to me. Alternative it can be called GroundAtom which would be very clear reference to a terminology used in the spec.
  2. Avoid name Tuple given how overloaded it is, even EAVTs are frequently referred as tuples (even spec the spec does it). Again I think Association seems like an intuitive term for me but anything less overloaded would do.
  3. Assuming Tuple and Fact do indeed refer to the concept of "ground atom" in different contexts it would be good to use same name (e.g. there are multiple Program types for different contexts) or alternatively have same term with different suffix.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant