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).

Community
  • 1
  • 1
false
  • 10,264
  • 13
  • 101
  • 209
  • 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. – jschimpf Mar 31 '16 at 13:05
  • 1
    @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. – false Mar 31 '16 at 13:16

2 Answers2

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.

Per Mildner
  • 10,469
  • 23
  • 30
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.

Paulo Moura
  • 18,373
  • 3
  • 23
  • 33