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 <schnet...@gmail.com> 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
> <cris...@gmail.com> 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 <schnet...@gmail.com>
> wrote:
> >>
> >> 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/
>
>
>
> --
> Erik Schnetter <schnet...@gmail.com>
> http://www.perimeterinstitute.ca/personal/eschnetter/
>
