A circular list is not a list. - #198
Merged
Merged
Conversation
|
One small remark: What is called "proper list" here is simply called list in the Prolog standard: 3.99 list: Either the empty list or a non-empty list. 3.62 empty list: The atom [] (nil). 3.114 non-empty list: A compound term whose prin- cipal functor is the list constructor and whose second argument is a list. The term |
ichiban
changed the title
Owner
Author
|
@triska Thank you for the clarification! |
triska
added a commit
to triska/scryer-prolog
that referenced
this pull request
Apr 20, 2022
This terminology is a bit harder to understand than that of the other
type checks.
Scryer Prolog comprises two individually consistent but incompatible
notions of terms, namely terms and rational trees (which are also
called "cyclic terms"). This leads to a confusion in terminology,
because cyclic terms are not terms in the former sense even though
they also contain the word "term" in their name.
This terminological confusion is not restricted to terms: We also find
it for example in the notion of lists. Lists are defined inductively:
- The empty list (written as "" or [], called 'nil') is a list.
- A term with principal functor '.'/2 is a list if its second argument
is a list.
Note that a list may contain cyclic terms as elements, and still be
called a list. However, if we post:
?- Ls = [_|Ls].
then Ls is not a list, because it does not fit the inductive
definition. Still, it is sometimes referred to as a "cyclic list" or
"circular list", even though it is not a list. Even Prolog
implementors that aim for strict conformance to the Prolog ISO
standard and are deeply familiar with the standard use this
terminology when talking about such terms, see for example:
ichiban/prolog#198
Consequently, must_be(list, Ls) raises a *type error* in this case.
Terms are distinguished from cyclic terms completely analogously. This
leads to the counterintuitive consequence that *cyclic lists are not
terms*. The reason for this apparent contradiction in terminology is
the mutual incompatibility of different notions of terms. The notion
of "term" precludes rational trees, similar to the notion of "list"
which precludes cyclic lists.
We therefore introduce:
* must_be(term, Term)
- raises an instantiation error if Term contains variables (since
it could still become a rational tree)
- raises a type error if Term is a rational tree
* can_be(term, Term)
- raises a type error if Term is a rational tree
Note that using the notion of "cyclic" and "acyclic" in this
terminology would not a good idea, because the then arising confusion
is precisely what we want to get away from: must_be(term, Term) should
be usable as a test that reliably determines whether Term can be
treated as a term with the logical properties we expect from terms.
This addresses mthom#1428.
triska
added a commit
to triska/scryer-prolog
that referenced
this pull request
Apr 20, 2022
This terminology is a bit harder to understand than that of the other
type checks.
Scryer Prolog comprises two individually consistent but incompatible
notions of terms, namely terms and rational trees (which are also
called "cyclic terms"). This leads to a confusion in terminology,
because cyclic terms are not terms in the former sense even though
they also contain the word "term" in their name.
This terminological confusion is not restricted to terms: We also find
it for example in the notion of lists. Lists are defined inductively:
- The empty list (written as "" or [], called 'nil') is a list.
- A term with principal functor '.'/2 is a list if its second argument
is a list.
Note that a list may contain cyclic terms as elements, and still be
called a list. However, if we post:
?- Ls = [_|Ls].
then Ls is not a list, because it does not fit the inductive
definition. Still, it is sometimes referred to as a "cyclic list" or
"circular list", even though it is not a list. Even Prolog
implementors that aim for strict conformance to the Prolog ISO
standard and are deeply familiar with the standard use this
terminology when talking about such terms, see for example:
ichiban/prolog#198
Consequently, must_be(list, Ls) raises a *type error* in this case.
Terms are distinguished from cyclic terms completely analogously. This
leads to the counterintuitive consequence that *cyclic lists are not
terms*. The reason for this apparent contradiction in terminology is
the mutual incompatibility of different notions of terms. The notion
of "term" precludes rational trees, similar to the notion of "list"
which precludes cyclic lists.
We therefore introduce:
* must_be(term, Term)
- raises an instantiation error if Term contains variables (since
it could still become a rational tree)
- raises a type error if Term is a rational tree
* can_be(term, Term)
- raises a type error if Term is a rational tree
Note that using the notion of "cyclic term" and "acyclic term" in this
terminology would not be a good idea, because this confusion is
precisely what we want to eliminate: must_be(term, Term) should be
usable as a test that reliably determines whether Term can be treated
as a term with the logical properties we expect from terms.
This addresses mthom#1428.
triska
added a commit
to triska/scryer-prolog
that referenced
this pull request
Apr 20, 2022
This terminology is a bit harder to understand than that of the other
type checks.
Scryer Prolog comprises two individually consistent but incompatible
notions of terms, namely terms and rational trees (which are also
called "cyclic terms"). This leads to a confusion in terminology,
because cyclic terms are not terms in the former sense even though
they also contain the word "term" in their name.
This terminological confusion is not restricted to terms: We also find
it for example in the notion of lists. Lists are defined inductively:
- The empty list (written as "" or [], called 'nil') is a list.
- A term with principal functor '.'/2 is a list if its second argument
is a list.
Note that a list may contain cyclic terms as elements, and still be
called a list. However, if we post:
?- Ls = [_|Ls].
then Ls is not a list, because it does not fit the inductive
definition. Still, it is sometimes referred to as a "cyclic list" or
"circular list", even though it is not a list. Even Prolog
implementors that aim for strict conformance to the Prolog ISO
standard and are deeply familiar with the standard use this
terminology when talking about such terms, see for example:
ichiban/prolog#198
Consequently, must_be(list, Ls) raises a *type error* in this case.
Terms are distinguished from cyclic terms completely analogously. This
leads to the counterintuitive consequence that *cyclic lists are not
terms*. The reason for this apparent contradiction in terminology is
the mutual incompatibility of different notions of terms. The notion
of "term" precludes rational trees, similar to the notion of "list"
which precludes cyclic lists.
We therefore introduce:
* must_be(term, Term)
- raises an instantiation error if Term contains variables (since
it could still become a rational tree)
- raises a type error if Term is a rational tree
* can_be(term, Term)
- raises a type error if Term is a rational tree
Note that using the notion of "cyclic term" and "acyclic term" in this
terminology would not be a good idea, because this confusion is
precisely what we want to eliminate: must_be(term, Term) should be
usable as a test that reliably determines whether Term can be treated
as a term with the logical properties we expect from terms.
This addresses mthom#1428.
nlothian
pushed a commit
to nlothian/scryer-prolog
that referenced
this pull request
Dec 2, 2025
This terminology is a bit harder to understand than that of the other
type checks.
Scryer Prolog comprises two individually consistent but incompatible
notions of terms, namely terms and rational trees (which are also
called "cyclic terms"). This leads to a confusion in terminology,
because cyclic terms are not terms in the former sense even though
they also contain the word "term" in their name.
This terminological confusion is not restricted to terms: We also find
it for example in the notion of lists. Lists are defined inductively:
- The empty list (written as "" or [], called 'nil') is a list.
- A term with principal functor '.'/2 is a list if its second argument
is a list.
Note that a list may contain cyclic terms as elements, and still be
called a list. However, if we post:
?- Ls = [_|Ls].
then Ls is not a list, because it does not fit the inductive
definition. Still, it is sometimes referred to as a "cyclic list" or
"circular list", even though it is not a list. Even Prolog
implementors that aim for strict conformance to the Prolog ISO
standard and are deeply familiar with the standard use this
terminology when talking about such terms, see for example:
ichiban/prolog#198
Consequently, must_be(list, Ls) raises a *type error* in this case.
Terms are distinguished from cyclic terms completely analogously. This
leads to the counterintuitive consequence that *cyclic lists are not
terms*. The reason for this apparent contradiction in terminology is
the mutual incompatibility of different notions of terms. The notion
of "term" precludes rational trees, similar to the notion of "list"
which precludes cyclic lists.
We therefore introduce:
* must_be(term, Term)
- raises an instantiation error if Term contains variables (since
it could still become a rational tree)
- raises a type error if Term is a rational tree
* can_be(term, Term)
- raises a type error if Term is a rational tree
Note that using the notion of "cyclic term" and "acyclic term" in this
terminology would not be a good idea, because this confusion is
precisely what we want to eliminate: must_be(term, Term) should be
usable as a test that reliably determines whether Term can be treated
as a term with the logical properties we expect from terms.
This addresses mthom#1428.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.