# Compiler support for cyclic terms?
**URL:** https://swi-prolog.discourse.group/t/compiler-support-for-cyclic-terms/5071
**Category:** Discussion
**Created:** [February 28, 2022, 5:14pm UTC](https://swi-prolog.discourse.group/t/compiler-support-for-cyclic-terms/5071 "2022-02-28T17:14:36Z")
**Posts on this page:** 1
**Showing post:** 3
### Author:  [@jan](https://swi-prolog.discourse.group/u/jan)
#### Post date: [March 1, 2022, 4:10pm UTC](https://swi-prolog.discourse.group/t/compiler-support-for-cyclic-terms/5071/3 "2022-03-01T16:10:05Z")
> [@ridgeworks](#):
>
> Is there any real prospect of of compiler support?
Built-in, there is no hurry. You can quite easily check for a cyclic term though and call term\_factorized/3 to create a non-cyclic version and stick the cycle unification at the start of the body. We could implement this in assert as a way to handle the exception, i.e. opportunistically assume the term is acyclic and do plan B otherwise.
> [@ridgeworks](#):
>
> `ERROR: [10,391,483] toplevel_variables:expand_args(1, 2, [length:1], , , _1848, _1850)`
Looks like the toplevel can’t deal with cyclic queries. As read\_term/2 cannot produce these normally that doesn’t matter too much. A couple of things need to be fixed though. You’ll probably encounter similar problems for goal expansion. Pull requests welcome 🙂
---
_[View the full topic](https://swi-prolog.discourse.group/t/compiler-support-for-cyclic-terms/5071)._