Last week I implemented sub-type algorithms in Rust and put the source code on GitHub. In this week, I rewrite the project with Scala, because I am going to work in Scala. This post is not a step-by-step explanation of the project, but more like a topic-based notes during the implementation.
\nA newly created Scala project has code like this.
\nobject Main extends App {\n println(\"Hello, world!\")\n}I have several questions in my first glance.
\nMain? Is it an object, or a type (class)?Main extend App?println can be placed in Main? Does Main works like a function?Here are my answers.
\nMain is an object. It is categorized as a value. It is not a type. You can try this.
def test(main: Main) = 0 // not found: type MainMain has a hidden and inaccessible type. Let’s call it T. So it actually means that T extends App. In this way, Main has everything in App.Another interesting yet familiar thing is companion object. It means you can create a singleton object called the same name of a class. I heard that static methods in Scala are mostly done in this way.
\nI will make an REPL. So I need something like
\nwhile (true) {\n line = readLine()\n reply(line)\n}Soon I found Scala is a expression-based language, so while expressions are typed. And they are typed to Unit since the halt problem. That’s okay.
Then, how about break and continue? To my surprise, they are not included in the language. I read the Scala Book but I didn’t notice this point. I found scala.util.control.Breaks, but it seems be implemented with exceptions.
Scala Standard Library 2.13.3 - scala.util.control.Breaks
\nSo I put the while expression in a method and use return instead. Here is the skeleton of the REPL.
\nobject Main extends App {\n val context = new Context()\n\n def repl: Unit = while (true) {\n val command = readLine(\"> \")\n command match {\n case \"exit\" => return\n case command => println(command)\n }\n }\n\n println(\"Welcome to TAPL Scala!\")\n repl\n}OptionI’m dealing with Option in Scala. There are few ways I know so far.
x match { Some(y) => z None => a }.Iterable. Because Option is actually a container of a single value, so what people can do with Iterable also works here.getOrElse, isEmpty, isDefined.When type inference fails, we need to handle errors. In my Rust implementation, errors are contained by Result<TermType, String>. Rust offers some syntactic sugars dealing with them, for example, if the return type of surrounding function is also the same Result type, appending an ? to the expression will return the error part if it is an Err, just like the lift in Monad.
In Scala, we can use exception, just like how we do it in Java. Therefore, we need custom errors. I found a solution on StackOverflow: Custom Exception in scala.
\nBecause I was learning the book Types and Programming Languages. I wanted to define <: as the “is subtype of” operator. Soon I found this is impossible because <: is reserved as the sub-type operator. Therefore, I chose <:: as the operator.
Operator overloading is easy in Scala. The syntax does not differ from defining functions.
\ntrait Type {\n override def toString: String\n def <::(that: Type): Boolean\n def ==(other: Type): Boolean\n}But, I found another problem. When I test the expression if true then {} else { a: 0 }, the result type is Record { a: Int }. What the heck? I thought I messed up some order, for example, reversing the order of if branches or something like that. But the logs indicate that a <:: b is actually equivalent to b.<::(a). Hmm, interesting.
I started searching in Scala documentation and Scala Book, but they told me nothing. Soon I found the answer in Scala specifications. I like reading specifications, because they are mostly well-structured so I can locate what I want immediately. I remembered I read ECMA-262 for thousands times because it is the only document telling me what’s really happening in the execution context.
\nOkay, let’s back to the topic. Here is what I found from this page: Expressions.
\n\n\nThe associativity of an operator is determined by the operator's last character. Operators ending in a colon `:' are right-associative. All other operators are left-associative.
\n
Because I don’t want to change my code too much, I just rename the operator :<. It looks like an unhappy face. Just like my mood. (I’m just joking.) I have to manually rename the operator because Metals says it will break my code. Even if I had replace all occurrences of infix notations with member function notations.
Fastparse is handy. I can write a parser in less than 20 lines of code. But it is based on backtracking strategies, which means sometimes I find the problem at the runtime.
\nHere is my grammar without any modification.
\nterm -> apply\n | project\n | true\n | false\n | int\n | if\n | abstract\n | variable\n | record\n | parenthesized\napply -> term \"(\" term \")\"\nproject -> term \".\" ident\ntrue -> \"true\"\nfalse -> \"false\"\nint -> [0-9]+\nif -> \"if\" term \"then\" term \"else\" term\nabstract -> \"(\" ident \":\" type \")\" \"=>\" term\nvariable -> ident\nrecord -> \"{\" entry (\",\" entry)* \"}\" where entry -> ident \":\" term\nparenthesized -> \"(\" term \")\"There are some obvious left-recursive rules: apply and project, so we can make them as a postfix rule. Replace the first 3 rules with these 4 rules.
term -> term' (apply-tail | project-tail)*\nterm' -> true\n | false\n | int\n | if\n | abstract\n | variable\n | record\n | parenthesized\napply-tail -> \"(\" term \")\"\nproject-tail -> \".\" identThen we will spot some “dangling-else” problems (not the else in the if rule because else clause is required). They are if and abstract. For example, (x: Int) => x.y can be interpreted into either ((x: Int) => x).y or (x: Int) => (x.y. The solution is to give apply-tail and project-tail higher binding weights than if and abstract have.
term -> simple (apply-tail | project-tail)* | complex\nsimple -> true | false | int | variable | record | parenthesized\ncomplex -> if | abstractIn the new rules above, term is either a simple term (terms without “dangling-else” problems) with any number of tails, or a complex term with no tails. By far the parser is almost done. However, I stepped into other two rabbit holes.
~)at appropriate position, or the parser might fail even if your grammar is correct! To cut is to tell the parser never look back.repX rather than rep. For example, I spent a whole hour on debugging ident = CharIn(\"a-zA-Z\").rep(1)!Finally, I had finish the project and uploaded to GitHub. You can check it out here.
\nBesides, I also want to address some off-topic discoveries about language servers. I’m writing Scala with Visual Studio Code. I felt that the Scala language server is very stable and ergonomic. It could expand complicated macro in seconds. It made the development smoother than I had expected.
\nBefore I write Scala in Visual Studio Code, I often use Rust and TypeScript.
\nThe TypeScript language server works pretty well. But there are still bunch of times when it stuck because there are too many type assertions and sub-types, especially when I was writing a large tree visitor with Babel. Rust language server sometimes are lazy to check ownership so everything seems fine in the editor but you get bunch of errors when compiling. There are also times the language server failed to expanded macro from newly installed crates.
\nAnyway, I’m not complaining about the language servers of TypeScript and Rust. They are also very great.
","frontmatter":{"title":"A Tour of Implementing TAPL in Scala","date":"July 01, 2021","tags":["scala"],"language":"en"}},"site":{"siteMetadata":{"title":"Luyu Cheng"}}},"pageContext":{"id":"392a13f5-2c9b-5eb0-8b7f-77e4694fce47"}},"staticQueryHashes":["3649515864","63159454","684267432"]}