12. Bigloo -- Eval and code interpretation

Browsing
Home: | Bigloo A ``practical Scheme compiler'' User manual for version 2.6b December 2003
Previous chapter: | Errors and Assertions
Next chapter: | Macro expansion
Eval and code interpretation
12.1 | Eval standard functions
12.2 | Eval command line options
12.3 | Eval and the foreign interface
Chapters
| Acknowledgements
1. | Table of contents
2. | Overview of Bigloo
3. | Modules
4. | Core Language
5. | Standard Library
6. | Pattern Matching
7. | Object System
8. | Threads
9. | Regular parsing
10. | Lalr(1) parsing
11. | Errors and Assertions
12. | Eval and code interpretation
13. | Macro expansion
14. | Command Line Parsing
15. | Explicit typing
16. | The C interface
17. | The Java interface
18. | Bigloo Libraries
19. | Extending the Runtime System
20. | SRFIs
21. | DSSSL support
22. | Compiler description
23. | User Extensions
24. | Bigloo Development Environment
25. | Global Index
26. | Library Index
| Bibliography
| 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
eval exp [env] | procedure
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.

repl | bigloo procedure
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:
    (module repl)
    (repl)
When compiled, this will deliver an executable containingthe sole Bigloo interpreter.

quit | bigloo procedure
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:

     #! bigloo-command-name

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
transcript-off | 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.

This Scribe page has been generated by `scribeinfo`.
Last update Tue Dec 16 13:46:41 2003