Kind of. I don't think that expression printing is even remotely good enough for this yet, but that's the basic idea that makes the most sense to me. No point in using separate parse or print code when there's already functions that do this stuff.
On Sat, Jan 11, 2014 at 12:06 PM, Job van der Zwan <[email protected] > wrote: > So you are saying that the most of the tooling required for an > auto-formatting tool is already there? > > On Thursday, 9 January 2014 14:42:40 UTC+1, Stefan Karpinski wrote: >> >> I would be into having an auto-formatting tool. The way to do this would >> be to work on the printing of ASTs until the way the code prints is the >> standard way it should be formatted. Then you have an auto-formatter: parse >> the code and print the resulting AST. One missing thing is that parser >> currently discards comments. >> >> >> On Thu, Jan 9, 2014 at 6:48 AM, Job van der Zwan <[email protected]>wrote: >> >>> The problem I see with that is that you can wait for a *very* long time >>> before any consensus emerges. There are simply many choices to be made in >>> that regard which at the end of the day are kind of arbitrary - that >>> *a*choice is made and consistently followed is more important, and again the >>> benefit of autoformatting is that you don't have to waste putting effort >>> into doing so. >>> >>> Having something something concrete to respond to also helps with the >>> discussion - an autoformatting tool will impose a certain style, which will >>> drive the discussion of standardising proper style. If people disagree with >>> the formatting it provides, great! That means a discussion is triggered. >>> >>> So instead of waiting for a consensus to emerge, I think that building >>> an autoformatting tool with a "good enough first guess" in terms of style >>> would be the place to start. Even if it starts out with terrible style >>> choices otherwise. >>> >>> (is this worth starting a separate discussion on the topic?) >>> >>> >>> On Thursday, 9 January 2014 03:18:05 UTC+1, John Myles White wrote: >>> >>>> There is not yet, because there is still not a consensus on proper >>>> style. Hopefully once we have that, it will be easier to make a julia fmt >>>> tool. >>>> >>>> — John >>>> >>>> On Jan 8, 2014, at 6:09 PM, Job van der Zwan <[email protected]> >>>> wrote: >>>> >>>> > Depends on what you mean with legibility. >>>> > >>>> > For example (and not at all related to x.f(y) vs f(x, y)), if I look >>>> at my experience with the Go programming language, once you get used to its >>>> imposed One True Way of formatting it really makes reading other people's >>>> source code a lot easier. And talking about spending energy on the subject >>>> of legibility: setting up my editor to use go-fmt (the autoformatting tool) >>>> when building/saving code means I don't have to spend any time thinking >>>> about it when writing my own code either; it will automatically get fixed. >>>> > >>>> > It's one of those things the Go developers are very enthusiastic >>>> about, and at first you go "really? That's a killer feature?" but after >>>> using it you do start to miss it in other languages. >>>> > >>>> > Speaking of which, is there an autoformatting tool for Julia? >>>> >>> >>
