Tuesday, September 6, 2011

When is the SEED M0?

When is the SEED M0?

As recently one Chinese developer have commented about the status of my recently blogged project about the Scala Eclipse IDE. Because this blog is published without any tags. So I used to think nobody will focus on it. This is my expectation in that I I have no habit of publishing any toys.

I'd like to first announce the name of project is SEED - Scala Eclipse Effort for Development":) This project will be hosted in the github. The recent funny thing is Linus Torvalds move the latest linux kernel tree to the github.

The biggest hard point of SEED now is the time. I basically have no time to contribute it except the weekend. I have killed two version of the implementation way. Finally, I decided that there must be one new Scala Model for eclipse-side presentation layer for putting the SEED into one stable and lightweight tooling in the daily usage(like JDT). One hand-written recursive descent parser/scanner for members of Scala top template definition is under construction(parser generators are too terrible for use).

The harder work is here is the spec of Scala language is complex to fully understand. The EBNF syntax notation of Scala in spec have shown some entanglement. Like PATH is StableId, but StableId is also the PATH. This may let the notation writer more convenient, but increase the complexity of understanding and implementation. Some parts of notation is anti-intuitive. like some one pointing out in the official forum, Scala allows such definition:

val 1 = 2

from the syntax aspect, this is allowed by the fact that the pattern match style contructs can be used as one way to define variable(s). Some one think it will be kept for symmetry. But I think there is non-symmetric here in fact(like this literal pattern matching). The scope of the semantic of pattern matching is larger than that of variable definition. It is a bad smell in the language! In fact, this allowance is mainly for convenience. In almost cases, we can move the pattern match semantic just to the right of assignment, like:

val x = selector match { case ....

This kinds of design in the language much increase the freedom of language. But I think the freedom is not always the good thing for the developers. If many ways can reach one point, which way we should choose to go?

And furthermore, the wrost things for the IDE tooling designer is, for parsing such a little constructs, I even need to include almost all the syntax constructs into the parser/scanner. So heavy cost!

Some trade-offs have been made in the process. And I think everything is still under the control. It is hope by me, the SEED M0 could be published in two more weekends or so. That is the time! I am seeking some Scala related opportunities. If this can become true, I will have definitely constant daily time to contribute to the SEED. Wait for that day.

Thanks for all the followers!

1 comment:

Atry said...

关于你抱怨的语法复杂性,马丁老大写过一篇文章为自己辩护

http://lamp.epfl.ch/~odersky/blogs/isscalacomplex.html