On Fri, Feb 12, 2016 at 5:17 AM, Cristóvão Duarte Sousa <cris...@gmail.com> wrote: > 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.
Adding to the `Expr` type is expensive, since it's used a lot. Instead, you can add extra `Expr` objects, e.g. `Expr(:empty_line)`, or `Expr(:block_comment, "text")`, or `Expr(:inline_comment, "text")`. -erik > 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? >>>>> >>>>> >>> > -- Erik Schnetter <schnet...@gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/
