{"action":"created","issue":{"url":"https://api.github.com/repos/jakebolewski/JuliaParser.jl/issues/4","labels_url":"https://api.github.com/repos/jakebolewski/JuliaParser.jl/issues/4/labels{/name}","comments_url":"https://api.github.com/repos/jakebolewski/JuliaParser.jl/issues/4/comments","events_url":"https://api.github.com/repos/jakebolewski/JuliaParser.jl/issues/4/events","html_url":"https://github.com/jakebolewski/JuliaParser.jl/issues/4","id":38556622,"number":4,"title":"Comments","user":{"login":"lendle","id":815403,"avatar_url":"https://avatars.githubusercontent.com/u/815403?v=3","gravatar_id":"","url":"https://api.github.com/users/lendle","html_url":"https://github.com/lendle","followers_url":"https://api.github.com/users/lendle/followers","following_url":"https://api.github.com/users/lendle/following{/other_user}","gists_url":"https://api.github.com/users/lendle/gists{/gist_id}","starred_url":"https://api.github.com/users/lendle/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lendle/subscriptions","organizations_url":"https://api.github.com/users/lendle/orgs","repos_url":"https://api.github.com/users/lendle/repos","events_url":"https://api.github.com/users/lendle/events{/privacy}","received_events_url":"https://api.github.com/users/lendle/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2014-07-23T18:20:04Z","updated_at":"2015-08-06T22:28:03Z","closed_at":null,"body":"I'm not even sure that this would make sense to do, but would it be possible to optionally keep comments in a parsed expression? I'm thinking a comment could be stored in a new type, for example a `CommentNode`, sort of like a `LineNumberNode`.  Since an `Expr` with a `CommentNode` in it's `:args` field would not really be a valid expression, I suppose it would also require an `ExprWithComments` type or something. \r\n\r\nThe use case I'm thinking about is an automatic code formatting tool so it would be necessary to keep comments along with the code. \r\n"},"comment":{"url":"https://api.github.com/repos/jakebolewski/JuliaParser.jl/issues/comments/128528337","html_url":"https://github.com/jakebolewski/JuliaParser.jl/issues/4#issuecomment-128528337","issue_url":"https://api.github.com/repos/jakebolewski/JuliaParser.jl/issues/4","id":128528337,"user":{"login":"davidanthoff","id":1036561,"avatar_url":"https://avatars.githubusercontent.com/u/1036561?v=3","gravatar_id":"","url":"https://api.github.com/users/davidanthoff","html_url":"https://github.com/davidanthoff","followers_url":"https://api.github.com/users/davidanthoff/followers","following_url":"https://api.github.com/users/davidanthoff/following{/other_user}","gists_url":"https://api.github.com/users/davidanthoff/gists{/gist_id}","starred_url":"https://api.github.com/users/davidanthoff/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/davidanthoff/subscriptions","organizations_url":"https://api.github.com/users/davidanthoff/orgs","repos_url":"https://api.github.com/users/davidanthoff/repos","events_url":"https://api.github.com/users/davidanthoff/events{/privacy}","received_events_url":"https://api.github.com/users/davidanthoff/received_events","type":"User","site_admin":false},"created_at":"2015-08-06T22:28:03Z","updated_at":"2015-08-06T22:28:03Z","body":"I recently looked at the C# Roslyn design for this kind of problem. The background here is that MS rewrote their C# compiler into a modular piece of code that could be used both for compiling, but also the full IDE C# support (which is impressive, if you have ever tried VS).\r\n\r\nThe basic philosophy of the project was that they have a parser that creates a syntax tree (very much like expression trees in Julia), but that this syntax tree has to have ALL the info from the original text file so that you can round-trip a full fidelity text file again. So the syntax tree has every single whitespace, comment, everything represented.\r\n\r\nThe design they use is that they have additional syntax trivia data, but this data is attached to either the next or previous \"real\" syntax expression as a child, and not a new expression type that can show up at the same level as a real language construct. The benefit of this is that when you traverse your expression tree, you can VERY easily ignore the trivia syntax by just not looking at these fields of an expression object. I think that design overall is actually better than to have a new comment expression type (or the line expression type that exists already).\r\n\r\nThe design the chose to go back to the location in the source code that corresponds to a syntax element also seems pretty robust, i.e. each element has a span property that gives the precise character position and coverage of that element.\r\n\r\nIn any case, it might be worth taking a look at their design and to think whether some of these ideas would make sense for Julia. The high level doc describing their approach is [here](https://github.com/dotnet/roslyn/wiki/Roslyn%20Overview).\r\n\r\nMaybe a good way to play around with this would be to add a full new type hierarchy that replicates something like the Roslyn stuff to this package here, and have a new ``parse`` function that produces such a tree. This could be used by tools that want to provide some IDE integration and one could play around with performance for now (and if it turns out to work well, it might even be migrated back as the core Julia expression system? But that question is clearly above my pay grade)."}}