I don't know if it has been said here before, sorry if I'm repeating, but: a way to represent the "concrete" syntax tree, convert it to AST and then back would be of great use here, see https://github.com/JuliaLang/JuliaParser.jl/issues/22 .
I actually thought a lot about that, and imagine that the `Expr` type could have an extra field to hold syntax delimiters (punctuation and whitespace) which is found around and between its arguments. But a great knowledge of the parsers, both Flisp and Julia written ones, would be required. Then I also wondered that maybe one formal, but incomplete, grammar could be useful to construct such tree, as in intermediate step between source code and real AST. That would allow the creation of very powerful autoformatting tools, along with lints, refactoring and other advanced IDE functionalities. On Friday, February 12, 2016 at 4:58:33 AM UTC, Maxim Grechkin wrote: > > Was there any progress on this lately? I've noticed that atom-beautify > plugin doesn't have Julia support( > https://github.com/Glavin001/atom-beautify/issues/799), but there doesn't > seem to be a tool that it can hook into. > > On Saturday, January 11, 2014 at 9:22:14 AM UTC-8, Stefan Karpinski wrote: >> >> 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 <j.l.van...@gmail.com> >> 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 <j.l.van...@gmail.com> >>>> 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 <j.l.van...@gmail.com> >>>>>> 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? >>>>>> >>>>> >>>> >>
