schedule Dec 14th 10:45 AM - 11:30 AM place Crystal 2 people 3 Interested

Forth is a classic imperative stack-based programming language that fills a very specific niche. Erlang is a concurrent, functional, fault-tolerant programming language that occupies another, albeit wider, niche. There is very little in common between the two except for a shared respect for Alan Turing. This session is a case study that narrates the story of building a bridge between the two languages. The bridge allows for Forth nodes to run in a Erlang controlled world, with the ability to talk to Erlang nodes, send messages, invoke processes and so on.

In particular we'll discuss the various threading techniques used in Forth, listed below. We'll discuss how the choice of threading model impacts the design of the Erlang-Forth bridge.

Indirect Threaded Code (ITC)

A classical Forth threading technique. All the other threading schemes are considered "improvements" on this. Consider the following Forth expression:

  : SQUARE DUP * ;

In a typical ITC Forth this would appear in memory as shown in the image below:

Figure 1

Direct Threaded Code (DTC)

This model is different from ITC in one respect: the Code Field contains actual machine code, rather than the address of some machine code.

Subroutine Threaded Code (STC)

This model relies on the following fact: a high-level Forth definition is nothing but a list of subroutines to be executed.

Token Threaded Code (TTC)

This model optimizes for size, at the cost of speed. A token-threaded Forth keeps a table of addresses of all Forth words. The token value is then used to index into this table, to find the Forth word corresponding to a given token.

2 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session

  1. What is/why do this project
  2. A brief introduction to Forth & Erlang
  3. Implementing a Forth
  4. Erlang - other language interop
  5. Example Erlang-Java interop
  6. What is different about Forth?
  7. Forth Erlang interop
  8. Lessons learned
  9. Questions

Learning Outcome

A better understanding of how Erlang-$Language interop works (aka how to run a $Language node with Erlang). How to leverage Erlang's fault tolerant, distribution, and other capabilities while relegating specific work to other languages.

Target Audience

Developers who (like to) use more than one programming language, programming language enthusiasts


A basic knowledge of Erlang and/or Forth would help, but is not mandatory.

schedule Submitted 6 months ago

Comments Subscribe to Comments

comment Comment on this Submission

  • Liked Michael Ho

    Michael Ho - Making the Switch: How We Transitioned from Java to Haskell

    Michael Ho
    Michael Ho
    Sr. Software Engineer
    schedule 5 months ago
    Sold Out!
    45 Mins
    Case Study

    In this case study presentation, SumAll's CTO, Todd Sundsted, and Senior Software Engineer, Michael Ho, will discuss the move from Java to Haskell along two parallel paths. First, the business/political story — how SumAll convinced the decision makers, fought the nay-sayers, and generally managed the people impacted by the transition. Second, the technical story — how they actually replaced their Java code with Haskell code. Along the way, they will address their hopes and expectations from transitioning from Java to Haskell, and will conclude with the results they've gained and seen to date.

  • Liked Debasish Ghosh

    Debasish Ghosh - Managing Effects in Domain Models - The Algebraic Way

    45 Mins

    When we talk about domain models, we talk about entities that interact with each other to accomplish specific domain functionalities. We can model these behaviors using pure functions. Pure functions compose to build larger behaviors out of smaller ones. But unfortunately the real world is not so pure. We need to manage exceptions that may occur as part of the interactions, we may need to write stuff to the underlying repository (that may again fail), we may need to log audit trails and there can be many other instances where the domain behavior does not guarantee any purity whatsoever. The substitution model of functional programming fails under these conditions, which we call side-effects.

    In this session we talk about how to manage such impure scenarios using the power of algebraic effects. We will see how we can achieve function composition even in the presence of effects and keep our model pure and referentially transparent. We will use Scala as the implementation language.

    In discussing effects we will look at some patterns that will ensure a clean separation between the algebra of our interface and the implementation. This has the advantage that we can compose algebras incrementally to build richer functionalities without committing to specific implementations. This is the tagless final approach that offers modularity and extensibility in designing pure and effectful domain models.

  • Liked Tony Morris

    Tony Morris - Let's Lens

    Tony Morris
    Tony Morris
    Sr. Software Engineer
    Queensland FP Lab, Data61
    schedule 4 months ago
    Sold Out!
    480 Mins

    Let's Lens presents a series of exercises, in a similar format to the Data61 functional programming course material. The subject of the exercises is around the concept of lenses, initially proposed by Foster et al., to solve the view-update problem of relational databases.

    The theories around lenses have been advanced significantly in recent years, resulting in a library, implemented in Haskell, called lens.

    This workshop will take you through the basic definition of the lens data structure and its related structures such as traversals and prisms. Following this we implement some of the low-level lens library, then go on to discuss and solve a practical problem that uses all of these structures.

  • Liked Ravi Mohan

    Ravi Mohan - Experience Report: Building Shin - A Typed Functional Compiler For Computational Linear Algebra Problems.

    Ravi Mohan
    Ravi Mohan
    schedule 6 months ago
    Sold Out!
    45 Mins

    Abstract: I wrote a distributed (mostly) Functional Compiler in Scheme, OCaml and Elixir that incorporates knowledge of Computational Linear Algebra and domain specific knowledge to generate highly optimized linear algebra code from specification of problems. This talk is about lessons learned in the process.

    The problem:
    In every domain that uses computational linear algebra (which is all of engineering and science), we encounter the 'how to optimize a linear algebra expression into an optimized sequence of BLAS (or LAPACK or $linear_algera library) kernel calls' problem.

    Example: (if the math equations make you want to tear your hair out and go jump off a cliff, don't worry, it is just an example, you don't have to grok it. Just skim the equations The basic problem being addressed here is that solving such equations with code takes up a lot of effort and time from experts in computational linear algebra)

    Here is a linear algebra expression from a genetics problem , specifically GWAS -Genome Wide Association Studies, looking for significant associations for millions of genetic markers- where the essence of the problem [1] comes down to generating the most efficient algorithm possible that solves these equations

    This in turn involves solving a 2 dimensional sequence of Generalized Least Squared Problems of the form

    The algorithms to solve these can be directly coded up in Matlab or Julia. But there are problems with this approach, with this specific problem.

    1. For different input sizes, different algorithms give the most optimal performance. Which algorithm do you code up?

    2. Even for a given input size, there are multiple algorithms that compute the same result, but have differing computational characteristics depending on the hardware etc. How do you generate the optimal algorithm for your hardware ?

    3. Most importantly the structure of *this* specific problem allows optimizations that are specific to the problem which are not built into generic linear algebra routines. (Obviously, one can't expect MATLAB to incorporate problem specific information for every scientific/engineering problem ever). The GLS problems are connected to others, thus saving intermediate results can save hours of computation vs calculating every GLS problem from scratch

    In practice, one needs to be an expert in Computational Linear Algebra to come up with the optimized algorithm for a domain specific problem, and then write (say Fortran) code to use BLAS, LAPACK etc optimally to actualize this algorithm, often with much iteration, often consuming 100s of hours.

    The Solution:

    Incorporating this 'expert knowledge' into a compiler speeds up the time taken to arrive at the best solution (often by a factor of 100 or 1000), and allows Computational Linear Algebra experts to do more interesting things, like focus on their research.

    For this particular problem, the above equations, and additional knowledge of the problem domain are the input into an expression compiler. The output is highly efficient and 'proved correct' code

    In compiler terms, incorporating domain knowldege into the compilation process results in being able to apply optimizations to the generated Syntax Trees/Graphs, resulting in optimal algorithms. (note: the output of the compiler is a program in another language- say Matlab).

    In essence, "Domain Specific Compilers" consume knowledge about the structure of a problem and generate optimized code that solves that problem.

    Shin is one such compiler. It consumes a problem description and outputs highly efficient Julia code that solves the problem.

    This talk focuses on the engineering challenges I faced in building this compiler, with a special focus on the approaches that failed [5]


    "Shin" is the Hebrew letter, not the English word meaning 'front of the leg between knee and ankle' ;-).

    Every company uses names from a common theme to name their servers and components - Athena, Zeus, Hercules , or Thor, Loki, Odin, or Jedi, Sith, Skywalker etc. We use Hebrew words, so we have Ruach, Melekh, Malkuth etc..