Re: [julia-users] Autoformatting for Julia?

[Tony Kelman]

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?

[Cristóvão Duarte Sousa]

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?

[Erik Schnetter]

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 

Re: [julia-users] Autoformatting for Julia?

[Cristóvão Duarte Sousa]

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 

Re: [julia-users] Autoformatting for Julia?

[Erik Schnetter]

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 

Re: [julia-users] Autoformatting for Julia?

[Cristóvão Duarte Sousa]

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.
> >> >>
> 

Re: [julia-users] Autoformatting for Julia?

[Maxim Grechkin]

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? 
>

>>>
>

[julia-users] Autoformatting for Julia?

[Job van der Zwan]

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.comjavascript:
  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? 

Re: [julia-users] Autoformatting for Julia?

[Stefan Karpinski]

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.vanderz...@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.comwrote:

 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?