Closed jurgenvinju closed 2 years ago
Do we have a 5 year horizon for Clair? Given the popularity and prevalence of C++ in the real world, I can definitely see ample opportunity for using ClaiR over the coming years. As you mention, CDT is indeed relatively stable and is actively maintained. Additions or adaptions to CDT's internal AST structure can easily be incorporated into ClaiR as well (at least by me).
Can you lead this for the coming 5 years (with help)? I'd be more than happy to lead this project, with the caveat that being able to commit to extensive feature requests would depend on my then-actual situation.
that's good enough for me. thanks @rodinaarssen
I would like to see some of the open issues here: https://github.com/cwi-swat/clair/issues
@rodinaarssen could you take some time and dump some (short) issues that you already know in there?
@jurgenvinju I've added some issues that popped into my mind.
Thanks
@rodinaarssen could you explain the dependency/relationship to your custom branch of rascal for the beautiful trick of concrete syntax without a rascal grammar?
Especially in relationship to the long term maintenance. Should that branch be considered part of clair support? Or is it an added benefit?
I do expect to use clair in the future and it will be a interesting technology to have around in a stable way.
That concrete syntax feature depends on my implementation of the Concretely framework in the Rascal interpreter; the branch containing this implementation is unmerged. Concretely is not ClaiR-specific, but could be implemented for any object language (e.g., lang/cpp/Concrete.rsc contains the implementation for ClaiR, the paper also describes my efforts for Java (JDT) and Javascript (js-air)).
@jurgenvinju and I have discussed a possible way of moving the idea behind Concretely forward in a more integrated fashion. If we do so, concrete syntax for ClaiR will be just around the corner.
Cool, sounds good.
Are there automated test we can run to make sure the output is as expected? A while back @lmove and I developed those for java M3. Roughly, we commit the expected results of calcuting an M3 model, and compare it to a result we get during testing. It has helped us uncover small regressions when updating to newer versions.
Sounds very useful indeed. At the moment, I do not have publicly available expected output. If we decide on a reasonable target project, we should definitely implement this.
If we find a suitable open source version of snakes and ladders in c++ that would make sense. It's a typical teaching exercise that is supposed to use all kinds of OO features from a language. We use it for Java too right?
Yup, indeed snakes and ladders.
But we also analyse a few full jars.
I've voted in favor, as I said, it's a great addition to Rascal community.
I think we also need to think about stable releases for clair, so that users have the option not to track the SNAPSHOT
as directly ;)
So far we've collected these requirements:
Let's make the move after we've tested the road with the salix project, including a mvn jar release that works with vscode, and an eclipse plugin and an update site. if we know how to do that for salix, then doing it for clair should be an extended version of that.
moving forward with this now that clair compiles against the latest version of Rascal, on a recent version of Eclipse and Java 11
This is to propose Clair as a usethesource project
Motivation
Questions
Votes