You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While there is code for getting, setting and unifying lists with prolog terms, there's nothing for the more primitive cons cells that underly these lists. This is annoying, because not every data structure that can be built with cons cells is necessarily going to be a list. Furthermore, certain approaches to list building are easier when we can leave the tail as a variable which is then unified later.
We therefore need a way to work with cons cells directly. This'll also help in implementing the cons part of #5.
You can implement this similarly to unifying with a list, just instead of unifying the end with a nil element, you can unify it with a user-specified tail. That way you're only using the "linked" part of the linked list for the part that's necessary thus not sacrificing performance by requiring use of some linked list structure.
In fact, regular lists are a special case of this list of terms + a tail unification, where the tail is nil.
While there is code for getting, setting and unifying lists with prolog terms, there's nothing for the more primitive cons cells that underly these lists. This is annoying, because not every data structure that can be built with cons cells is necessarily going to be a list. Furthermore, certain approaches to list building are easier when we can leave the tail as a variable which is then unified later.
We therefore need a way to work with cons cells directly. This'll also help in implementing the cons part of #5.
See #4 for earlier discussion on this.
The text was updated successfully, but these errors were encountered: