Student Projects

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.

10 thoughts on “Student Projects

  1. If you support something like the constructs of Rascal, KFramework, Metaborg, etc. you do not need this to depend on Scala. You can define the subset of Scala features you need though it.

  2. Perhaps you can expand 4 to include all rewriting / reduction / matching logic systems to the extend you can define subscript using subscript. Another property at a later stage would be Homoiconicity.

    Ideally make sure everything is formally verifiable.

  3. sirinath  I am thinking of removing this 4th project idea. I am not sure any more how useful it will be. There is http://strategoxt.org/Spoofax, a sister project for Rascal. On top of that a lot of products are being developed, among which http://www.informatik.uni-marburg.de/~seba/projects/sugarj/ and https://github.com/fjak. Mimicing Rascal or Spoofax will be quite some work, whereas the added value maybe marginal since SugarScala may offer much of that functionality. I am not sure.

    BTW I expect that the SubScript compiler will move from a Scalac derivative to a SugarScala application, really soon after SugarScala gets an official release.

  4. Add algo skeletons and an alternative to Akka which may be more formally defined. Akka also can be supported. But most of what you support should have a formal Algebra / Calculus behind it. I am not sure how close to formal Akka is for a process calculus. Perhaps you might need a layer on top to make it fit.

  5. Just saw this http://subscript-lang.org/subscript-actors/. But nevertheless having a alternative is also good. Ideally they should be drop in replacements.

    Also have a look at this https://github.com/Primetalk/SynapseGrid

  6. sirinath AKKA has great properties: adressable, loosely coupled actors with FIFO message queues. IMO ACP cannot improve that. But I think ACP/SubScript is very good for programming the internal behaviour of single actors

  7. sirinath I think a lot is possible in this direction, and it could be very useful. But I will have no time for this. So others should do this.

Leave a Reply