{"id":396,"date":"2013-09-08T16:18:23","date_gmt":"2013-09-08T15:18:23","guid":{"rendered":"http:\/\/bryants.eu\/blog\/?p=396"},"modified":"2018-02-26T02:45:06","modified_gmt":"2018-02-26T02:45:06","slug":"plinth-isnt-dead","status":"publish","type":"post","link":"https:\/\/bryants.eu\/blog\/2013\/09\/plinth-isnt-dead\/","title":{"rendered":"Plinth Isn’t Dead!"},"content":{"rendered":"

Update 2018-02-26: <\/strong>This was written several years ago, and Plinth development is essentially dead now. (In retrospect,\u00a0although it was true at the time, this was a bad title and it’s been annoying me ever since.)<\/p>\n

\n

I thought I’d write a status update, since it’s been almost four months since I last posted anything here.<\/p>\n

Firstly, Plinth isn’t dead! I have been working on it, albeit slightly more slowly than I’d have liked, for the last four months. At first, that was because Generics took me a while to get right, as it required major structural changes throughout the compiler. More recently, I’ve just been away on a couple of holidays.\u00a0For the last few days, though, development has sped up significantly.<\/p>\n

Now, since this is a status update, here’s a list of all of the major things I’ve added since my last post:<\/p>\n

Generics\u00a0[commit<\/a>]<\/h3>\n

This took much longer than it should have – partly because it changed so much of the compiler’s data structure, but also because code generation for it was much more difficult than I expected (see last post<\/a>).<\/p>\n

A Test Framework [commits: 1<\/a> 2<\/a> 3<\/a> 4<\/a>]<\/h3>\n

There is now a suite of tests<\/a> that covers everything up to name resolution. I still need to write tests for: cycle checking, type checking, control flow checking, and exception checking.<\/p>\n

If you want to run all of the tests, just run `ant run-tests<\/code>`\u00a0from the project root directory.<\/p>\n

A new array-initialisation syntax [commit<\/a>]<\/h3>\n

Before this change, it was impossible to create an array of anything that didn’t have a default value, unless you knew its size in advance. Here’s an example:<\/p>\n

[]string foo = new [n]string;<\/pre>\n
^ This is impossible – you can’t create an array of not-null strings unless you know all of their values beforehand. Here’s what you could do before:<\/p>\n
[]string foo = new []string {\"foo\", \"bar\"}; \/\/ only has two elements, not n\r\n[]?string bar = new [n]?string;             \/\/ all elements are nullable<\/pre>\n
But now, with this new syntax, you can create them much more easily:<\/p>\n
[]string foo = new [n]string(\"hello\"); \/\/ initialises all of the strings to \"hello\"<\/pre>\n
Or, if you define a function somewhere first:<\/p>\n
string makeString(uint index)\r\n{\r\n  return \"string number \" + index;\r\n}\r\n[]string foo = new [n]string(makeString);<\/pre>\n
This will become much easier to use once closures are added, which will hopefully be soon.<\/p>\n
Wildcard types [commits: 1<\/a> 2<\/a>]<\/h3>\n
Wildcards are useful if you want to store an object but don’t care about its generic type arguments. For example, a List<?> can only store one type inside it, but we don’t care what that type is. We can’t store new elements in it, but we can retrieve them as objects.
\nAdding wildcards required a lot of changes to the way run-time type information works, mainly because of cases like this one:<\/p>\n
ArrayList<?> list = new ArrayList<Bar>();\r\nList<? extends Foo> list2 = cast<List<? extends Foo>> list;<\/pre>\n
To do this sort of check, we need to go through all of the super-types of the value being tested (list<\/code>) for the target type (List<\/code>), and then make sure the constraints on the wildcard type argument encompass the actual type argument we get from the object’s run-time type information. This gets especially complicated when you cast to a type like List<? extends Foo super Bar><\/code>, or when you have multiple type arguments, so the runtime’s code for checking this<\/a> is a bit long (although that’s partly because it’s written in LLVM bitcode).<\/p>\n
A copyright notice [commit<\/a>]<\/h3>\n
This should have been added a while ago, but the code is now officially under the three-clause BSD license, so you can use it for almost anything you want.<\/p>\n
Array bounds checking [commit<\/a>]<\/h3>\n
Now, if you index past the end of an array, you won’t get a segmentation fault any more – an IndexError will be thrown instead. Also, IndexError has been added to the standard library.<\/p>\n
Various standard-library improvements [commits: 1<\/a> 2<\/a> 3<\/a> 4<\/a> 5<\/a> 6<\/a>]<\/h3>\n
Some new methods have been added to string, such as trim() which trims all unicode whitespace characters.
\nstring now has a read-only property called “length” instead of a method, which will be the standard way of exposing the length of something in the standard library (no size() methods on Lists!).
\nAlso, the stdin::readLine() method can now throw EOFException.<\/p>\n
ArrayList<T> and LinkedList<T> implementations [commits: 1<\/a> 2<\/a> 3<\/a>]<\/h3>\n
These both implement a new List<T> interface, which extends Iterable<T>.
\nArrayList<T> is actually implemented as a ring buffer in an array. I’m not sure why this isn’t more standard in ArrayList implementations, but it makes insertions to and deletions from the start of the list O(1) with hardly any overhead.<\/p>\n
For-each loops [commit<\/a>]<\/h3>\n
These loops are extremely flexible: they don’t just iterate through arrays and Iterables, they also work on integers (signed and unsigned) and Iterators. This means you can do things like this:<\/p>\n
for uint x in 5\r\n{\r\n  stdout::print(\" \" + x); \/\/ prints: 0 1 2 3 4\r\n}\r\nfor short y in value\r\n{\r\n  stdout::print(\" \" + y);\r\n  \/\/ if value\u00a0== -5, prints: 0 -1 -2 -3 -4\r\n  \/\/ if value\u00a0== 0, prints nothing\r\n  \/\/ if value\u00a0== 3, prints: 0 1 2\r\n}<\/pre>\n
And this:<\/p>\n
Iterator<Foo> iter = list.iterator();\r\nif iter.hasNext()\r\n{\r\n  iter.next(); \/\/ skip the first element\r\n}\r\nfor Foo foo in iter\r\n{\r\n  stdout::println(foo); \/\/ starts at the second element of the list\r\n}<\/pre>\n
Auto-assign parameters [commit<\/a>]<\/h3>\n
These are something I’ve wanted Java to have for a while, but they’re purely syntactic sugar. Basically, they let you define a constructor\/method(\/property setter) parameter which, instead of creating a local variable, just assigns to a field. It’s easier to show it than to describe it. Instead of writing this:<\/p>\n
class Item\r\n{\r\n  string name;\r\n  string description;\r\n  uint price;\r\n  create(string name, string description, uint price)\r\n  {\r\n    this.name = name;\r\n    this.description = description;\r\n    this.price = price;\r\n  }\r\n  \/\/ ... getters and setters ...\r\n}<\/pre>\n
You can write this (also, you can use properties instead of writing getters and setters!):<\/p>\n
class Item\r\n{\r\n  property string name;\r\n  property string description;\r\n  property uint price;\r\n  create(@name, @description, @price);\r\n}<\/pre>\n
The auto-assign parameters get assigned just before the body of whatever you’re calling.
\nWith this change, when you’re using an auto-assign parameter a body is added automatically, so you can put a semicolon instead of an empty body.
\nYou can also do some cool things like:<\/p>\n
void setHalfPrice(@price)\r\n{\r\n  price \/= 2;\r\n}<\/pre>\n
This works because the parameter doesn’t create a local variable, so when you say “price” you’re actually referencing the property.<\/p>\n
 <\/p>\n
That’s as far as I’ve got right now. Hopefully I’ll add default arguments and varargs soon. However, I do need to do some preparation for job interviews, so I’m not sure when my next post will be.<\/p>\n","protected":false},"excerpt":{"rendered":"
Update 2018-02-26: This was written several years ago, and Plinth development is essentially dead now. (In retrospect,\u00a0although it was true at the time, this was a bad title and it’s been annoying me ever since.) I thought I’d write a status update, since it’s been almost four months since I last posted anything here. Firstly, […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"_links":{"self":[{"href":"https:\/\/bryants.eu\/blog\/wp-json\/wp\/v2\/posts\/396"}],"collection":[{"href":"https:\/\/bryants.eu\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bryants.eu\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bryants.eu\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/bryants.eu\/blog\/wp-json\/wp\/v2\/comments?post=396"}],"version-history":[{"count":7,"href":"https:\/\/bryants.eu\/blog\/wp-json\/wp\/v2\/posts\/396\/revisions"}],"predecessor-version":[{"id":426,"href":"https:\/\/bryants.eu\/blog\/wp-json\/wp\/v2\/posts\/396\/revisions\/426"}],"wp:attachment":[{"href":"https:\/\/bryants.eu\/blog\/wp-json\/wp\/v2\/media?parent=396"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bryants.eu\/blog\/wp-json\/wp\/v2\/categories?post=396"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bryants.eu\/blog\/wp-json\/wp\/v2\/tags?post=396"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}