# Wrapping predicates

**URL:** <https://swi-prolog.discourse.group/t/wrapping-predicates/668>\
**Category:** Request For Comments\
**Created:** [May 19, 2019, 2:27pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668 "2019-05-19T14:27:12Z")\
**Posts on this page:** 20\
**Page:** 1

<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:** [May 19, 2019, 2:27pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/1 "2019-05-19T14:27:12Z")

</div>

I have an early prototype for something I wanted to achieve for a long time: be able to add wrappers around arbitrary predicates. The driving use-case is tabling. As is, tabled predicates can only be defined by loading a source file with a `:- table ...` directive. The directive creates a _wrapper predicate_ and the real predicate is renamed. This has some unpleasant consequences:

- As said, we cannot (in a nice and supported way) create tabled predicates on the fly.
- All the usual predicate inspection and modification affects the wrapper rather than the thing itself.
- We cannot switch between tabled and non-tabled execution for a predicate.

Some way to execute Prolog code before/after any predicate was already part of Quintus AFAIK. It provides a huge opportunity for debugging tools, ranging from logging, conditional spy points, checking the execution by verifying pre- and post conditions, determinism, etc.

What I now have is a predicate like this:

```prolog
%! wrap_predicate(:Head, +Name, -Closure, +Body) is det.
%
% Wrap the predicate referenced by Head using Body. Subsequent calls
% to Head call the given Body term. Body may call the original
% definition using a term
%
% call(Closure, A1, ...)
%
% Name names the wrapper for inspection using predicate_property/2 or
% deletion using unwrap_predicate/2.

```

This allows us to write e.g.,

```prolog
det(M:Name/Arity) :-
    functor(Head, Name, Arity),
    Head =.. [_|Args],
    Wrapped =.. [call, Closure|Args],
    wrap_predicate(M:Head, det, Closure,
		   ( prolog_current_choice(Ch0),
                       Wrapped,
                       prolog_current_choice(Ch1)
		   -> ( Ch0 == Ch1
		       -> true
		       ; throw(error(det_error(nondet, M:Head), _))
		       )
		   ; throw(throw(error(det_error(failed, M:Head), _)))
		   )).

```

Which validates that a predicate is indeed deterministic (succeeds and leaves no choice point behind). We can use this at any time to start checking a predicate, **even before it is defined**.

Current properties:

- Wrappers may be added before or after defining the predicate
- Wrappers are named.
- A predicate can have multiple wrappers. The execution is simply nested, starting with the last added wrapper.
- Wrappers may be deleted by name or variable to delete the outermost (last added) wrapper
- Adding/deleting wrappers is thread-safe, which allows for e.g., temporary wrapping a predicate to track activity of another thread.
- The wrapper may, but need not to call the real implementation. That is hard to avoid with this design and can be considered a feature or a bug.
- All predicates can be wrapped, even built-ins. Only built-ins that are implemented as virtual machine instructions (`true`, `fail`, unification, comparison, (optimized) arithmetic), etc.) cannot be wrapped.

**Questions**

- One of the things I’m struggling with is whether we should allow for multiple wrappers with the same name on a predicate. One of the disadvantages is that when using the above det/1 as a directive in a source file, every re-load will add another layer of wrappers ☹ If we deny that, we have some options, such as replacing the existing wrapper while maintaining order, rejecting or delete the old, adding the new as outermost.
- Should _wrapping_ be the leading term to refer to this functionality?
- Any prior art from which to borrow terminology and functionality?
- Any use cases that need a different API?

**Implementation**

For those who want to know how it works, Creating a wrapper creates a predicate `__wrap$<name>` with the same arity as the predicate being wrapped. The _Body_ is used to create a clause for this predicate. Any SWI-Prolog predicate is executed by starting its _supervisor_: a (short) sequence of VM instructions that depends on the implementation (C, dynamic, thread-local, etc) and indexing of the predicate. Wrapping creates a closure _blob_ that allows us executing a predicate with a specific supervisor instead of the default one. That is passed as _Closure_ above. Wrapping replaces the supervisor of the wrapped predicate to call the wrapper clause in the `__wrap$<name>` predicate. The overhead is pretty low 🙂

---

<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:** [May 19, 2019, 2:55pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/2 "2019-05-19T14:55:02Z")

</div>

> [@jan](#):
>
> Any prior art from which to borrow terminology and functionality?

This sounds like/reminds me of [Aspect-oriented programming](https://en.wikipedia.org/wiki/Aspect-oriented_programming). 🥴

---

<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:** [May 19, 2019, 3:00pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/3 "2019-05-19T15:00:40Z")

</div>

You are right. Thanks for reminding. Aspect-oriented programming through program transformation is not uncommon in the Prolog world. Tabling is also a form of Aspect-oriented programming where you disconnect the program from the resolution strategy.

---

<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:** [May 19, 2019, 3:27pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/4 "2019-05-19T15:27:06Z")

</div>

In det/1

> [@jan](#):
>
> ```prolog
> Head =.. [_|Args], 
> Wrapped =.. [call, Closure|Args]
> 
> ```

I wonder whether we should lift that to wrap\_predicate/4, i.e., passing a callable term that calls the unwrapped predicate. That has the advantage of simplifying usage. It makes it more awkward if you want call the original predicate with different arguments though, forcing the user to modify the callable term. Surely someone will sooner or later wish to do so 🙂 I do not see much use for changing the call except for quick and dirty work arounds for some bug. This is still possible, but a bit harder.

---

<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:** [May 19, 2019, 3:48pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/5 "2019-05-19T15:48:07Z")

</div>

> [@EricGT](#):
>
> > Any prior art from which to borrow terminology and functionality?
> 
> This sounds like/reminds me of [Aspect-oriented programming](https://en.wikipedia.org/wiki/Aspect-oriented_programming). 🥴

Indeed 🙂 But there is prior art to AOP. E.g. _before_, _around_, and _after_ methods from OO extensions to LISP. Logtalk implementation of _event-driven programming_ allows the programmer to define _before_ and _after_ event handlers that can also be seen as predicate wrappers. The semantics of these handlers (see [Event-driven programming — The Logtalk Handbook v3.72.0 documentation](https://logtalk.org/manuals/userman/events.html)) touch some of the questions that Jan are asking (both explicitly and implicitly). But my quick reading of Jan proposal (and notably his example) is that the wrappers will work as _around_ methods. That’s something that I always wanted to have and I will be looking closely to his proposal… tomorrow (too tired from MTB today 😛).

---

<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:** [May 19, 2019, 3:59pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/6 "2019-05-19T15:59:46Z")

</div>

> [@pmoura](#):
>
> _around_ methods

I was aware of _before_ and _after_ methods. For Prolog we have to watch 4 _ports_ (5 if we add exceptions) though, making this rather complicated. _Around methods_ are arguable the most generic. I can see some disadvantages

- The around method may not call the thing wrapped.
- The wrapper can make arbitrary changes to the semantics.

I consider this in general misuse in the same family as directly calling private predicates inside modules, i.e., you should typically not do that but it is sometimes useful that you can 🙂

---

<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:** [May 19, 2019, 4:11pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/7 "2019-05-19T16:11:15Z")

</div>

> [@jan](#):
>
> _Around methods_ are arguable the most generic.

That depends on the **composition** semantics being the same. By supporting both before/after methods and around methods, we can provide and benefit from the availability of different composition semantics.

---

<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:** [May 19, 2019, 4:16pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/8 "2019-05-19T16:16:21Z")

</div>

> [@jan](#):
>
> The execution is simply nested, starting with the last added wrapper.

IIRC starting with the last wrapper added is a problem because if the new wrapper changes something then all the down stream wrappers become affected thus putting the responsibility on the creator of each wrapper to adjust to the changes made by the last added wrapper. On the other hand if the wrappers are executed in the order they are added then then once a wrapper is in place and working, the person creating the wrapper may have to dance around the mistakes of an earlier wrapper but the code doesn’t cause other developers to go back and fix a working begin/end wrapper.

Then there there could also be problems with paired before/after wrappers such as transactions. Should all the logging be done within the transaction, outside the transaction or have one set of logging before the transaction starts and another after the logging starts.

I think while a default of first added first called is reasonable, there should be room left open in case a more complex means of ordering and paring of the wrappers is needed.

I have to admit that the only development related to this I can currently recall is

1. Begin/end with unit testing
2. Low level calling conventions to C and assembly code, (Think [Endianness](https://en.wikipedia.org/wiki/Endianness)) and stack setup/cleanup.
3. Event models of browsers (That was during the Netscape - Microsoft wars of the late 1990s).

Usually when I get near problems like this at a higher level I try to switch to a functional language like F# with functional composition or in other paradigms switch to events and [trampolining](https://en.wikipedia.org/wiki/Trampoline_(computing)) . 🙂

---

<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:** [May 19, 2019, 4:32pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/9 "2019-05-19T16:32:25Z")

</div>

> [@EricGT](#):
>
> IIRC starting with the last wrapper added is a problem because if the new wrapper changes something then all the down stream wrappers become affected thus putting the responsibility on the creator of each wrapper to adjust to the changes made by the last added wrapper.

A **key design decision** is indeed if the wrappers are allowed to change the goal being wrapped. In Logtalk, the answer is **no** :

> The execution of actions, defined in a monitor, associated to each event, never affects the term that denotes the message involved.

The relevant code in the runtime is:

```prolog
% '$lgt_guarded_method_call'(+object_identifier, +callable, +object_identifier, +callable)
%
% wraps the method call with the before and after event handler calls; the "before" event handler
% may prevent a method from being executed by failing and an "after" event handler may prevent a
% method from succeeding by failing; however, event handlers cannot modify the method call

'$lgt_guarded_method_call'(Obj, Msg, Sender, Method) :-
	% call before event handlers
	\+ ('$lgt_before_event_'(Obj, Msg, Sender, _, Before), \+ Before),
	% call method
	call(Method),
	% call after event handlers
	\+ ('$lgt_after_event_'(Obj, Msg, Sender, _, After), \+ After).

```

---

<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:** [May 19, 2019, 5:23pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/10 "2019-05-19T17:23:48Z")

</div>

> [@pmoura](#):
>
> The execution of actions, defined in a monitor, associated to each event, never affects the term that denotes the message involved.

That seems to support my idea to make a term available that calls the things being wrapped unmodified. Your before and after handlers may fail, causing the method to fail. What is the reasoning behind that?

> [@pmoura](#):
>
> That depends on the **composition** semantics being the same. By supporting both before/after methods and around methods, we can provide and benefit from the availability of different composition semantics.

Not sure I get that. Seems with an _around_ method one can always do the same as with any set of before and after handlers. Yes, what you do before calling and after calling can bind goal variables. That is not a good idea, but allows for things such as reporting the CPU time used by a predicate.

---

<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:** [May 19, 2019, 5:47pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/11 "2019-05-19T17:47:14Z")

</div>

> [@EricGT](#):
>
> Usually when I get near problems like this at a higher level I try to switch to a functional language like F# with functional composition or in other paradigms switch to events and [trampolining](https://en.wikipedia.org/wiki/Trampoline_(computing)) . 🙂

SWI-Prolog has quite a rich pallet of primitives to run things out of order: attributed variables, delimited continuations and engines 🙂

You are raising some interesting points though. I never considered much more than tabling and debugging. Just wrapping arbitrary goals with the idea to make them do something more or even different than what they were designed for feels way worse then _goto_. I always want to reason about concrete scenarios. Your transaction/logging seems one.

I guess the most meaningful composition is to use logging as outer wrapper so we can see when an action failed due to a transaction conflict. Where and how do we want to use this knowledge?

Technically is is quite easy to add a wrapper that is not the outermost one. So, if there is feeling this is useful we should add that to the interface.

---

<div class="post-metadata">

**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\
**Post date:** [May 19, 2019, 5:56pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/12 "2019-05-19T17:56:35Z")

</div>

One other piece of prior art is Python, where

```prolog
@wrapper
def foo(x): ...

```

is an abbreviation for(\*)

```prolog
def foo(x): ...
foo = wrapper()(foo)

```

The wrapper (called “decorator” in Python) can’t look inside the function,(\*\*) so the wrapper functionality is mainly used to add functionality (e.g., caching or “read only”). In general, it’s possible to compose decorators, although this seems to be rare.

Surprisingly, this simple capability seems to have covered most of the use cases for macros or preprocessors.(\*\*\*) Of course, Prolog is used for more complex data structures than the typical Python program, but it’s instructive to see how much can be done with a relatively simple and safe feature.

(\*) It’s a bit more complicated than this (note that `wrapper()` returns a function), but I don’t want to get into the details. Also, the “more complicated” part is one reason why this tends to be a “for experts only” feature.

(\*\*) In Python, it is possible to look at the byte codes, but this is generally frowned for obvious reasons.

(\*\*\*) There are some packages for manipulating Python ASTs, but they tend to be used for whole program transformations.

---

<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:** [May 19, 2019, 6:15pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/13 "2019-05-19T18:15:28Z")

</div>

> [@jan](#):
>
> > The execution of actions, defined in a monitor, associated to each event, never affects the term that denotes the message involved.
> 
> That seems to support my idea to make a term available that calls the things being wrapped unmodified. Your before and after handlers may fail, causing the method to fail. What is the reasoning behind that?

Notably, it allows event handlers to work as message (goal) _guards_.

> [@jan](#):
>
> ![](https://global.discourse-cdn.com/free1/uploads/swiprolog/original/1X/919b58d6abd25e404a29a79678bb170fc6ba0770.png) pmoura:
> 
> > That depends on the **composition** semantics being the same. By supporting both before/after methods and around methods, we can provide and benefit from the availability of different composition semantics.
> 
> Not sure I get that.

A major aspect of the composition semantics is the **order** of applying/calling before/around/after handlers when multiple ones are defined. One option is to tell the programmer that he/she cannot rely on order (analogous to the usual advice for multifile predicates). That’s the design choice in Logtalk, btw (see the link I provided earlier). But you can also, in alternative, use handler registration order and choose either last registered handler applies first or last. Thus, you can use one of these choices for before/after handlers and a different choice for around handlers.

> [@jan](#):
>
> Seems with an _around_ method one can always do the same as with any set of before and after handlers. Yes, what you do before calling and after calling can bind goal variables.

Not in the Logtalk case. Glad that you agree that is not a good idea.

> [@jan](#):
>
> That is not a good idea, but allows for things such as reporting the CPU time used by a predicate.

Hum? That doesn’t not require the handlers to be able to _modify_ (i.e. further instantiate) the wrapped message/goal term. Am I missing something in this particular usage example?

---

<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:** [May 19, 2019, 6:26pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/14 "2019-05-19T18:26:28Z")

</div>

> [@peter.ludemann](#):
>
> The wrapper (called “decorator” in Python) can’t look inside the function,(\*\*) so the wrapper functionality is mainly used to add functionality (e.g., caching or “read only”). In general, it’s possible to compose decorators, although this seems to be rare.
> 
> Surprisingly, this simple capability seems to have covered most of the use cases for macros or preprocessors.(\*\*\*) Of course, Prolog is used for more complex data structures than the typical Python program, but it’s instructive to see how much can be done with a relatively simple and safe feature.

Interesting. I should learn Python one of these days 😛 There’s one significant usage case for wrappers that’s worth emphasizing: it allows writing applications that _react_ to what happens at runtime without breaking the encapsulation of the observed/monitored entities **and** without requiring cooperation of those entities (as e.g. in the Smalltalk’s _dependents_ mechanism). This, btw, strongly suggests that the best design decision is to not allow wrappers to modify the wrapped goals.

---

<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:** [May 19, 2019, 6:34pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/15 "2019-05-19T18:34:11Z")

</div>

> [@pmoura](#):
>
> Am I missing something in this particular usage example?

Simply things such as

```prolog
statistics(cputime, T0),
Wrapped,
stattistics(cputime, T1),
T is T1 - T0,
...

```

This requires _T0_ to be preserved.

> [@pmoura](#):
>
> This, btw, strongly suggests that the best design decision is to not allow wrappers to modify the wrapped goals

I fully agree this is in general a bad idea. Using _around_ wrappers it is hard to avoid that wrappers can affect the semantics of the wrapped goal. For tabling this is actually what we want 🙂 Still @EricGT hints that even without modifying the wrapped goal we may want a particular order.

---

<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:** [May 19, 2019, 6:55pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/16 "2019-05-19T18:55:10Z")

</div>

But `T0` is not a variable in `Wrapped`; it’s added by the wrapper itself. What I have been emphasizing is that a wrapper should have access to `Wrapped` bindings but not be able to further instantiate `Wrapped`. That recommendation doesn’t prevent your example from working.

Regarding relying on a particular order, that would be as bad as relying on the order of multifile predicate clauses. Eric, do you have where a specific case where a wrapper calling fixed order would be convenient or even required? Ideally, there will be a better way to handle such cases.

---

<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:** [May 19, 2019, 7:01pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/17 "2019-05-19T19:01:00Z")

</div>

> [@jan](#):
>
> I guess the most meaningful composition is to use logging as outer wrapper so we can see when an action failed due to a transaction conflict. Where and how do we want to use this knowledge?

The mixing of the transactions and logging were just something to think about. At the start the basic use-cases you purpose would be a worthy accomplishment. Once those have had time to settle and real usage feedback arrives then expanding out to these ideas might be desired.

I do agree at the start with with @pmoura`A key design decision is indeed if the wrappers are allowed to change the goal being wrapped. In Logtalk, the answer is no:` I take this to mean that the API does not change and the structure of the values are not altered.

However if/when the scenarios get more complex in the future a feature of F# widely used and liked is  
[F# computation expressions](https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions). The part of it I want to bring over to this idea is that with computation expression they encapsulate the details of the concept into the syntax of the language thus hiding the details from the user. It is very simple and expressive. In the same light that DCG is syntactic sugar this could be implemented as syntactic sugar. See: [The “Computation Expressions” series](https://fsharpforfunandprofit.com/series/computation-expressions.html)

---

<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:** [May 19, 2019, 7:38pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/18 "2019-05-19T19:38:40Z")

</div>

> [@pmoura](#):
>
> But `T0` is not a variable in `Wrapped` ; it’s added by the wrapper itself. What I have been emphasizing is that a wrapper should have access to `Wrapped` bindings but not be able to further instantiate `Wrapped` . That recommendation doesn’t prevent your example from working.

But, _T0_ must remain bound. This implies we cannot call the _before_ part in a (double) negation to avoid binding. As you (correctly) state that the wrapper requires access to the bindings as well, I do not really see how you would like to prohibit it from binding these arguments. We could split the before part into two pieces, but this too doesn’t help. Suppose we want to write a wrapper that verifies that the arguments are not further instantiated by some goal. We should write this using term\_variables/2 to get the variables and pass these to _after_ part.

Thus far I cannot see a sensible way for the system to prevent misbehaving wrappers using _around_ methods. As I said, my primary use case is tabling which is a misbehaving wrapper 🙂

---

<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:** [May 19, 2019, 8:52pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/19 "2019-05-19T20:52:20Z")

</div>

I never found a way to implement _around_ methods using _before_ and _after_ methods. I don’t say that it is not possible but I doubt it. As your example illustrates, the semantics are not compatible. The snippet of code that I posted from the Logtalk runtime uses two inlined `forall/2` goals to run all handlers without ever binding variables in the wrapped goal. That snippet was not meant to illustrate a suggested implementation for _around_ methods, however, just to show how the semantics for _before_ and _after_ methods are implemented. We ended up discussing different aspects.

I think we’re in agreement that (1) your example doesn’t require modifying the wrapped goal but (2) does require the _around_ method before and after **steps** (which should not to be confused with _before_ and _after_ **methods** ) to be part of the same conjunction of goals (is there a better way to phrase it?), which (3) precludes using a negation based solution to run all defined handlers.

---

<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:** [May 19, 2019, 9:03pm UTC](https://swi-prolog.discourse.group/t/wrapping-predicates/668/20 "2019-05-19T21:03:34Z")

</div>

> [@pmoura](#):
>
> Eric, do you have where a specific case where a wrapper calling fixed order would be convenient or even required?

Off the top of my head security might be of importance because another layer might inadvertently disclose something, e.g. a catch returns a message that gives the internal address of a server or something worse like an unencrypted password gets logged.

[Next page](https://swi-prolog.discourse.group/t/wrapping-predicates/668.md?page=2)