The TransLucid interpreter is being written using the new standard C++, called C++11.
For interesting discussions about C++11, I recommend the http://thenewcpp.wordpress.com blog.
For a summary of the current C++11 implementation of the GNU gcc compiler suite, go to http://gcc.gnu.org/projects/cxx0x.html
The TransLucid interpreter is coming alive. It now implements a full functional programming language. It can be used online at http://translucid.web.cse.unsw.edu.au
The Go programming Language:
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?
It’s all pretty straight forward. It’s just a matter of determining correct interfaces. Is this for tlcore or for the C++ interface?
The C++ interface.
Printing is pretty easy, I’ll come up with something.
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.
Since headers are needed for equations to be parsed, and (at least in theory) equations can come from multiple simultaneous sources, there will be a need for multiple simultaneous headers, which should simply be unioned together, no? This means that one should be able to load the same library multiple times and declare the same dimension multiple times, and so on. What is necessary is that everything be consistent, e.g., an operator cannot be defined to have multiple interpretations.
I think this goes with the post 2 down. The header semantics need to be better defined, including the deletion of dimensions, and the parser should be sensitive to time and other context. Currently the header just gets added to and the parser parses by whatever the header says at the time that it was called.
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.
Yes that is what I will do.
I have completed this now, the interface is the same. System dimensions are in system_dimension_symbols, so addDimensionSymbol and removeDimensionSymbol only affects user dimensions.
What are the operators available in tlcore? If we are loading up the integer library, we should provide the operations therein, as in the five operators. Is this done?
I don’t understand the question.
tlcore has no built in operators, they all come through loading the integer library and declaring things in the header. Are you wanting some of this to be automatic?
To which five operators are you referring? There are plenty that we could have, all the arithmetic and comparison operators, we could have bitwise operators too. It’s partly a question of how we can implement these with a minimum of typing too.
I think that there should be a default set of operators. We can always use a flag to turn these on and off. For integers, at the minimum, +, -, *, /, %. For comparison, we have a problem with the angle brackets, we could use ge, gt, le, lt.
Parsing negative numbers is also problematic if we are not using the intmp interface. I propose that we do the same as in Haskell, and use the tilde (~) to indicate a negative number. That way there will be no confusion between ~3 (negative-three) and -3 (the negation operator applied to three).
I forgot about the angle brackets. Although only < is a problem. Using tilde is a good idea. I think having a default set of operators is a good idea too. We should come up with a reasonable set of associativities and precedences and allow them to be redefined.
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.
Yes, the trick is that SorceForge tl doc pages is not updated automatically with the your updates. Local copies do look better. Can this be done automatically?
I’m not sure how to do this automatically. I can at least make a script that uploads the latest documentation, and then we would need to rebuild it every now and then as we add to the code.
jarro2783 and 
Reply