Skip to content

Latest commit

 

History

History
72 lines (47 loc) · 3.22 KB

README.md

File metadata and controls

72 lines (47 loc) · 3.22 KB
Raw

codecov Codacy Badge

Linux/Mac: Build Status

Windows: Build status

Elysium

Join the chat at https://gitter.im/MetaElysium/Lobby

Important: Will be porting to scalameta/scalagen soon (tm)

Incredibly WIP/Experimental, everything is in a state of flux until scalameta/paradise hits 3.0.0. api's can change/dissapear at a moments notice

"Elysium - any place or state of perfect happiness; paradise."

Elysium has 3 goals.

  1. Make macro creation as simple as possible
  2. Teach people how to write macros
  3. Have a huge number of useful macros on hand for people to use

Some useful things

  • In core, Renamed and Decorator have examples of using arguments in macro
  • In misc, there is a simple

Modules

I have also detailed what kind of dependency is required. Mixed means can be either depending on how you use it

  • [Runtime] all - Aggregation of all projects
  • [Compile] core - The main things people will want when creating their own macros or using this library
  • [Runtime] debug - Macros for debugging (printing object state etc)
  • [Runtime] profile - Macros for profiling (accumulating statistics etc)
  • [Compile] log - Macros for generating loggers (will possibly use slf4j)
  • [Compile] gen - Macro/Inline generation tooling. This would be in core but has to be compiled seperately
  • [Mixed] manipulate - impicit classes to manipulate meta trees, The semantic api may replace some of this.
  • [Mixed] validate - things for improving the validation and error messages for macros
  • [Compile] misc - generic stuff, more for teaching purposes then anything else, there's usually a better way

Things delaying this project

Ordered by importance will tick when they are complete in scala meta.

Note: Im mainly refraining from working only the macro heavy parts of the project at the moment because once I can parse/generate inline macros I will be rewriting all existing macros.

  • Argument Macros
  • Inline Generation (Macros generating macros)
  • Macro Testing framework
  • Semantic API
  • Multiple Annotations
  • Def Macros

Navigating

Every module has an 'module_tests project'.

This is because we cannot test usages of the annotations in all cases without 3 compilation stages (including test:compile)

So to make a convention and stick with it...

  • a/src/main - Macro code etc.
  • a/src/test - Tests of macro compilation and structure output (eventually)
  • a_test/src/main - Objects that are required in the test code that need to be expanded (eg things annotated with macros)
  • a_test/src/test - General use case testing of macros.