Restricting goal_expansion/6 to compile time only
Asked Answered
P

2

5

In SICStus Prolog, there is a hook for expanding a goal: goal_expansion/6 which is called both at compile time and at runtime during metacalling. These calls incur quite some runtime overhead which slows down metacalling. The purpose of my expansion is optimization only. So semantically the goals and expanded goals are equivalent.

How can I disable such calls at runtime?

(It seems I would have to abolish goal_expansion/6 which looks a bit crass to me. It would also hamper lightweight recompilation).

Podvin answered 30/3, 2016 at 19:53 Comment(2)
I would even support the view that optimization is the only legal use of goal expansion. That would imply that it is always optional, and should probably not be done automatically for metacalls and maybe even asserts.Stanton
@jschimpf: (speculation only) Maybe other uses involve some special handling of meta-arguments, or macro-like things. Not that I am aware of such use. Like: adding debugging information.Podvin
O
5

The idiomatic way is to load the compile-time-only code using load_files/3 with option when(compile_time). Unfortunately, this does not help if you want to (re)compile in the same process in which you then run your code.

Using abolish to remove the definition of goal_expansion/5 is also not ideal (since it will be gone if you then re-compile). It is not as bad/crass as it seems, though: goal_expansion/5 is per module, so you can abolish it without worrying that you destroy some functionality in some other module.

Osteen answered 30/3, 2016 at 22:46 Comment(0)
R
4

A workaround would be to call the prolog_load_context/2 predicate. Something like:

goal_expansion(...) :-
    prolog_load_context(source, _),
    % compile-time; expand the goal
    ... .

The prolog_load_context/2 predicate only succeeds at compile time.

Ripply answered 30/3, 2016 at 22:18 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.