Pretty-printing
How hard is it to have pretty-printing of the header components? All the operators, delimiters and libraries already loaded? Is is reasoble to ask the same for equations?
How hard is it to have pretty-printing of the header components? All the operators, delimiters and libraries already loaded? Is is reasoble to ask the same for equations?
The simplified bestfitting becomes even simpler in the presence of time and priority. We no longer need deftime nor validtime dimensions. We simply need to use the time dimension. Then definitions might have the form
x | [time:40..50, priority:2] = E
There is nothing special about the time dimension as far as bestfitting is concerned. For the priority dimension, this is different, as it is an ordered dimension. We need to adapt the refinement order ⊂ on equations so that the priority is considered first. We can consider an equation q as a quadruple (x_{q}, P_{q}, K_{q}, E_{q}), where P_{q} is the priority of q. Then
q ⊂ q' if x_{q} = x_{q'} and P_{q} < P_{q'} or K_{q} ⊃ K_{q'}
In previous work on TransLucid, it was never clear whether a context was a finite or an infinite object. Well, it turns out that by making it an infinite object, then the semantics is a lot cleaner, and bestfitting will become simpler as well. This is the way that it works. Let D be the domain of atomic values. Then a context κ is an element of K = D to D, and a set of contexts K is a subset of K. Then the denotational semantics of TransLucid expressions is much more easily expressed. Here it is, ignoring identifiers and undefined values:
⟦c⟧σκ = c
⟦op(E_{1}, ..., E_{n})⟧σκ = op(⟦E_{1}⟧σκ, ..., ⟦E_{n}⟧σκ)
⟦if E_{1} then E_{2} else E_{3}⟧σκ = if ⟦E_{1}⟧σκ then ⟦E_{2}⟧σκ else ⟦E_{3}⟧σκ
⟦#E⟧σκ = κ(⟦E⟧σκ)
⟦E_{11}:E_{12}, ..., E_{n1}:E_{n2}⟧σκ = {⟦E_{11}⟧σκ ⟼ ⟦E_{12}⟧σκ, ..., ⟦E_{n1}⟧σκ ⟼ ⟦E_{n2}⟧σκ}
⟦E_{2} @ E_{1}⟧σκ = ⟦E_{2}⟧σ(κ † ⟦E_{1}⟧σκ)
The documentation automatically generated by Doxygen for the TransLucid code can be found at
http://translucid.sourceforge.net/doc/index.html
When the –reactive option is set for tlcore, then the application becomes reactive, and the set of equations is allowed to vary over time, and the expressions being evaluated can refer to the time dimension. The idea is that at each instant,
When tlcore is reading from the standard input, then the input will be of the form
header
%%
equations
%%
expressions
$$
header
%%
equations
%%
expressions
$$
...
Each instant corresponds to the lines appearing between successive occurrences of $$.
The output is of the same form as the input, with occurrences of $$ to separate the different instants.
When the input is given in the form of option —input=infile, then the entire input, for all instants, is read from infile. When the input is given in the form of option –inputiter=inprefix, then the input for instant n comes from file inprefix_{n}. In other words, the input for each instant is placed in a different file.
Similarly for –output and –outputiter.
If the –uuid option is set, then the universal identifiers for the equations are presented to the programmer, who can then manipulate them explicitly, with lines like the following two:
delete eqnuuid_{1};;
replace eqnuuid_{2} equation;;
For the first line, if #time, the time that this line is added to the equations, has value t, then from t on, eqnuuid_{1} is no longer usable. For the second line, the equation corresponding to eqnuuid_{2} is replaced, from t on, with equation. If the value of #time is changed to t’, which happens to be less than t, then all of the equations available at time t’ continue to be accessible.
Changes to the set of equations are done synchronously. All additions, deletions and replacements for a given instant are done as a single transaction, and must be consistent.
An empty instant stops the tlcore program.
This is neat!
When can I have one? (without bugs…)
tlcore will be part of the TransLucid distribution.
When an equation is added to the TransLucid system, it is automatically given a unique identifier, generated by the Boost.UUID library. When tlcore is passed the –uuid option, then both the equations and the expressions will return results. The results will be of the form
eqnuuid_{1};;
...
eqnuuid_{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_{m} → eqnuuid_{m};;
%%
expr_{1} → answer_{1};;
...
expr_{n} → answer_{n};;
From a practical point of view, it is not clear to me what the difference is between expressions and equations. They could both define and both be evaluated… No?
The “value” of an equation is its UUID.
When the interpreter is evaluating an expression in a given context κ and comes across a variable x to be evaluated, the bestfit definition of x must be chosen. This process consists of examining, for each definition, the context guard and Boolean guard for that definition. The applicable definitions are the ones for which the current context κ is enclosed in the context guard and for which the Boolean guard evaluates to true. The bestfit definition, should it exist, is the one applicable definition whose context guard defines a region completely (and strictly) contained inside the context guard of each of the other applicable definitions.
Bestfitting becomes more complicated when the predefined priority, deftime and validtime dimensions are introduced. Both deftime and validtime are natural numbers, referring to the same time line, while priority is a natural number meaning that the higher the priority, the higher the number. The priority and validtime dimensions are controlled by the programmer, while the deftime dimension is controlled by the interpreter. For example, for the equation
should #time be between 10 and 15, inclusive, then this equation is valid and has priority 2. The deftime for this equation is when it is added to the system.
The validtime dimension is simply used to restrict the context guard. However, the deftime and priority act differently, as they are ordered dimensions. Once all of the applicable definitions are found, then they are further restricted, first using the priority dimension, then the deftime dimension. For both these dimensions, higher numbers are favored.
Now that the Core TransLucid library has been developed, it is time to develop some applications.
The first application is called tlcore. It simply reads, either from a file or from the standard input, a TransLucid header, set of equations and set of expressions. The expressions are then evaluated one by one, and the results are placed on the standard output or in a file.
The interface is as follows:
tlcore --input=infile --output=outfile
along with the standard –verbose and –version options.
If the –input option is not provided, input is read from the standard input.
If the –output option is not provided, output is written to the standard output.
All errors or log messages, including version information, are written to the standard error.
The syntax of the files is simple. It consists of three parts:
header
%%
equations
%%
expressions
where each part follows its standard syntax.
The expressions are to be read, one by one, and then evaluated. The answers are provided as follows:
answer_{1};;
...;;
answer_{n};;
Should the –verbose option be used, then the output will be
expr_{1} → answer_{1};;
...;;
expr_{n} → answer_{n};;
The inContext variable is used to define the default context for parsing expressions.
The outContext variable is used to define the default context for printing expressions.
What is the difference between the Core TransLucid library and tlcore? Why is tlcore an application? Or rather what does it do exactly for the user?
tlcore is an interpreter of the TransLucid language, implemented using the Core TransLucid library. It allows direct use of TransLucid without having to write any C++ code.
Again, from a user point of view, what ts the syntax of the header, equation and expression. Where can we find out? Is there a link?
Official user documentation does not yet exist. When it does, it will be made part of the TransLucid distribution. In the meantime, use the papers on TransLucid as a guide.
Where are inContext and outContext defined? In the command line? In the program? IOW, by user or programmer?
inContext and outContext are variables defined in the set of equations. They should be tuple-valued.
The language for developing Cartesian Programming is called TransLucid.
Its home site, with the source code, is http://translucid.sourceforge.net
jarro2783 09:47 on 2010/09/20 Permalink |
It’s all pretty straight forward. It’s just a matter of determining correct interfaces. Is this for tlcore or for the C++ interface?
cartesianprogramming 10:02 on 2010/09/20 Permalink |
The C++ interface.
jarro2783 22:44 on 2010/09/20 Permalink
Printing is pretty easy, I’ll come up with something.
jarro2783 22:54 on 2010/09/22 Permalink |
I’ve done pretty printing of equations in the translator. I haven’t been able to test it though. Have a look at Translator::beginEquation and Translator::endEquation. They return an object which acts like an iterator but also has a print and id function allowing you to print the equation and retrieve the uuid.