# Linter

**URL:** <https://swi-prolog.discourse.group/t/linter/1160>\
**Category:** Split Topic\
**Created:** [September 3, 2019, 9:30am UTC](https://swi-prolog.discourse.group/t/linter/1160 "2019-09-03T09:30:41Z")\
**Posts on this page:** 1\
**Showing post:** 7

<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:** [September 3, 2019, 1:22pm UTC](https://swi-prolog.discourse.group/t/linter/1160/7 "2019-09-03T13:22:23Z")

</div>

> [@jan](#):
>
> That is mostly because you want to be portable. Virtually all SWI-Prolog’s code analysis tools run on the generated code […].

Portability is only a partial issue. SWI-Prolog reflection API and native tools are oblivious of Logtalk language constructs and thus of limited usefulness for Logtalk developer tools. The only notable usage exception is the [`diagrams`](https://logtalk.org/tools.html#diagrams) tool but there the SWI-Prolog reflection API is only used when [generating diagrams for Prolog module applications](https://swi-prolog.discourse.group/t/generate-diagrams-for-your-prolog-module-applications/543).

> [@jan](#):
>
> In fact, for code analysis the more recent `library(prolog_codewalk)` makes cross referencing on the loaded code much easier (as well as many additional tasks).

Logtalk objects, protocols, and categories are not an abstraction over Prolog modules. Message sending is not an abstraction over module-qualified calls. Not to mention the Logtalk predicate semantics that don’t exist in Prolog. Thus, trying to reconstruct the related contextual information from the generated intermediate code, either for the linter or for Logtalk own reflection API, would be too much work for little to no gain.

---

_[View the full topic](https://swi-prolog.discourse.group/t/linter/1160)._