[julia-users] Autoformatting for Julia?
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 > > > 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 >>> 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? >>> >> >
Re: [julia-users] Autoformatting for Julia?
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 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 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 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? >>> >>
Re: [julia-users] Autoformatting for Julia?
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 > 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 >>> 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 > 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? > >>> >
Re: [julia-users] Autoformatting for Julia?
Would maybe be better to start a new thread asking about this rather than adding to an old one. But anyway, no there is not currently anyone working on a standalone Julia formatter as far as I know. The IDE's under development as Eclipse and Atom plugins are working on their own formatters, but they are somewhat specific to the IDE environment that they're written for. It would be great to have something command-line or a Julia package that looked into this, and could be used like clang-format or yapf. On Thursday, February 11, 2016 at 8:58:33 PM UTC-8, 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 >> 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 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 >> 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? >> > >>
Re: [julia-users] Autoformatting for Julia?
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 >> 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 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 >> 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? >> > >>
Re: [julia-users] Autoformatting for Julia?
On Fri, Feb 12, 2016 at 5:17 AM, Cristóvão Duarte Sousa 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 >>> 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 > 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 >>> 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 t
Re: [julia-users] Autoformatting for Julia?
Yes, but then where such Exprs will placed? Not inside the args array of other Exprs... I guess that if it is necessary to revert back to source code from an AST, then a modification to Expr has to be made... On Fri, Feb 12, 2016 at 1:47 PM Erik Schnetter wrote: > On Fri, Feb 12, 2016 at 5:17 AM, Cristóvão Duarte Sousa > 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 > > >>> 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 t
Re: [julia-users] Autoformatting for Julia?
Line numbers are already handled in this way: julia> parse("f(x)=x") |> dump Expr head: Symbol = args: Array(Any,(2,)) 1: Expr head: Symbol call args: Array(Any,(2,)) 1: Symbol f 2: Symbol x typ: Any 2: Expr head: Symbol block args: Array(Any,(2,)) 1: LineNumberNode file: Symbol none line: Int64 1 2: Symbol x typ: Any typ: Any -erik On Fri, Feb 12, 2016 at 10:25 AM, Cristóvão Duarte Sousa wrote: > Yes, but then where such Exprs will placed? Not inside the args array of > other Exprs... > I guess that if it is necessary to revert back to source code from an AST, > then a modification to Expr has to be made... > > On Fri, Feb 12, 2016 at 1:47 PM Erik Schnetter wrote: >> >> On Fri, Feb 12, 2016 at 5:17 AM, Cristóvão Duarte Sousa >> 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 >> >>> >> >>> 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 >> > >> > 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 the
Re: [julia-users] Autoformatting for Julia?
Hum, OK, it uses block Exprs... That may then work for punctuation and whitespace too. On Fri, Feb 12, 2016 at 4:20 PM Erik Schnetter wrote: > Line numbers are already handled in this way: > > julia> parse("f(x)=x") |> dump > Expr > head: Symbol = > args: Array(Any,(2,)) > 1: Expr > head: Symbol call > args: Array(Any,(2,)) > 1: Symbol f > 2: Symbol x > typ: Any > 2: Expr > head: Symbol block > args: Array(Any,(2,)) > 1: LineNumberNode > file: Symbol none > line: Int64 1 > 2: Symbol x > typ: Any > typ: Any > > -erik > > On Fri, Feb 12, 2016 at 10:25 AM, Cristóvão Duarte Sousa > wrote: > > Yes, but then where such Exprs will placed? Not inside the args array of > > other Exprs... > > I guess that if it is necessary to revert back to source code from an > AST, > > then a modification to Expr has to be made... > > > > On Fri, Feb 12, 2016 at 1:47 PM Erik Schnetter > wrote: > >> > >> On Fri, Feb 12, 2016 at 5:17 AM, Cristóvão Duarte Sousa > >> 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 > >> >>> > >> >>> 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 > >> > > >> > 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 t