tl;dr

Building a multi-dimensional spatially configured feed forward nodal compute network.

  •  

    June 2009
    M T W T F S S
        Jul »
    1234567
    891011121314
    15161718192021
    22232425262728
    2930  
  • Archives

  • Subscribe

  • Other Blogs

  • RSS Latest Posts on Vorlaths Blog

    • Assembly: Interlaced Zig Zag x264 (Updated Dec 8,2009)
      Via reddit, we find this article about implementing zig zag in assembly. See zig zag figure in section 1.6.6 of this article for more info. The author implemented the interlaced version of zigzag (16bit word elements) as it was not already available. This version is for more recent processors as can be seen by this quote.Furthermore, as should be clear by th […]
    • Intel 48 Core Processor (Update: Larrabee canceled)
      Link to article.I like what they did with the routing. I wonder how it works at the low level. They have 24 dual core IA32 processing units arranged in tiles. There is a 2D grid routing system. From what I gather, there is a buffer for incoming data (and outgoing?) and each L2 cache is independent. There is a central (up to) 64GB of RAM.I like the buffering […]
    • Climategate
      If you only watch CNN, MSNBC, CBS, ABC, BBC or CBC for your news, you probably didn't hear about one of the biggest scientific, economic and global scandals ever. I'm a big fan of conspiracy theories for their entertainment values, but this has real consequences. Still, it does have a lot of comedic value in some parts. Specifically, the coding par […]
    • Generic List
      I don't know if this is possible, but it'd be cool if it was. In Project V, I use a generic list with the objective that no operation takes more than O(log n). However, it has one drawback which causes it to be just short of that objective. Before going into that, a description of the list is required.I will simplify the scenario since Project V ha […]
  • RSS Latest LtU Posts

    • An Innocent Model of Linear Logic
    • Back to the Future: Lisp as a Base for a Statistical Computing System
      Back to the Future: Lisp as a Base for a Statistical Computing System by Ross Ihaka and Duncan Temple Lang, and the accompanying slides. This paper was previously discussed on comp.lang.lisp, but apparently not covered on LtU before. The application of cutting-edge statistical methodology is limited by the capabilities of the systems in which it is implement […]
    • Why API Design Matters
      Michi Henning, Why API Design Matters, Communications of the ACM, May 2009. After more than 25 years as a software engineer, I still find myself underestimating the time it takes to complete a particular programming task. Sometimes, the resulting schedule slip is caused by my own shortcomings: as I dig into a problem, I simply discover it is a lot more diffi […]
    • ActorScript(TM): Industrial strength integration of local and nonlocal concurrency for Client-cloud Computing
      ActorScript(TM): Industrial strength integration of local and nonlocal concurrency for Client-cloud Computing by Carl Hewitt, 2009. ActorScript is based on a mathematical model of computation that treats “Actors” as the universal primitives of concurrent digital computation [Hewitt, Bishop, and Steiger 1973; Hewitt 1977]. Actors been used both as a framework […]
  • RSS Latest ACM Queue Posts

    • A Conversation with Arthur Whitney
      Can code ever be too terse? The designer of the K and Q languages discusses this question and many more with Queue editorial board member Bryan Cantrill.
    • Purpose-Built Languages
      While often breaking the rules of traditional language design, the growing ecosystem of purpose-built "little" langages is an essential part of systems development.
    • Realtime Garbage Collection
      Traditional computer science deals with the computation of correct results. Realtime systems interact with the physical world, so they have a second correctness criterion: they have to compute the correct result within a bounded amount of time. Simply building functionally correct software is hard enough. When timing is added to the requirements, the cost an […]
    • How Not to Write Fortran in Any Language
      There are characteristics of good coding that transcend all programming languages. Programmers have debated the merits of different programming languages since the dawn of programming. Every coder has a favorite general-purpose programming language, and many have an unfavorite language, too. If the coder is old enough, often that unfavorite language is Fortr […]

Archive for June 12th, 2009

Language Concept

Posted by dublindan on June 12, 2009

I was digging through my external drive yesterday and I discovered some notes on a programming language concept. I will briefly talk about it here.

There are a few things I really like in programming languages:

  1. Parametric recursive data types
  2. Automatically checked type constraints
  3. Pattern matching and guards
  4. Automatic event management
  5. A concise and simple syntax (point free, if possible)
  6. Restartable/Resumable exceptions
  7. Type inference

This language concept features, at a minimum, numbers 4, 5 and 7.

In this language, just like in Java, everything is an object, of sorts. Also, just like in Java, you define each “class” inside its own file and the file name must match the class name. In the spirit of being short and concise, however, the language eliminates the redundancy and boilerplate: you do not need to define the class or give it a name, we already know its name is the same as the file name. We also already know that everything inside that file belongs in that class.

This is only a minor, cosmetic change, though. The more interesting features are the automatic event and dependency management.

Lets start with some sample code:

[Filename: ButtonClick.lang]

public
    reset click -> false
    click_count <- local_click_count
private
    local local_click_count = 0
    react click: local_click_count += 1

in some other file:

import io
import .ButtonClick
private
    local clicker = ButtonClick
    display: io.print “Button clicked ”
                      clicker.click_count
                      “ times.\n”
    main: times [clicker.click = true, yield] 3

What this does is creates a number of cells which contain data:

  • click, a cell which will reset to false every time it gets set
     >>> clicker.click = true
     >>> io.print clicker.click
     --- false
  • click_count, a cell which is bound to the value of local_click_count
  • local_click_count, a local variable. This is a standard integer variable, “bound” to click_count
  • react click, a function which reacts to click being modified

When click is set to true, the react click code is run. This will change the value of the local state variable. In turn, this causes the public cell to change.
The other file creates an instance of this class as the object clicker and defines two functions: display, which displays the current click count and main which is run on program start. Because of the automatic event management system, any time clicker.click_count changes, the display function gets rerun. As I stated above, setting click to true, will increment click_count, so if you set clicker.click to true, the value for click_count is incremented, click is reset to false and display is executed.

The main function simply sets clicker.click to true three times, waiting for events to be handled in between.

The concept is simple enough – modules/objects may contain mutable local state, but communications between modules can only be done through automatically managed events. Any code which relies on these events (by referencing a cell or because its a reactor) will be automatically evaluated any time the event occurs (that is, any time the dependents change).

The language could be visually enhanced too:

Visual representation of code

Visual representation of code

At this point, I’d like to point out that this is not the language I have envisioned and is not what this blog aims to be about, but it is a step in that direction. So bear with me, I will slowly transition into dataflow and hopefully design a useful, intuitive and powerful dataflow language in the process. Or at the very least, learn something useful.

Posted in Software | Leave a Comment »