# Inlining C

**URL:** <https://swi-prolog.discourse.group/t/inlining-c/3780>\
**Category:** Request For Comments\
**Created:** [March 30, 2021, 6:49am UTC](https://swi-prolog.discourse.group/t/inlining-c/3780 "2021-03-30T06:49:27Z")\
**Posts on this page:** 2\
**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:** [March 30, 2021, 6:49am UTC](https://swi-prolog.discourse.group/t/inlining-c/3780/1 "2021-03-30T06:49:27Z")

</div>

Hi Jan,

Have you considered inlining C – with “macro” wrappers to access terms … as an alternative to foreign predicates.

Perhaps now with a new construct for determinstic predicates, it could, in particular make sense – to focus on seamlessly supporting simpler C code that doesn’t need to be backtracked over.

Key benefit would be fast deterministic (functional) code; simplified, and seamless, foreign language support.

Drawback might be the difficulty of supporting a debugger that handles two languages seamlessly and a more elaborate prolog complier tool chain that now requires calling a c complier as well.

Dan

---

<div class="post-metadata">

**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\
**Post date:** [March 30, 2021, 9:45am UTC](https://swi-prolog.discourse.group/t/inlining-c/3780/2 "2021-03-30T09:45:15Z")

</div>

With a VM that won’t be easy. Even then, life is touch inside the VM as just about anything can move anywhere at any time. That is why we have the `term_t` abstraction for foreign code that makes all access of foreign code known to Prolog and makes sure that possible moved data can still be found.