Eval and code interpretation
|
|
Bigloo includes an interpreter. Unfortunately, the language accepted by the
interpreter is a proper subset of that accepted by the compiler. The main
differences are:
- No foreign objects can be handled by interpreter.
- None of the object system constructions are available from the
interpreter.
- The interpreter ignores modules, and has a unique global environment.
Compiled code and interpreted code can be mixed together. That
is, interpreted code is allowed to call compiled code and vice
versa. This connection can be use to circumvent the missing
features of the interpreter (see Section see Module Declaration,
for a description of how to connect compiled and interpreted code).
12.1 Eval standard functions
|
This form evaluates exp . The second argument is optional. It can be
the evaluation of one of these three function forms:
(scheme-report-environment 5)
(null-environment 5)
(interaction-environment)
|
|
scheme-report-environment version | procedure |
null-environment version | procedure |
interaction-environment version | procedure |
These three procedures have the definitions given in the R5RS so see
info-file `r5rs.info', 6.5 Eval, for more
details.
|
This invokes the read-eval-print loop. Several repl
can be embedded.
The repl function can be used to implement custom Bigloo interpreters.
For instance, one may write:
When compiled, this will deliver an executable containingthe sole Bigloo interpreter.
|
This exits from the currently running repl . If the current
repl is the first one then this function ends the interpreter.
|
set-prompter! proc | bigloo procedure |
The argument proc has to be a procedure of one argument and invoking
this function sets the repl prompter. That is, to display its prompt,
repl invokes proc giving it the nesting level of the
current loop as its argument.
|
get-prompter | bigloo procedure |
Returns the current repl prompter.
|
set-repl-printer! proc | bigloo procedure |
The argument proc has to be a procedure accepting one or two arguments.
This function sets the repl display function. That is, to display the
result of its evaluations, repl invokes proc giving it the
evaluated expression as first argument and the current output port (or
a file in case of transcript) as second argument. Set-repl-printer!
returns the former repl display function.
For instance, one may write:
1:=> (define x (cons 1 2)) -| X
1:=> (define y (cons x x)) -| Y
1:=> y -| (#0=(1 . 2) . #0#)
1:=> (set-repl-printer! display) -| #<procedure:83b8c70.-2>
1:=> y -| ((1 . 2) 1 . 2)
|
|
native-repl-printer | bigloo procedure |
Returns the native (default) repl display function.
|
expand exp | bigloo procedure |
Returns the value of exp after all macro expansions
have been performed.
|
expand-once exp | bigloo procedure |
Returns the value of exp after one macro expansion has been performed.
|
It is possible to specify files which have to be loaded when the interpreter
is invoked. For this, see section see Compiler Description.
If a Bigloo file starts with the line:
and if this file is executable (in the meaning of the system) and if the user
tries to execute it, Bigloo will evaluate it. Note also that SRFI-22 support
enables to run any Unix interpreter (see SRFIs).
load filename | bigloo procedure |
loadq filename | bigloo procedure |
Filename should be a string naming an existing file which contains
Bigloo source code. This file is searched in the current directory and
in all the directories mentioned in the variable *load-path* .
The load procedure reads expressions and
definitions from the file, evaluating them sequentially. If the file
loaded is a module (i.e. if it begins with a regular
module clause), load behaves as module initialization. Otherwise, this
function returns the result of the last evaluation. The function oadq
differs from the function load in the sense that loadq does
not print any intermediate evaluations.
Both functions return the full path of the loaded file.
|
loada filename | bigloo procedure |
Loads an ``access file'', which allows the interpreter to find
the modules imported by a loaded module. It returns the full path
of the loaded file.
|
*load-path* | bigloo variable |
A list of search paths for the load functions.
|
dynamic-load filename [init-point] | bigloo procedure |
Load a shared library named filename . The function
returns the name of the loaded library. If init-point is
specified and if it is a string and if the library defines a function
named init-point , this function is called when the library is
loaded. Init-point is a C identifier, not a Scheme identifier. In
order to set the C name a Scheme function, use the extern export
clause (see Section see C Interface). If the init-point value
is not provided, once the library is loaded, dynamic-load uses
the Bigloo default entry point. Normally you should not provide
an init-point to dynamic-load unless you known what you are
doing. When producing C code, to force the Bigloo compiler to emit such
a default entry point, use the -dload-sym compilation option (see
Section see Compiler Description). This option is useless when using
the JVM code generator. Let's assume a Linux system and two Bigloo
modules:
(module mod1
(eval (export foo))
(export (foo x)))
(define (foo x)
(print "foo: " x))
(foo 4)
|
(module mod2
(import (mod1 "mod1.scm"))
(eval (export bar))
(export (bar x)))
(define (bar x)
(print "bar: " x))
(bar 5)
|
If these modules are compiled as:
$ bigloo mod1.scm -c -o mod1.o
$ bigloo mod2.scm -c -o mod2.o -dload-sym |
Then, if a shared library is built using these two modules:
$ ld -G -o lib.so mod1.o mod2.o |
Then, lib.so cant be dynamically loaded and the variables it defines
used such as :
$ bigloo -i
(dynamic-load "lib.so")
-| foo: 4
bar: 5
1:=> (foo 6)
-| foo: 7
|
As the example illustrates, when Bigloo modules are dynamically loaded,
they are initialized. This initialization is ensure only if
dynamic-load is called with exactly one parameter. If
dynamic-load is called with two parameters, it is of the
responsibility of the program to initialize the dynamically loaded
module before using any Scheme reference.
Note: In order to let the load module access the variables
defined by the loader application, special compilation flags must be
used (e.g., -rdynamic under the Linux operating
system). Dynamic-load is implemented on the top of the
dlopen facility. For more information read the dlopen and
ld manuals.
|
*dynamic-load-path* | bigloo variable |
A list of search paths for the dynamic-load functions.
|
transcript-on filename | procedure |
|
default-repl-error-notifier proc obj msg | bigloo procedure |
This function is the default notifier used to print out error message in
the repl
|
set-repl-error-notifier! notifier | bigloo procedure |
get-repl-error-notifier::procedure | bigloo procedure |
These procedures set and get the repl-error-notifier . The argument
notifer is a procedure of three arguments.
|
12.2 Eval command line options
|
This section presents the Bigloo compiler options that impact the interaction
between compiled and interpreted code. The whole list of the Bigloo
compiler options can be found in
The Bigloo command line.
-i Don't compile a module, interprets it!
-export-all Make all the bindings defined by
the compiled module available from the interpreter.
-export-export Make all the bindings exported by the
compiled module available from the interpreter.
-export-mutable Make all the bindings exported by the
compiled module mutable from outside the module. This option is
dangerous! Either all the modules composing the application
must be compiled with or without -export-mutable . It is impossible
to mix -export-mutable enabled and disabled compilations.
12.3 Eval and the foreign interface
|
To be able to get access to foreign functions within the Bigloo
interpreter, some extra measurements have to be taken. The foreign
functions have to be present in the interpreter binary, which means you
have to compile a custom interpreter. This is described in
Section Using C bindings within the interpreter.
|