I’ve recently had the opportunity to work with ANTLR to create a DSL, and I’ve liked the overall experience so much that I’ve started using it for parsing just about anything, especially for my metaprogramming needs, and decided to write a series of articles to explain how it can be used to create DSLs.

In the first article we’ll discuss the motivations behind creating a DSL, what our options are regarding the implementation, and how ANTLR can be used to declare a grammar and parse some inputs with it.

In later articles we’ll create an actual DSL, execute and evaluate inputs, and even write a web-based code editor with full support for parsing and verifying code written in our language.

For this we’ll be using Microsoft’s Monaco Editor so it’ll also double as a potential VS Code extension because VS Code is based on Monaco as well.

But first things first, let’s see why we might need a DSL in the first place.

ygunayer/antlr4-examples

An example DSL implementation using Antlr4 and Java

ANTLR

0

0

In our previous example we’ve explored the basics of Erlang, and built simple, but concurrent and stateful apps for demonstration. With the basics in place, it’s time to move on to the actual stuff that makes Erlang such an excellent language for building fault-tolerant apps for distributed networks. In this article, we’ll go over topics like distributed Erlang (aka node-to-node communication), fault tolerance via Erlang/OTP, and code distribution and releases via rebar3, which will allow us to write production-ready apps.

As mentioned in my introductory article to the actor model, the programming language Erlang implements the actor model as its core functionality, so anyone who’s got exposed to Akka is bound to have heard about it, and quite possibly they’ve become interested with it.

While I certainly was interested, that interest has only recently grown into the “oh boy I’ve got to try this right now” levels. Now that I’m this hyped, and we’re waiting for Scala 3 anyway, it’s the perfect time to play around with Erlang.

So in this article, we’ll go over a quick introduction to Erlang, and in subsequent articles we’ll rewrite our bastra game from the previous article in Erlang, with exactly the same functionality.

If you’re interested in learning more (much, much more) about Erlang, just check out the incredible book Learn You Some Erlang for Great Good! either in printed or online form.

In previous articles we’ve talked about how we can implement a simple game using actors, and how we can use Akka’s remoting functions to build actor networks, so it’s time we put the pieces together and create a multiplayer game.

The game we’ll implement is called pişti or bastra, a card game that can be played with 2 to 4 people, and is pretty popular among people of all ages due to its simplicity.

At the start, each player is dealt 4 cards, and 4 other cards are placed in the middle of the table (also called the board), with one of them open. To ensure fairness, any jacks that are dealt on the board stack is randomly replaced with another from the deck so the players can get them later. On each turn, a player plays a card from their hand and places it on the board. If the card that is played is a jack, or if it matches the one on top of the board stack, the player collects the board (also called fishing) and earns points. If not, the card is left on the stack and the turn passes over to the next player. If the player runs out of cards they’re dealt 4 more, and the game lasts until all cards are played out. Once they are, whoever has the highest score wins the game.