//1. WHAT IS THIS PROJECT?
    I am planning to create a new Programming Language.
    The language will be called eurolang.


//2. WHAT TYPE OF LANGUAGE?
    eurolang is planned to be a general purpose, relatively low level programming language.
    Low-level magic like memory management and pointer arithmetic will  available, and built into the syntax.
    No compromises here.
    eurolang's PRIMARY goal is to be able to go as low level as C does.

    At the same time, I will try to create a syntax that will be as programmer-friendly as it can get.
    I imagine a modern, elegant syntax, like swift, kotlin or es6 javascript have.

    I think that dealing with low level stuff, like memory management and pointer arithmetic,
    is by itself messy enough.
    It's awesome, but messy and often, a bit painful experience.

    I would like to ease that pain by creating a syntax that is as programmer-friendly as it can get.




//3. WHERE I COME FROM?
    I hope my personal preferences do no influence the future of this new language.
    But still, I have to list them so that my biases can be known:

    - I deeply respect languages like C and C++. Their contribution and influence is MONUMENTAL.
      As you will notice from my code, I am not an expert on those languages, but still, I acknowledge their value.
      But...

    - As a whole, I am more of the java/kotlin/javascript/swifty type of guy.
      These are the languages I enjoy to code on.
      I find coding with js(es6+), or java(8+) a really nice experience.
      And mainly, this is because I find their syntax to be really elegant.
      Arrow functions is an absolute must-have for me, built-in array/map/function utils like filter and map are precious.
      I think dynamic structures like json-like or xml-like is a great thing to support natively.
      Some times runtime performance is simply not critical. But coding performance and maintainability is.

    - I love the import-export system of languages like javascript or python.
      I find this much more deterministic, ordered, and intuitive than the copy-pasty #include of C/C++.
      Every source file is an independent entity that declares what symbols to export, which to import, and where to import them from.
      In eurolang, source files will not import other source files.
      They will import "stuff" FROM other source files.

    - Header files
      I appreciate the reason those exist.
      But if I had to chose between having to work with 12 files open on my text editor, or 6,
      I would probably choose 6.
      If I had to refactor 2 places, or 1 every time I change a function's name or signature, I would choose 1.
      If I had to type 2 times in 2 files for creating a new function, or simply in 1, I would choose 1.

      I think things that belong together should be written together.
      I think it is clear that I hate them.
      I would try to work around the need of them in all costs.
      And since I see that other languages managed to get rid of them, I think eurolang will be able too.s


   - Forward declarations.
     That is INSANE.
     No programmer should use his precious brain power to think if he used a function ad line 7, but declared it in line 17.
     No programmer should try to solve the puzzle of include ordering in order to make the compiler happy.
     That sucks.

     Programmers have much more important things to destroy their brains for.
     Same true for type declarations, of course.


   - My knowledge about C is limited.
     I learned a lot while deveoping this project, but still, I feel that I am at the beginning.
     Any C/C++ magician mostly welcome to participate on this project!
     If you this kind of sorcerer, but you don't have time to participate, you could still provide technical/architectural advices.
     This would be precious, too...




4. WHAT THE LANGUAGE WILL FOR SURE HAVE
    - native support for real arrays, like C has. It turns our we need to separate an array from its length very rarely. But still, it should be possible.
    - native support for "fake arrays" (like java, with a length property..)
    - native support for lists (like js array, that one can push pop)

    - Native support for map type, and xml-like type.

    - char array literals (like C strings, in fact char[]).
    - strings with length property (this is the way to go 99% of the times. So, native support for that)

    - namespaces. Each source file belongs to one namespace. The namespace is the first thing to appear on the file.
      Kind of like the java's package.
    - functions as first-class data types. pointers to functions. function literals (arrow functions).
    - basic OO support (class, interface, constructors, destructors, this)

    - optional semicolons to terminate a command.




5. THINGS THAT WE WILL MAYBE HAVE
    - compiler super-global variable, through which the programmer can interact with the compiler.
        This will be similar to c pre-processor, but it will not introduce any parallel syntax, foreign to the main language.
    - var, const and val.
    - function identifiers: modifier, pure etc(...)
    - auto-freed variables
    - annotated blocks: @abc {}


6. THINGS THAT WE WILL NOT HAVE
    - tabulation for control flow, like python.
    - the need for type and function forward declaration
    - the need of .h files




7. THE TECHINICAL DETAILS OF THIS PROJECT
    - I write a compiler (in C/C++) for the new language, using llvm.
      Special credits to Roger Ferrer Ibáñez for his gcctiny tutorial.
      This was my code entry point, because, before switching to llvm, I was planning to make eurolang a gcc frontend
      So, thanks, Roger :)

    - I use flex and bison to read the text and build the AST.
    - I try to unit test all of my code. Also my flex and bison syntax must be unit tested, because A LOT can go wrong there.

    - My naming conventions are very java-ish. Please follow those
            --- Types start with letter, like EulToken. variables and function names start with small letter, like myVar.
            -- camelCase.
    - This will be free software.




8. WHAT I EXPECT FROM THIS PROJECT
    - To be realistic, nothing big, just fun, excitement and learning.
      As I start this project, I would say that the most likely scenario is that I will be the only person engaged.
      But still, it is a nice and fun experience to create a language and a compiler.