Difference between revisions of "GSOC 2013 Ideas"
m (→PyD) |
(Add SDC as a project proposal.) |
||
| Line 14: | Line 14: | ||
Once remaining issues with shared libraries are resolved, it becomes feasible to use D code from dynamic languages. Clearly it's vital to provide easy path for calling it from Python, as it's used by many scientists, amongst others. Although there's [http://bitbucket.org/ariovistus/pyd/ PyD], the last few years saw rising interest in [http://pypy.org PyPy] because it shows much better performance than CPython. For PyPy, the way to go seems to be generating <tt>extern(C)</tt> wrappers for classes/functions/etc. + [http://cffi.readthedocs.org CFFI bindings] for that C code. First part of this can be reused for producing C++ wrapping code -- this is similar in goals to [http://d.puremagic.com/issues/show_bug.cgi?id=9285 dtoh] but here entities to be wrapped should be explicitly mentioned. Extra benefit of producing C++ bindings is ability to call SWIG on them to support other languages. So, perhaps, C++ is the number one target in this respect. | Once remaining issues with shared libraries are resolved, it becomes feasible to use D code from dynamic languages. Clearly it's vital to provide easy path for calling it from Python, as it's used by many scientists, amongst others. Although there's [http://bitbucket.org/ariovistus/pyd/ PyD], the last few years saw rising interest in [http://pypy.org PyPy] because it shows much better performance than CPython. For PyPy, the way to go seems to be generating <tt>extern(C)</tt> wrappers for classes/functions/etc. + [http://cffi.readthedocs.org CFFI bindings] for that C code. First part of this can be reused for producing C++ wrapping code -- this is similar in goals to [http://d.puremagic.com/issues/show_bug.cgi?id=9285 dtoh] but here entities to be wrapped should be explicitly mentioned. Extra benefit of producing C++ bindings is ability to call SWIG on them to support other languages. So, perhaps, C++ is the number one target in this respect. | ||
| + | |||
| + | ==SDC== | ||
| + | |||
| + | SDC is a work in progress in order to implement a D frontend in D. The lexing/parsing/semantic part is available as a lib in order to allow other tools to be built on top of it. The long term goal is to improve the tooling around D in general. | ||
| + | |||
| + | If SDC handle the most advanced features of D now (CTFE, templates, static ifs, mixin) many things remains to do. They include : | ||
| + | * Full support of D's OOP capabilities. | ||
| + | * Context pointers creation (closures and delegate passed by alias). | ||
| + | * pure, @safe | ||
| + | * shared/synchronized. | ||
| + | * and much more ! | ||
| + | |||
| + | A lot of work, but the project have now a solid base to build upon. | ||
| + | |||
| + | SDC is leveraging LLVM in order to JIT CTFE and doing codegen. It is probably possible to mutuality work around LLVM with LDC (for instance Emscripten and asm.js ). | ||
Revision as of 15:40, 27 March 2013
Refer to our GSoC 2013 page for details about this project.
LDC
LDC is based on LLVM, so this suggests several small project ideas, like porting some of the LLVM tools/features designed for C/C++ to the D-LDC world. Things like:
- Perform more static analysis, like abstract compilation or linting (Clang does both);
- Develop a simple way to compile D for the browser with Emscripten to "asm.js" (this is a very small project);
- Perform other run-time tests as done by Clang;
- Use some of the D semantics to improve D code optimization (Walter talks about this all the time);
- Implement better high level optimizations for D code that uses array ops.
PyD
Once remaining issues with shared libraries are resolved, it becomes feasible to use D code from dynamic languages. Clearly it's vital to provide easy path for calling it from Python, as it's used by many scientists, amongst others. Although there's PyD, the last few years saw rising interest in PyPy because it shows much better performance than CPython. For PyPy, the way to go seems to be generating extern(C) wrappers for classes/functions/etc. + CFFI bindings for that C code. First part of this can be reused for producing C++ wrapping code -- this is similar in goals to dtoh but here entities to be wrapped should be explicitly mentioned. Extra benefit of producing C++ bindings is ability to call SWIG on them to support other languages. So, perhaps, C++ is the number one target in this respect.
SDC
SDC is a work in progress in order to implement a D frontend in D. The lexing/parsing/semantic part is available as a lib in order to allow other tools to be built on top of it. The long term goal is to improve the tooling around D in general.
If SDC handle the most advanced features of D now (CTFE, templates, static ifs, mixin) many things remains to do. They include :
* Full support of D's OOP capabilities. * Context pointers creation (closures and delegate passed by alias). * pure, @safe * shared/synchronized. * and much more !
A lot of work, but the project have now a solid base to build upon.
SDC is leveraging LLVM in order to JIT CTFE and doing codegen. It is probably possible to mutuality work around LLVM with LDC (for instance Emscripten and asm.js ).
