Updates from cartesianprogramming Toggle Comment Threads | Keyboard Shortcuts

  • cartesianprogramming 03:22 on 2011/11/22 Permalink | Reply  

    The new C++ 

    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

  • cartesianprogramming 03:17 on 2011/11/22 Permalink | Reply  

    TransLucid is live and online 

    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

  • cartesianprogramming 09:59 on 2010/09/14 Permalink | Reply  

    Semantics of header entries 

    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.

    • jarro2783 10:07 on 2010/09/14 Permalink | Reply

      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.

  • cartesianprogramming 04:42 on 2010/09/13 Permalink | Reply  

    Formalization of the interpreter 

    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.

    • jarro2783 10:05 on 2010/09/14 Permalink | Reply

      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.

      • cartesianprogramming 10:12 on 2010/09/14 Permalink | Reply

        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).

        • cartesianprogramming 10:14 on 2010/09/14 Permalink

          The initial implementation can be done using the linear-quadratic solution. Just-in-time ideas can be kept for future optimization.

        • jarro2783 00:18 on 2010/09/16 Permalink

          what about including priority in that?

  • cartesianprogramming 11:33 on 2010/08/26 Permalink | Reply  

    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?

    • jarro2783 01:29 on 2010/08/27 Permalink | Reply

      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.

      • cartesianprogramming 04:08 on 2010/08/27 Permalink | Reply

        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.

    • cartesianprogramming 05:01 on 2010/08/27 Permalink | Reply

      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).

    • jarro2783 04:04 on 2010/08/30 Permalink | Reply

      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.

  • cartesianprogramming 11:18 on 2010/08/26 Permalink | Reply  

    Outputtting uuid in tlcore 

    tlcore --uuid

    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 ?

    • jarro2783 11:21 on 2010/08/26 Permalink | Reply

      uuid or uuid … ?
      The rest is easily fixed.

      • cartesianprogramming 11:23 on 2010/08/26 Permalink | Reply

        Problems with angle brackets. Now fixed.

        • jarro2783 11:24 on 2010/08/26 Permalink

          and my reply got broken with the angle brackets too, that doesn’t say what I intended it to.

      • cartesianprogramming 12:01 on 2010/08/26 Permalink | Reply

        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.

  • cartesianprogramming 06:59 on 2010/08/09 Permalink | Reply  

    The “tlcore with demands” and “reactive tlcore” entries have been updated: The ## has been replaced with $$.

  • cartesianprogramming 05:36 on 2010/06/15 Permalink | Reply  

    tlcore with demands 

    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:


    A demand requests that a variable be computed in a specific context. It is written as a pair


    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:

    demmdemanswerm ;;

    If the –uuid option is set, then the UUID of the demands is printed out, as it is for equations:

    demmdemuuidmdemanswerm ;;

    Should the –verbose option also be set, then the results will be of the form

    demmdemuuidmdemanswerm ;;

    • jarro2783 14:00 on 2010/06/20 Permalink | Reply

      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?

      • cartesianprogramming 19:37 on 2010/06/24 Permalink | Reply

        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.

    • yvdriess 13:02 on 2010/06/30 Permalink | Reply

      Could you give a usage example of tlcore? I’ve managed to compile everything, but I cannot seem to get anything out of tlcore.

    • yvdriess 13:43 on 2010/07/07 Permalink | Reply

      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.

    • superspreadsheet 05:47 on 2010/08/24 Permalink | Reply

      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.

  • cartesianprogramming 04:43 on 2010/06/15 Permalink | Reply  

    Bestfitting with time and priority 

    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 (xq, Pq, Kq, Eq), where Pq is the priority of q. Then

    qq' if xq = xq' and Pq < Pq' or KqKq'

  • cartesianprogramming 04:31 on 2010/06/15 Permalink | Reply  

    Bestfitting simplified 

    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 (xq, Kq, Eq), where xq is the variable being defined, Kq is the set of contexts where the equation is valid, and Eq is the defining expression.

    Given two equations q and q’, we write qq’ if xq = xq’ and KqKq’.

    If we have a set of equations σ, then best(σ) consists of the bestfit equations in σ , i.e.,

    best(σ) = {q ∊ σ | ∄ q' ∊ σ. qq'}

    The restriction of a set of equations σ to an identifier x and a context κ is written

    σ|xκ = {q ∊ σ | x = xq and κ ∊ Kq}

    We can now write the semantics for identifiers in equations.

    x⟧σκ =
    let {q1, ..., qn} = best(σ|xκ) in
    let vi = ⟦Eqi⟧σκ in
    v1 ⊕ ⋯ ⊕ vn

    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.

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc