Interface for Clean programmers
We need to decide on how the interface to the dynamics interpreter will look to the end user (the programmer); this has many implications for the implementation:
- Should the dynamic be interpreted in a separate memory block?
- Should it be possible to pose restrictions on the dynamic? For example:
- Set heap and stack size;
- Set a timeout for computation to a head normal form;
- Disallow certain 'unsafe' ABC instructions, such as
openF
,writeFS
etc. for dealing with files.
To keep in mind:
- It should be possible to evaluate many different dynamics in parallel.
- We need to match descriptors from the dynamic and from the main program. If the dynamic is interpreted in a separate memory block, when HNFs are copied the descriptor needs to be translated. If it is interpreted in the same block, descriptors in the bytecode need to be translated prior to interpreting.
- JIT compilation should be possible in the future.
To do:
-
There now is a sample program CodeSharing.icl
which reads an expression frominfprimes.bc
and evaluates the first 100 elements (it is a list). This needs to be generalised into a library. There are some hacks, e.g. to build a Start graph by guessing the position of the Start label in the bytecode. -
Copy nodes from interpreter to host, in C, using a string_to_graph-like function (!47 (merged)) -
Copy nodes from host to interpreter, in C, using a graph_to_string-like function
To think about when doing that:
-
How to translate nodes? There are three different cases:
- The descriptor exists in the host program. These nodes can be translated.
- The descriptor does not exist in the host program. A new descriptor needs to be added to the data segment of the host program, because when interpretation is done the bytecode should be thrown away. Then, the nodes should be translated to these new descriptors.
- A descriptor with the same name exists in the host program, but it is different. This may be caused by different versions of a library. This needs to be detected and then handled as the second case.
Presumably it is practical to store a translation table somewhere and fill it as needed.
-
Can we reuse host descriptors? For instance, if a bytecode program uses lists and has the
Cons
andNil
descriptors for this, is it possible to make it use the native descriptors instead by updating all labels? This would mean translating the bytecode program once to match it with the host program and start running only after that. This will make descriptor translation (see below) trivial.If this is possible, it also means that you get applying bytecode functions on native expressions (e.g., a bytecode function
[Int] -> Int
on a native list) for free, because the descriptors match. If not, we need to be able to translate descriptors in both directions, and deal with the issues of non-existing descriptors (see below).