The problem is that any AST can be intercepted by macros before it reaches the compiler. For example, you could easily have a macro that can be used like:
my_macro @type t :: other_type And that rewrites the @type annotation to something completely different. Changing other_type to other_type() would change what AST the my_macro receives and it has potential to break code. That's why one of the core principles of the formatter is to never change the AST. Perhaps there should be a way to allow formatter some of those "unsafe" transformations, but I think this is somewhat a separate discussion. Michał. On 5 Feb 2018, 16:15 +0100, Vincent Siliakus <[email protected]>, wrote: > I understand the reason that parenthesis can't be added to nullary local > functions and that if you walk the AST without keeping any state the > formatter can't discern a local type from a local nullary function call. > > However, when the formatter does keep some state while walking the tree it > should be possible for the formatter to understand which AST nodes are part > of a typespec? > > Given the following typespec: > > @type my_type :: my_other_type > > The corresponding AST should be something like: > > {:@, [line: 1], > [ > {:type, [line: 1], > [ > {:::, [line: 1], > [{:my_type, [line: 1], nil}, {:my_other_type, [line: 1], nil}]} > ]} > ]} > > So the formatter encounters an attribute node {:@, ...}, updates it state > that if the next node starts with :type, we are at the start of a typespec, > etc. > > Is interpreting the AST like this considered too fragile/brittle, or am I > missing something else? > > Best, > Vincent > > Op maandag 5 februari 2018 15:10:05 UTC+1 schreef Eric Meadows-Jönsson: > > Typespecs are following the same rules as all other code because the > > formatter only sees AST and can't discern typespecs from executed code. > > > > We can't add parenthesis to nullary local function calls because they have > > the same AST representation as variables so adding parenthesis would break > > code. > > > > > > -- > > Eric Meadows-Jönsson > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/f1efdaf8-c8b8-4197-b1f2-622bd5b2190e%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/a8e62890-bb5b-41cc-89f9-8623f27d655e%40Spark. For more options, visit https://groups.google.com/d/optout.
