4 ms·

Doesn't work as well in languages where indentation is significant. But even in languages where indentation is insignificant you'll run into issues doing things

by mbell 8y ago

Doesn't work as well in languages where indentation is significant. But even in languages where indentation is insignificant you'll run into issues doing things like line splitting.

alangpierce 8y ago
FWIW Black ( https://github.com/ambv/black https://github.com/ambv/black ) is a disciplined Python formatter that's reasonably successful, so I'm not convinced that the "significant indentation" thing actually matters too much; it probably just means that formatters need to be more careful to not introduce bugs, but the same principle of code -> AST -> code seems just as valid. What line splitting issues are you referring to? I've been pretty happy with the approach used by Prettier (and I believe Black) of fitting it on one line if possible, and doing one per line otherwise. I'd say that's my favorite part of Prettier: I don't need to think about wrapping anymore, it figures it out, so it's sad to see that gofmt doesn't do that (from my testing just now).
- mbell 8y ago
  I think you're only considering a one-way transform, what's being proposed above is two-way. i.e. Store the output of Black as the 'canonical' version, but translate it back into your preferred style when looking at the code in your editor. > but the same principle of code -> AST -> code seems just as valid The question is really the reversibility of the transform in a reasonable way. If you are translating all your source to an AST there is technically no reason multiple programmers even need to be working in the same language. However in practice, even within a single language, there are many possible transforms from an AST back into code. Some will make sense, some will be nearly indecipherable. In practice you either limit the allowed transforms such that there is little benefit over a simple linting tool or the problem explodes in complexity.
masklinn 8y ago
> Doesn't work as well in languages where indentation is significant. Store the bytecode, indents and dedents are present as <indent> and <dedent> token which are no different than e.g. <brace, open> and <brace, closed>. Well technically those are in the tokeniser, the AST or bytecode would reify the structures they delimit, and if you stored the AST or bytecode the separator would be reified from there. But the point is that for the machine indentation is no different than any other token (in fact Haskell is defined using braces and semi-colons, the common indentation-based version is an augmentation of the base language which semantically just inserts braces and semicolons)
onion2k 8y ago
Doesn't work as well in languages where indentation is significant. The point is that the code on disk needs to work when it's compiled. That's all. You could write an editor that displays the code in a circle so long as it writes properly indented code when you save. Nothing about the IDE is actually important.

by mbell 8y ago

Doesn't work as well in languages where indentation is significant. But even in languages where indentation is insignificant you'll run into issues doing things like line splitting.

alangpierce 8y ago

FWIW Black ( https://github.com/ambv/black https://github.com/ambv/black ) is a disciplined Python formatter that's reasonably successful, so I'm not convinced that the "significant indentation" thing actually matters too much; it probably just means that formatters need to be more careful to not introduce bugs, but the same principle of code -> AST -> code seems just as valid. What line splitting issues are you referring to? I've been pretty happy with the approach used by Prettier (and I believe Black) of fitting it on one line if possible, and doing one per line otherwise. I'd say that's my favorite part of Prettier: I don't need to think about wrapping anymore, it figures it out, so it's sad to see that gofmt doesn't do that (from my testing just now).

mbell 8y ago
I think you're only considering a one-way transform, what's being proposed above is two-way. i.e. Store the output of Black as the 'canonical' version, but translate it back into your preferred style when looking at the code in your editor. > but the same principle of code -> AST -> code seems just as valid The question is really the reversibility of the transform in a reasonable way. If you are translating all your source to an AST there is technically no reason multiple programmers even need to be working in the same language. However in practice, even within a single language, there are many possible transforms from an AST back into code. Some will make sense, some will be nearly indecipherable. In practice you either limit the allowed transforms such that there is little benefit over a simple linting tool or the problem explodes in complexity.

masklinn 8y ago

> Doesn't work as well in languages where indentation is significant. Store the bytecode, indents and dedents are present as <indent> and <dedent> token which are no different than e.g. <brace, open> and <brace, closed>. Well technically those are in the tokeniser, the AST or bytecode would reify the structures they delimit, and if you stored the AST or bytecode the separator would be reified from there. But the point is that for the machine indentation is no different than any other token (in fact Haskell is defined using braces and semi-colons, the common indentation-based version is an augmentation of the base language which semantically just inserts braces and semicolons)

onion2k 8y ago

Doesn't work as well in languages where indentation is significant. The point is that the code on disk needs to work when it's compiled. That's all. You could write an editor that displays the code in a circle so long as it writes properly indented code when you save. Nothing about the IDE is actually important.