Open projects - vilinski/nemerle GitHub Wiki
This page is a list of subprojects inside the Nemerle project we would like to have done but do not have enough resources to implement ourselves.
If you don't know Nemerle already (but you have some programming experience) -- don't worry, learning Nemerle won't take you more then a few days and you can learn more as you go with the project.
Most of the topics here are possible to be taken as MSc thesis subject in The Computer Science Institute, University of Wroclaw. It is probably also possible to take this as a thesis subject outside our institute. In both cases you should set this thing up with your advisor.
If you want to pick one of these, please contact us so no project is done by more than one student (we will be the locking device here :-).
We (the Nemerle team) will be happy to evaluate results of these projects to help the advisor.
It is also possible to take some other project, not listed here. Especially developing macro packages could be both interesting (from the programming language design point of view) and practical.
Time estimations are based on 40h/week of programming work.
You are welcome to take any of them.
Implement traits.
Time estimate: about 1 week assuming an average knowledge of our macros design and some compiler API, also some work must be done to create a clean design before implementation
The idea is to create set of class level macros, which would generate mock objects. You could just declare the interface, which should be implemented and annotate some specific methods with desired behavior. The rest of code would be automatically generated.
Our macros are perfect implementation framework for creating persistence library. The idea is to have object-oriented model in your application, corresponding database schema and code, which maps one to another. We could create macros, to do any or all of following:
- take DB schema and generate classes corresponding to it (entirely or just all the members for defined empty class stub)
- take set of classes and generate DB schema for them
- generate persistence code for propagating any change of object to underlying database and fetching objects from database data
- consider using the Linq, the upcoming Microsoft solution for query language
Nemerle has rich syntax-extending capabilities. It should be generally possible to implement C#'s query extensions entirely using macros generating the lambda expressions and System.Query calls.
One of the shortcomings of current compiler's implementation is design of some of its API. This usually hits people trying to implement quite complex macros. The goal would be to clean this design by:
- identifying the most problematic parts
- invent the better and easier to use design
- perform the refactoring
Some time we had a question about possible support from language / compiler for effectively solving so called Expression Problem. It would be a nice research topic to create clean design and implementation (probably using some nice macros) to ease the creation of extensible tree-like data-structures in Nemerle.
Some reading is required about current achievements in object-oriented languages design and existing solutions (especially Scala, since its author claims to solve the problem in an elegant way using mixin composition).
Links for consideration:
AOP is a methodology of dividing project design into separate concerns that overlap in functionality as little as possible. It is accomplished using specially designed aspect-oriented languages, which give the framework for defining aspects, specifying how they should be merged into the final program and compiling such specification into a working executable.
In Nemerle we have a more general and low-level approach to the problem of modifying code - macros. They allow generating, analysing and transforming code, as well as traversing the object hierarchy of program (enumerating existing classes, their members, modifying methods' bodies, etc.).
The idea is to implement the AOP design using macros as a compiler extensibility framework. The possible plan of action:
- identify and create a language for specifying aspects, pointcuts, advices (the standard shape of class can be used - by utilizing the attribute macros it can be transformed and interpreted as apect)
- identify the needed modifications of the compiler API (for example making a field reference as join-point would require extending compiler to insert some code at every use of given field)
- implement the aspects weaving
Requirements: moderate knowledge of AOP ideas and/or some aspect-oriented language (like AspectJ), desire to try out possibilities of macros and ability to modify some compler API and code (with help of core team)
It is possible to implement macros for creating and matching over XML much like in Xtatic. Compiler sources in OCaml are also available.
Probably we would need a special XML class in the library as described in the paper. Of course conversion between that implementation and System.Xml classes need to be provided.
We are not very interested in static typing of XML. The most important thing is to develop some practical and usable mechanisms for operating on XML.
It is not required to base this project on Xtatic, but it's clearly required to read about it.
Time estimate: 1 week to 1 month depending on how much you would like to have done.
Requirements: knowledge about XML, XPath and related stuff, knowledge and/or ability to learn about Nemerle macros.
We have implemented some basic support for design by contract in Nemerle. It is based on macros modifying methods' and classes' contents to perform runtime checks of assertions specified by programmer.
There are still many features missing in the implementation - the first idea is to extend it according to (or exceeding) the design of Spec#. The next step is to plug in some theorem-prover framework for checking those assertions statically (and making compiler signal errors about bugs detected in code). Possibly the tools used by SpecC# could be reused here (they check .NET binary assemblies), proving that the idea is language independent.
Time estimate: about 1,5 week for extending the existing implementation to generate more runtime checks; 2 weeks to 1 month for incorporating theorem prover tools in static checking
Requirements: for extending the assertion macros just a curiosity for new ideas is needed and ability to learn how to use macros, for using theorem prover - ability to communicate with Spec# folks and exploring the possibilities of plugging together tools, which were not specifically designed for it.
Status: Wojciech Walewski has declared to work on it.
Nemerle syntax is curly-braces based. We would like a compiler option to make the syntax indentation-sensitive. This can be rather easily done at the lexer. Please refer to indentation-based syntax for more info.
The second part of this project is to make the semantics closer to one used
by Python -- for example drop def for definition, and use plain
assignments. This requires some creativity and good knowledge of Python.
Time estimate: 1 week for the first part, 1 week up to 2 months for the second depending on how much you want to have done.
Requirements: Python experience; at least moderate ability to dive into existing Nemerle code base.
Status: The project is complete and integrated into compiler. The current implementation seems quite stable.
Compilation is usually based on rewriting abstract syntax trees (AST) The tree used internally in Nemerle is now ready to incorporate some optimization pass. There are several things we would like to have done.
Copy propagation, constant propagation, stack slot reuse. Not very much to be done here -- we leave more machine specific stuff (strength reduction etc) for the JIT. What we would like here is to simplify and shorten generated code, so JIT time is shortened and the generated code becomes more readable.
This may require some investigation about what kind of optimizations are performed by the JIT.
There are several places where we allocate more than we should. Some more optimizations are possible for example in closure conversion and tuple construction/matching.
Time estimate: about 2 weeks for each.
Requirements: some ability to dive into existing Nemerle code base, basic knowledge about compiler optimizations (can be gained during the project though, it isn't very hard).
Status: Paweł Różański is working on this project as his MSc thesis.
Most modern IDEs provide some kind of code completion.
For example when you write System.Console.Wr a window is
popped listing WriteLine and Write overloads. This
is relatively easy -- because this can be done with only very local
knowledge of the existing file.
Next there is def x = System.Console.Out; x.Wr. This is somewhat
harder, because you need to know about local variables.
Somewhat orthogonal issue is to collect and maintain information about classes and their members in the current project. This information needs to be updated as the user edits the sources.
To summarize:
- static member completion
- instance member completion
- class information collection
The first two cases can be tested with nemish (Nemerle Interactive Shell). For the third case you would either need to extend one of the existing plugins for MonoDevelop, VS.NET, SharpDevelop or Asper or alternatively create a simple editor with code completion (this isn't very hard for example using GTK Source View).
Time estimate: 2 weeks or more depending on problems for the first two cases, 1 week or more for the third case, +1 week for plugin extension/editor writing.
Requirements: strong ability to dive into existing code base, extend it and debug, ability to communicate with Nemerle team members.
Status: The great work on Visual Studio integration is being made by RSDN folks. A binding for using Nemerle inside MonoDevelop is now usable: it shows class view ans completion. You can check it using MonoDevelop SVN.