TransLucid preamble
There are now a number of TransLucid examples available at the TransLucid Web site.
All of these examples use the declarations found in the preamble.
http://translucid.web.cse.unsw.edu.au/examples/header.tl
There are now a number of TransLucid examples available at the TransLucid Web site.
All of these examples use the declarations found in the preamble.
http://translucid.web.cse.unsw.edu.au/examples/header.tl
To help gather the open problems related to implementing TransLucid,
a publication archive has been prepared. It is available at
http://plaice.web.cse.unsw.edu.au/archive
Included in that archive are the collected works of John Plaice,
Blanca Mancilla and Bill Wadge, along with all of the papers
presented at the International Symposia on Lucid and
Intensional Programming and the Conferences on
Distributed Communities on the Web.
It has taken a long time to come, but the first release of TransLucid,
version 0.1.0, is out. It is available at the following link.
http://sourceforge.net/projects/translucid/files/TransLucid/0.1.0/tl-0.1.0.tar.bz2/download
The interpreter needs to be formalized once the operational semantics is finished. This is a necessary step towards writing TransLucid in TransLucid. The key missing parts for writing TL in TL are:
1. Besfitting
2. Parsing (a form of bestfitting)
3. Printing (a form of bestfitting)
4, Libraries
We are close on all of these. But nothing is finalized.
1. We need a good algorithm to determine the bestfit equation. The best I can think of would be n^2 because it has to determine for every equation whether it is more specific than every other.
2. Not sure about how to tackle this still. Some sort of recursive descent thing which mimics spirit could be feasible. I can see that in the future we could even beat spirit, possibly blowing it out of the water. We quite possibly need functions in TL to do this.
3. String operations are probably required, apart from that it seems trivial.
4. It seems that we just need some proper semantics. At the moment a library adds equations when it’s loaded. Libraries are currently written in c++, we could allow these to be translucid files too.
If you store information separately for each variable, then testing applicability is linear in the number of entries for that variable. Among the applicable entries, finding bestfit ones is quadratic in the number of applicable entries.
This can be improved by using just-in-time ideas. After each modification of the set of equations for a variable, the first time that a demand is made for that variable would force the creation of a finite-state automaton that would be run upon any request for that variable (until, of course, the next modification to the set of equations).
The initial implementation can be done using the linear-quadratic solution. Just-in-time ideas can be kept for future optimization.
what about including priority in that?
Dimensions necessary for the proper behaviour of the system should not be allowed to be manipulated. That includes deletion. Should we write the TransLucid interpreter in TransLucid, we will reconsider this decision. This will allow rewriting, optimization and specialization of the interpreter as in Smalltalk.
That makes sense, it’s fairly trivial to do too. Although we should define semantics better, currently it is just in the c++ interface that dimensions can be deleted. It would be better if it was all consistent with time and so on and could actually be done with in TransLucid too.
Just to confirm the email exchange, system dimensions will be put in a separate symbol table in the parser so that way they have a container which has a list of all their names, accessible to the programmer.
tlcore --uuid
%%
x=5;;
%%
x;;
4557f67592cb498fa684d50f5511a65
intmp<5>
This is neat, here are a few comments.
1. The output from the equations section should be separated from the output from the expressions section with a %%.
2. The uuid “4557f67592cb498fa684d50f5511a65” should read “uuid<4557f67592cb498fa684d50f5511a65>“.
3. The output from the equations section is not taking into account the –verbose option.
4. In –verbose mode, we should output equations, demands and expressions as eqn<…>, dem<…> and expr<…>, respectively.
5. Should there be ;; at the end of each line of output?
6. Should there be a separator between the input and output? As in a line —?
uuid or uuid … ?
The rest is easily fixed.
Problems with angle brackets. Now fixed.
and my reply got broken with the angle brackets too, that doesn’t say what I intended it to.
The fix looks good. Points 5 and 6 should be tried out. For point 6, that is two dashes on a separate line, to separate the input lines from the output lines. In the reactive mode, there should be two lines with two dashes, before and after each output. If this is too verbose, we can remove it.
When the –demands option is set in tlcore, then it can handle demands. In this case, in each instant, there are four parts, not three. The fourth part is introduced with another %% pair, as follows:
header
%%
equations
%%
demands
%%
expressions
$$
header
%%
equations
%%
demands
%%
expressions
$$
...
A demand requests that a variable be computed in a specific context. It is written as a pair
(x,tuple);;
and it is registered internally by the system with a UUID. At each instant, should the tuple be valid in that instant, then this pair is evaluated, producing the result, along with the other expressions. The response for an instant therefore looks like this:
dem_{1} → demanswer_{1};;
...
dem_{m} → demanswer_{m} ;;
%%
answer_{1};;
...
answer_{n};;
If the –uuid option is set, then the UUID of the demands is printed out, as it is for equations:
eqnuuid_{1};;
...
eqnuuid_{l};;
%%
dem_{1} → demuuid_{1} → demanswer_{1};;
...
dem_{m} → demuuid_{m} → demanswer_{m} ;;
%%
answer_{1};;
...
answer_{n};;
Should the –verbose option also be set, then the results will be of the form
eqn_{1} → eqnuuid_{1};;
...
eqn_{l} → eqnuuid_{l};;
%%
dem_{1} → demuuid_{1} → demanswer_{1};;
...
dem_{m} → demuuid_{m} → demanswer_{m} ;;
%%
expr_{1} → answer_{1};;
...
expr_{n} → answer_{n};;
Are demands always added to the previous demands? So at any time instant, all the demands from previous instants are evaluated if valid?
Also where is this context for demands coming from?
Suppose I write
(fact, [0:15]);;
Where does the 0 dimension come from?
Yes, demands are added to previous demands. But, because there are UUIDs, you can also replace and delete demands, as you can for definitions.
The 0 dimension just is.
Could you give a usage example of tlcore? I’ve managed to compile everything, but I cannot seem to get anything out of tlcore.
Do you have some example input you can pass to tlcore for this? I tried out the repository code, but it isn’t reacting to any input.
tlcore now works up to the level of tlcore –reactive, so it is possible now to have an interactive session. The manual is not yet written, so we will put some examples on the blog.
The first release of TransLucid is now out. See the post from today for downloading TransLucid from Sourceforge. Also see the examples available at
Dimension 0 comes from the equations, right? What would happen differently if there were an aether? I’m still looking for the notion of a context in the way TransLucid is running now.
With the simplification of contexts, bestfitting becomes simpler as well, as does the semantics for identifiers in expressions.
An equation q is, conceptually, a triple (x_{q}, K_{q}, E_{q}), where x_{q} is the variable being defined, K_{q} is the set of contexts where the equation is valid, and E_{q} is the defining expression.
Given two equations q and q’, we write q ⊂ q’ if x_{q} = x_{q’} and K_{q} ⊃ K_{q’}.
If we have a set of equations σ, then best(σ) consists of the bestfit equations in σ , i.e.,
best(σ) = {q ∊ σ | ∄ q' ∊ σ. q ⊂ q'}
The restriction of a set of equations σ to an identifier x and a context κ is written
σ|xκ = {q ∊ σ | x = x_{q} and κ ∊ K_{q}}
We can now write the semantics for identifiers in equations.
⟦x⟧σκ =
let {q_{1}, ..., q_{n}} = best(σ|xκ) in
let v_{i} = ⟦E_{qi}⟧σκ in
v_{1} ⊕ ⋯ ⊕ v_{n}
where ⊕ is the combining operator. The simplest combining operator checks that all of its arguments are identical, and returns that value. In the general language, each identifier could have its own combining operator, which could be any commutative, associative operator.
Reply