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/
