Introduction

Students computer science or software engineering can take up projects and participate in the SubScript project. This is a great opportunity to learn Scala and also programming with Process Algebra. Depending on the subject you are even likely to interact with some of the world’s top technologists: the Scala Team at EPFL and JetBrains, the makers of IntelliJ. This makes continued participation attractive.

Below four directions for student projects. Each may would be good for 150 up to 750 working hours, whatever is desired. Three of these directions are related to SubScript; the first direction is more general, though it may well be used for SubScript.

André van Delft and Anatoliy Kmetyuk are available as mentors. You can contact them using gmail (andre.vandelft and anatoliykmetyuk @ …).
 

Direction 1: Broaden the Scala language

Languages such as Scala should embrace extensions and dialects, so that they enable maximum ease of writing code and reading code. With such a mindset Scala could become a common base language for a much broader audience than the current Scala developer community. That would be like how the Java Virtual Machine and JavaScript have become popular common execution platforms for totally different languages.

We have some specific ideas to broaden the language. This enable clearer shorter programs with less boilerplate code and text repetitions. Code should not contain symbols that look and feel unnecessary. Also we want to reduce the use of parentheses, braces and brackets: these make code look technical while there are often alternatives appear more elegant. Using “import” statements, developers can select such Scala dialects; and at certain language boundaries syntax and semantics may change even more intensely. The Scala compiler should allow this through plugins, that also work in the parsing phase. This enables heterogenous DSLs as extensions to Scala.

We want to broaden the language by opening it up for syntactic sugar which can be plugged in relatively easily to the compiler. We propose some conventions for how to designate specific areas in code for such special syntaxes. This broadening requires a mindset change. We are not limited to internal DSLs and external DSLs. The former suffer from syntactic constraints and the latter do not benefit from what is already available.

We don’t fear Babylonic confusion, but embrace dialects; these allow a common base language be used by a larger variety of communities.

Specific ideas

Infix notation

The Scala style guide presents “a special syntax for invoking methods of arity-1”. This infix notation is meant for “purely-functional methods such as mkString, or methods which take functions as parameters, such as foreach”:

names mkString ","

We propose that by default infix notation becomes unavailable for identifiers that start with a letter (it should remain for identifiers such as `+` etc). An “import language” statement may make it available, e.g., for method invocation, but other usages are also thinkable: spacing could be an operator like “+”, but without any characters. This would enable for specifying sequences in a BNF-like style.

Identifiers with dots

Restriction infix notation would by default disable often used range expressions such as `1 to 10`. New classes of identifiers that start with two dots could offer alternatives, e.g.,

 1 ..<=.. 10
10 ..>.. 1

Smalltalk style method calls

Like with the C style if-statements, the parentheses that enclose parameter lists clutter the code a bit. Named parameters clarify the role of each parameter in method calls, but at the cost of even more cluttering. The Smalltalk language has a more restful style for calls (AKA message sends), as in

'hello world' indexOf: $o startingAt: 6

A Scala dialect may offer something similar, with a dot before the first tag, and a comma before each new tagged parameter:

"hello world".indexOf: 'o', startingAt: 6

The compiler would treat this as an old style call with the tags concatenated using camelCasing:

"hello world".indexOfStartingAt('o', 6)

Multi-sections

Scala code often contains groups of similar definitions or declarations that start with the same word, such as `import`, `def`, `val` and `var`. It is possible to get rid of such repetitions using an ellipsis (..) and smart indentation. E.g.,

import ..
  scala.collection.mutable.ListBuffer
  util.{ SourceFile, SourcePosition }
  Tokens._
  Scanners._

Ellipsis macros

An ellipsis could also initiate a section with a local text macro and an instantiation table.

E.g.,

case Sequence(Nil ) => Success()
case Sequence(Sequence(a) :: x) => Sequence(a ++ x)
case Sequence(Call(t) :: x) => Sequence(t() :: x)
case Sequence(Success() :: x) => Sequence(x)

could be written with less repeated text as

..
  case Sequence(`Params`) => `Result` 

  Params           | Result
  -----------------+--------------
  Nil              | Success()
  Sequence(a) :: x | Sequence(a ++ x)
  Call(t)     :: x | Sequence(t() :: x)
  Success()   :: x | Sequence(x)

A language aware editor could represent the table with full borders. It could even extract such macros and tables from existing code, or perform the opposite conversion.

Heterogenous DSLs

A heterogenous DSL supports mixing sections of Scala code and sections with special DSL code. These sections should have clear boundaries. We propose these standard rules:

• In DSL code, parentheses and braces enclose Scala blocks and expressions
• In Scala code, brackets enclose DSL code (or type parameters, depending on the preceding symbol and spacing).
• A word such as `parser` or `script` may also initiate a DSL construct, and this may be combined with ellipsis macros.

An `import language` statement could activate a compiler plugin that recognizes such section changes and activates the appropriate kind of parsing.

Direction 2: Enhance current implementation of SubScript-Scala

There is still plenty to do on the current implementation. You may do:

• make a SubScript plugin for the IntelliJ IDE
• improve the SubScript debugger
• improve the koans
• make a learning environment like 4Clojure, using ScalaJS or even SubScriptJS if that is available in time

Direction 3: SubScript on top of JavaScript

As Scala compiles to JavaScript, next to the JVM, so SubScript may do that as well. This could open up opportunities to improve web development: for generated JS in the browser, but also for NodeJS applications without callback hell.

The project would involve some of the following tasks:

• compile the SubScript VM to JavaScript and deploy it; adjust a clone of the preprocessor or compiler to work well with JS instead of Java
• create bridge libraries for working with JS GUI controls and NodeJS
• develop examples, both for client-side and server-side/NodeJS applications
• develop alternatives for explicit multithreading, since standard JavaScript does not
• develop a site for easy experimentation with SubScriptJS, like ScalaJS-Fiddle.

Direction 4: Discrete Event Simulation

A predecessor of SubScript was successfully applied to discrete event simulation, e.g., see the paper in these conference proceedings starting at page 229. Something similar, and even better, is possible for SubScript. As a use case you could develop a simulator for railway systems; here is a reference project (shorter paper); it is based on the process theory CSP, that preceded ACP.