# Diagramming algorithms implemented in prolog

**URL:** <https://swi-prolog.discourse.group/t/diagramming-algorithms-implemented-in-prolog/778>\
**Category:** Help!\
**Created:** [June 6, 2019, 11:34am UTC](https://swi-prolog.discourse.group/t/diagramming-algorithms-implemented-in-prolog/778 "2019-06-06T11:34:42Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\
**Post date:** [June 6, 2019, 11:34am UTC](https://swi-prolog.discourse.group/t/diagramming-algorithms-implemented-in-prolog/778/1 "2019-06-06T11:34:42Z")

</div>

Hi,

I am trying to document the overall design of my code. My first attempt is to create flow charts of broad steps performed and related static and dynamic data structures.

However, I now noticed that once one looks into backtracking – this can become quite tricky.

For example, one flow chart step could be a generator – generating examples to test – while in another location quite further down of multiple recursive calls, there could be a fail, to initiate a backtracking.

The fail causes backtracking across many calls, untraveling various computations until the generator gets to redo and call to test another example.

are there any good visual techniques to visualize that …

Dan

---

<div class="post-metadata">

**Author:** ![pmoura](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/pmoura/32/11_2.png) [@pmoura](https://swi-prolog.discourse.group/u/pmoura)\
**Post date:** [June 6, 2019, 11:48am UTC](https://swi-prolog.discourse.group/t/diagramming-algorithms-implemented-in-prolog/778/2 "2019-06-06T11:48:09Z")

</div>

Take a look e.g. to SWI-Prolog graphical profiler and Logtalk ports profiler.

---

<div class="post-metadata">

**Author:** ![EricGT](https://avatars.discourse-cdn.com/v4/letter/e/f1d935/32.png) [@EricGT](https://swi-prolog.discourse.group/u/EricGT)\
**Post date:** [June 6, 2019, 11:48am UTC](https://swi-prolog.discourse.group/t/diagramming-algorithms-implemented-in-prolog/778/3 "2019-06-06T11:48:56Z")

</div>

Yes,

Use the [box model](http://www.gprolog.org/manual/html_node/gprolog012.html).

This is one of those cases where using Google Image [search](https://www.google.com/search?tbm=isch&source=hp&biw=1920&bih=969&ei=N_34XMuZCa_U5gKVy4zQBA&q=prolog+box+model&oq=prolog+box+model&gs_l=img.3...2239.6292..6534...3.0..0.86.1275.21......0....1..gws-wiz-img.....0..0j0i24j0i10i24j0i8i30j0i30.9cfm-vBsKHI) leads to better pages than Google text search.

[https://www.cs.nmsu.edu/~ipivkina/ECLIPSE/doc/userman/node76.html](https://www.cs.nmsu.edu/~ipivkina/ECLIPSE/doc/userman/node76.html)

Another variation that can be used is based on [derivation tree](https://github.com/jariazavalverde/tau-prolog/issues/58#issuecomment-439489480).

---

<div class="post-metadata">

**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\
**Post date:** [June 6, 2019, 12:45pm UTC](https://swi-prolog.discourse.group/t/diagramming-algorithms-implemented-in-prolog/778/4 "2019-06-06T12:45:14Z")

</div>

Thank you

This the box model with the ports looks very useful. I really like to back “redo” arrow – that what i was missing …

I will need to work out how to do this legible on a page …

thank you,

Dan

---

<div class="post-metadata">

**Author:** ![EricGT](https://avatars.discourse-cdn.com/v4/letter/e/f1d935/32.png) [@EricGT](https://swi-prolog.discourse.group/u/EricGT)\
**Post date:** [June 6, 2019, 12:57pm UTC](https://swi-prolog.discourse.group/t/diagramming-algorithms-implemented-in-prolog/778/5 "2019-06-06T12:57:18Z")

</div>

> [@grossdan](#):
>
> legible on a page

If you have [Visio](https://en.wikipedia.org/wiki/Microsoft_Visio) or other similar application that helps.

Another way to make them presentable on paper is to use [graphviz](https://www.graphviz.org/) [dot](https://graphviz.gitlab.io/_pages/pdf/dotguide.pdf)

Visio is faster, but proprietary, however you can save in many formats including SVG.

Dot is widely known an used and is what I used [here](https://swi-prolog.discourse.group/t/wiki-how-to-unification/691). The dot output was saved as [SVG](https://en.wikipedia.org/wiki/Scalable_Vector_Graphics) which is nice because Internet browsers can read them and they scale nicely.

Both have a learning curve, but once you do it for a while it becomes [old hat](https://www.macmillandictionary.com/us/dictionary/american/old-hat)

You might want to search the SWI-Prolog [packages](http://www.swi-prolog.org/pack/list), several of them make use of GraphViz, e.g.

> **["gvterm" pack for SWI-Prolog](https://www.swi-prolog.org/pack/list?p=gvterm)**

and might actually do what you are planing or at least have code that use to work but is no longer maintained, but is useful for studying.

---

<div class="post-metadata">

**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\
**Post date:** [June 6, 2019, 1:15pm UTC](https://swi-prolog.discourse.group/t/diagramming-algorithms-implemented-in-prolog/778/6 "2019-06-06T13:15:42Z")

</div>

thanks,

I am drawing them in power point – and more abstractly than the code.

I also notice that having two lines in parallel for call and redo, seems reducant – every call implies a redo – so i can simplify that – i think.

its the nested boxes and llines across boxes on the page that seem to hold the essentials

The diagram with the circular recursions i am getting is interesting – almost Escher like 🙂

---

<div class="post-metadata">

**Author:** ![EricGT](https://avatars.discourse-cdn.com/v4/letter/e/f1d935/32.png) [@EricGT](https://swi-prolog.discourse.group/u/EricGT)\
**Post date:** [June 6, 2019, 1:17pm UTC](https://swi-prolog.discourse.group/t/diagramming-algorithms-implemented-in-prolog/778/7 "2019-06-06T13:17:44Z")

</div>

> [@grossdan](#):
>
> Thank you

A nice alternative to using a Thank You response with discourse is to just click on the heart

![Capture](https://global.discourse-cdn.com/free1/uploads/swiprolog/original/1X/fadeea6f1f0e5cf9b7f14ece8873b97685cc4fcb.png)

This not only saves the time of saying thank you, it also helps those you thank get a higher [trust level](https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/) and reflects in the users profile, e.g. [EricGT](https://swi-prolog.discourse.group/u/ericgt).

Additionally it saves on the amount of reading others have to do and notifies others that this is a reply worth reading or noting for future use.

However if it is a Thank You and some added info, then by all means use a response, and give the heart a click.

The way the accounts are set up by default is that if a response is created with a quote or ` @<user tag>` then they get an instant messages on their computer.

If a heart is clicked on a topic they made then it doesn’t disturb the OP of the response; instead it shows up in their notification queue.

![Capture](https://global.discourse-cdn.com/free1/uploads/swiprolog/original/1X/36d91219dcef109e463955223fbeb835a42896a6.png)

---

<div class="post-metadata">

**Author:** ![EricGT](https://avatars.discourse-cdn.com/v4/letter/e/f1d935/32.png) [@EricGT](https://swi-prolog.discourse.group/u/EricGT)\
**Post date:** [June 6, 2019, 1:20pm UTC](https://swi-prolog.discourse.group/t/diagramming-algorithms-implemented-in-prolog/778/8 "2019-06-06T13:20:36Z")

</div>

> [@grossdan](#):
>
> I also notice that having two lines in parallel for call and redo, seems redundant – every call implies a redo – so i can simplify that – i think.

That does not sound correct. Can you give an example image that has a few boxes working together and the corresponding Prolog source code so that we can check it. You don’t want to pick up a bad or invalid habit at first then have to re-learn which is harder than just learning.

---

<div class="post-metadata">

**Author:** ![pmoura](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/pmoura/32/11_2.png) [@pmoura](https://swi-prolog.discourse.group/u/pmoura)\
**Post date:** [June 6, 2019, 4:08pm UTC](https://swi-prolog.discourse.group/t/diagramming-algorithms-implemented-in-prolog/778/9 "2019-06-06T16:08:20Z")

</div>

> [@grossdan](#):
>
> I am drawing them in power point – and more abstractly than the code.
> 
> I also notice that having two lines in parallel for call and redo, seems reducant – every call implies a redo – so i can simplify that – i think.
> 
> its the nested boxes and llines across boxes on the page that seem to hold the essentials
> 
> The diagram with the circular recursions i am getting is interesting – almost Escher like 🙂

Curious how far is a predicate cross-reference diagram (e.g. [html\_basics\_module](https://logtalk.org/diagrams/cliopatria/html_basics_module_xref_diagram.svg)) from what you want for documenting your code. These diagrams can show recursive calls (a `calls` edge linking a predicate to itself), predicates updating (i.e. asserting or retracting) dynamic predicates (`updates` edges), and links to your source code (as in that example). They will no show the exact sequence of calls, however (only edges to called predicates). Still, it should be possible to automatically generate a diagram with at least some of the extra information you mention. Doing it manually means that diagrams and code can easily get out of sync, diminishing the diagrams values as documentation. Can you share one of those diagrams that you’re making for comparison and clarification?
