File: README.oldforeign

package info (click to toggle)
swi-prolog 3.1.0-2
  • links: PTS
  • area: main
  • in suites: slink
  • size: 8,772 kB
  • ctags: 12,869
  • sloc: ansic: 43,657; perl: 12,577; lisp: 4,359; sh: 1,534; makefile: 798; awk: 14
file content (79 lines) | stat: -rw-r--r-- 2,704 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
	      Using old-style foreign code with SWI-Prolog 2.5


1.  Introduction
================

The foreign language interface  has   been  changed  drastically between
version 2.1.14 and 2.5.0 (there are no intermediate releases). This file
describes some considerations for converting old code.


2.  Rewrite your interface?
===========================

If you have only a small porting of   C, you can consider rewriting your
interface. The new code will generally run   faster,  is easier to write
and read and your code again be  compatible with many future releases of
SWI-Prolog. In addition, it will be much   easier  to run your code with
Quintus or SICStus Prolog (basically  declare   the  type as `+term' and
write macros to deal with the different   names  of the functions in all
three Prolog systems).

Below are some example code fragments and their translation:

READING ARGUMENTS
****************************************************************
{ if ( PL_is_integer(x) )
  { long n = PL_integer_value(PL_atomic(x));
    
    ...
================================================================
{ long n;

  if ( PL_get_long(x, &n) )
  { ...
****************************************************************

WRITING ARGUMENTS
****************************************************************
pl_get_something(term x)
{ char *answer = getsomething();

  return PL_unify_atomic(x, PL_new_atom(answer));
}
================================================================
pl_get_something(term x)
{ char *answer = getsomething();

  return PL_unify_atom_chars(x, answer);
}
****************************************************************


3. Using backward compatibility feature
=======================================

Alternatively, you may decide to use the backward compatibility flag:

#define PL_OLD_INTERFACE
#include <SWI-Prolog.h>

You can NOT mix old and new code in the same file (but Prolog can handle
object-files holding both old and new code).

You can expect  a  number  of   warning  from  your  compiler.  Notably,
PL_new_atom() used to return an unsigned long, while it returns a void *
in the new interface.

Using the backward compatibility feature is   not  entirely safe against
garbage-collection,  at  least  not  when    the  garbage-collector  and
stack-shifter will be complete. Notably the  `atomic' handles of strings
can be invalidated by a stack-shift or garbage collection.

The new interface PL_put_*()  functions  allow   for  the  reuse of term
references. In the old code, PL_arg(),  etc. create a new term-reference
for each argument extracted.

PL_call_predicate() is only available with  the new calling conventions.
PL_call() based callback will work.