5 ms·

"The VM code is about 2K lines long, the multipass compiler code is about 3K lines and the shared code is about 2K lines long." I was surprised by these number

"The VM code is about 2K lines long, the multipass compiler code is about 3K lines and the shared code is about 2K lines long." I was surprised by these numbers so I checked, and this is highly misleading (or very much out of date). The parser alone (https://github.com/marcobambini/gravity/blob/master/src/compiler/gravity_parser.c https://github.com/marcobambini/gravity/blob/master/src/comp...) is over 2K lines, and with the lexer and the AST definitions the frontend of the compiler is already comfortably above 3K lines. Also, the VM (https://github.com/marcobambini/gravity/blob/master/src/runtime/gravity_vm.c https://github.com/marcobambini/gravity/blob/master/src/runt...) is about 2K lines, but then there is another 3K lines in another "runtime" file (https://github.com/marcobambini/gravity/blob/master/src/runtime/gravity_core.c https://github.com/marcobambini/gravity/blob/master/src/runt...). Still, it's not a huge project, and it might be interesting as a point of study for people interested in compilers (to bytecode) or bytecode interpreters. The input syntax looks pretty as well. Interestingly, https://github.com/marcobambini/gravity/blob/master/src/runtime/gravity_vm.c https://github.com/marcobambini/gravity/blob/master/src/runt... also serves as a nice illustration of the fact that if tabs are allowed in source code, people will mix them with spaces, resulting in code that looks bad unless you have the exact same tab width preferences as the author.

davelnewton 8y ago
I'm not sure how the parser and lexer/etc. line count matters for the VM line count. shrug Definitely something I'll be looking at for my embedded work; it may fill a gap in my toolchain. And boo-hiss tabs.
- filmor 8y ago
  Parser and lexer matter for the multipass compiler.
  - davelnewton 8y ago
    Which isn't the VM, right?
    - tom_mellior 8y ago
      No, it's the compiler. Are you still overlooking the phrase "the multipass compiler code is about 3K lines" in my original post above?
- Sean1708 8y ago
  > And boo-hiss tabs. At the risk of starting a flame-war: boo-hiss not using a formatter.
  - davelnewton 8y ago
    Orthogonal. Once you have tabs, any viewing of that file will rely on the tab size set by whatever viewer you're using: mixing tabs and spaces basically never works. At least if it's just tabs everything will be seen wrong consistently. The only reliable mechanism is spaces-only. :p
    - Sean1708 8y ago
      But if you're using a formatter then it doesn't matter whether you use tabs, spaces, minimal whitespace, or any mix thereof because that's what the formatter is for. Also if you're using a formatter then you can do the correct thing and use tabs for indentation and spaces for alignment, because the formatter will ensure that the output is consistent.
      - davelnewton 8y ago
        The output is consistent if your tab settings are always the same when you look at your code, and you use the same tab size across all languages. I view code in multiple ways, have different indentations for different languages (not many different now), and have clients that enforce difference indentation settings. It just doesn't work.
        Sean1708 8y ago
        > The output is consistent if your tab settings are always the same when you look at your code, and you use the same tab size across all languages. I don't really understand what you're getting at here to be honest, surely if you change your tab settings it's because you want the code to look different? > I view code in multiple ways, have different indentations for different languages (not many different now), This is exactly what tabs are great for! You can set the tab width based on language without having to force that choice on anyone else. > clients that enforce difference indentation settings Again, formatter.
cup-of-tea 8y ago
> the fact that if tabs are allowed in source code, people will mix them with spaces, resulting in code that looks bad unless you have the exact same tab width preferences as the author. Every bit of go code shows you are wrong. If a codebase uses tabs for indentation (which is the only place they should ever be allowed) then it's a mistake to use spaces for indentation. My first ever contribution to a free software project (when I was about 15) used the wrong whitespace for indentation. They made me fix the patch and that is how I learnt about whitespace. The example you've shown is just an example of bad code standards, not tabs being bad.
- tom_mellior 8y ago
  The problem with the code in question is a problem of alignment, not indentation. Edit: Ah, no, there are some indentation problems too. But it's the alignment that I first noticed because it's so jarring.
  - lomnakkus 8y ago
    Wow, yeah, that's why should never change tab width to anything other than 8 unless you're very sure that you've got things set up exactly right tooling-wise.
  - ricardobeat 8y ago
    If you open it in an editor, you'll see no indentation problems: https://monosnap.com/direct/cSBUU3ik31upjfdxpc8p9RJjLyVtda https://monosnap.com/direct/cSBUU3ik31upjfdxpc8p9RJjLyVtda This is a result of using 'elastic tabs' which GitHub is not able to display correctly (and also the reason people will use spaces for alignment in a tab-indented project).
    - tom_mellior 8y ago
      If you open it in an editor and have the same tab width configured as the author, you'll see no indentation and alignment problems. If you set a different tab width (the purported advantage of tabs), the code will be messed up (the actual disadvantage of tabs). Not sure why you blame this on GitHub. Emacs with a tab width of 2 or vim with a tab width of 8 will also show this code with broken formatting.
stelonix 8y ago
> also serves as a nice illustration of the fact that if tabs are allowed in source code, people will mix them with spaces This seems disingenuous, I could just as well point to a piece of code and say "if spaces are allowed in source code, people will mix them with tabs". People should get over themselves and accept some people prefer a single character to specify tabbed-space and other people want the exact number of spaces. I find space characters cumbersome to work with, so I use tabs myself.
- vorpalhex 8y ago
  In addition, most editors these days should be able to fix this as you go so you can use whatever your preference is and comply with the projects standards.

davelnewton 8y ago

I'm not sure how the parser and lexer/etc. line count matters for the VM line count. shrug Definitely something I'll be looking at for my embedded work; it may fill a gap in my toolchain. And boo-hiss tabs.

filmor 8y ago
Parser and lexer matter for the multipass compiler.
- davelnewton 8y ago
  Which isn't the VM, right?
  - tom_mellior 8y ago
    No, it's the compiler. Are you still overlooking the phrase "the multipass compiler code is about 3K lines" in my original post above?
Sean1708 8y ago
> And boo-hiss tabs. At the risk of starting a flame-war: boo-hiss not using a formatter.
- davelnewton 8y ago
  Orthogonal. Once you have tabs, any viewing of that file will rely on the tab size set by whatever viewer you're using: mixing tabs and spaces basically never works. At least if it's just tabs everything will be seen wrong consistently. The only reliable mechanism is spaces-only. :p
  - Sean1708 8y ago
    But if you're using a formatter then it doesn't matter whether you use tabs, spaces, minimal whitespace, or any mix thereof because that's what the formatter is for. Also if you're using a formatter then you can do the correct thing and use tabs for indentation and spaces for alignment, because the formatter will ensure that the output is consistent.
    - davelnewton 8y ago
      The output is consistent if your tab settings are always the same when you look at your code, and you use the same tab size across all languages. I view code in multiple ways, have different indentations for different languages (not many different now), and have clients that enforce difference indentation settings. It just doesn't work.
      - Sean1708 8y ago
        > The output is consistent if your tab settings are always the same when you look at your code, and you use the same tab size across all languages. I don't really understand what you're getting at here to be honest, surely if you change your tab settings it's because you want the code to look different? > I view code in multiple ways, have different indentations for different languages (not many different now), This is exactly what tabs are great for! You can set the tab width based on language without having to force that choice on anyone else. > clients that enforce difference indentation settings Again, formatter.

cup-of-tea 8y ago

> the fact that if tabs are allowed in source code, people will mix them with spaces, resulting in code that looks bad unless you have the exact same tab width preferences as the author. Every bit of go code shows you are wrong. If a codebase uses tabs for indentation (which is the only place they should ever be allowed) then it's a mistake to use spaces for indentation. My first ever contribution to a free software project (when I was about 15) used the wrong whitespace for indentation. They made me fix the patch and that is how I learnt about whitespace. The example you've shown is just an example of bad code standards, not tabs being bad.

tom_mellior 8y ago
The problem with the code in question is a problem of alignment, not indentation. Edit: Ah, no, there are some indentation problems too. But it's the alignment that I first noticed because it's so jarring.
- lomnakkus 8y ago
  Wow, yeah, that's why should never change tab width to anything other than 8 unless you're very sure that you've got things set up exactly right tooling-wise.
- ricardobeat 8y ago
  If you open it in an editor, you'll see no indentation problems: https://monosnap.com/direct/cSBUU3ik31upjfdxpc8p9RJjLyVtda https://monosnap.com/direct/cSBUU3ik31upjfdxpc8p9RJjLyVtda This is a result of using 'elastic tabs' which GitHub is not able to display correctly (and also the reason people will use spaces for alignment in a tab-indented project).
  - tom_mellior 8y ago
    If you open it in an editor and have the same tab width configured as the author, you'll see no indentation and alignment problems. If you set a different tab width (the purported advantage of tabs), the code will be messed up (the actual disadvantage of tabs). Not sure why you blame this on GitHub. Emacs with a tab width of 2 or vim with a tab width of 8 will also show this code with broken formatting.

stelonix 8y ago

> also serves as a nice illustration of the fact that if tabs are allowed in source code, people will mix them with spaces This seems disingenuous, I could just as well point to a piece of code and say "if spaces are allowed in source code, people will mix them with tabs". People should get over themselves and accept some people prefer a single character to specify tabbed-space and other people want the exact number of spaces. I find space characters cumbersome to work with, so I use tabs myself.

vorpalhex 8y ago
In addition, most editors these days should be able to fix this as you go so you can use whatever your preference is and comply with the projects standards.