Closed FractalU closed 3 years ago
This is intentional so that line numbers match up to any runtime errors that may occur
to elaborate: lua doesn't support source maps (at least, not to my knowledge) and making good source maps is probably also not exactly the easiest.
So, as a compromise the generated lua is made to look as much as the original teal as possible and the extra white lines are an (unfortunate) consequence.
Personally, I like it. It makes it very easy to see what your code got turned into, so at least for debug/development builds it works really well (though, sourcemaps + this generation style would be even better I think?). I do agree though that for builds meaning to be released that it isn't as great, especially if it needs to be sent over the network. However, I do believe there are minifiers for lua, which could help with this?
Thanks, this makes a lot of sense. Then I leave it that way. Minifiers or even formatters make builds a lot more complicated.
After some thought I came to the conclusion that it makes sense to enable it as an option in 'tl gen'. For debug/developer builds it makes perfect sense to leave it as it is. For release builds it would be nicer to have the code a bit more readable and less code generated and it usually doesn't matter whether the lua error messages match up the teal source code in the release case. I don't know whether it would make the compiler unnecessarily more complicated or not. I'm not asking for source maps.
@lenscas's answer summarizes the reason why I'm keeping the newlines.
I don't intend to add the option because it would send the wrong message: making the generated Lua readable is explicitly not a goal — this is compiler output, so it's meant for execution, not for humans to read. Humans are expected to read Teal code. There are often cases where compilers need to generate "unreadable code" so I'd like to keep that prerogative — which I have used in the past, for example when Teal generates some ugly code for compatibility of operators — and not make output readability into a design constraint (also note that Teal does not preserve comments, or respect the input's indentation style — it only outputs indentation altogether to help compiler devs debug the compiler itself :grin: ).
Hope that clarifies! I'm closing the issue for now, but feel free to add any other questions or comments!
How is the state of documentation with teal? If the teal compiler strips off comments then the documentation tools like 'LDoc ' cannot work for teal. I searched for 'TealDoc' or 'TLDoc' in luarocks and haven't found anything. Also there is no documentation tool repo in https://github.com/teal-language/. So I assume that there is no documentation support with teal today.
@FractalU I remember reading that someone was working on it and it also looks like cyan
already has documentation working (at least, for its own repo)
I don't know the exact state that documentation generation is in though.
@lenscas Thanks for the response. I looked at cyan and it has its document autogenerated by a script called 'docgen.tl'. It uses the teal parser to generate a document, including the index, from the parsed symbols, This is actually really cool. I assume there is no doc tool for teal today, but it's only a matter of time. I also assume when teal gets more popular over time the 'LDoc' tool will also support teal files.
Also note: Because teal automatically strips all the comments away and doesn't give an option to preserve them, all the existing documentation solution for lua cannot work for teal. The only popular documentation tool I saw is 'LDoc'. So for me this is not that much of a problem.
While using Teal to write lua programs, I looked at the lua code generated by 'tl gen --check'. On each type declaration, that gets elided away the newlines remain.
e.g. """local enum Color "red" "blue" "green" end
local c: Color = "red" print(c)"""
gets compiled to """local Color = {}
local c = "red" print(c)"""
I don't know whether the remaining newlines is intended or not. To me, it looks more like code generated rather than human readable. I would suggest to elide the newlines as well on each type declaration. suggestion: """local Color = {}
local c = "red" print(c)"""