-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactored erl_prettypr.erl #4570
base: master
Are you sure you want to change the base?
Conversation
…es; Remove cond expr
@elbrujohalcon, this might interest you. |
fun erl_syntax:user_type_application_arguments/1); | ||
attribute -> | ||
Name = erl_syntax:attribute_name(Node), | ||
case catch erl_syntax:concrete(Name) of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this can be simplified a bit to both avoid an unnecessary catch
and make it clear what kind of node are allowed as the attribute name, i.e. an atom node.
case catch erl_syntax:concrete(Name) of | |
case erl_syntax:atom_value(Name) of |
spec -> | ||
[SpecTuple] = erl_syntax:attribute_arguments(Node), | ||
[FuncName, FuncTypes] = erl_syntax:tuple_elements(SpecTuple), | ||
Clauses = erl_syntax:concrete(FuncTypes), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the trick with concrete
/abstract
here. Very nice 😄
I was bold enough to start a pet-project refactoring the
erl_prettypr.erl
module. This has been a long-time coming and I still consider it Work-In-Progress. Never-the-less, I thought I'd share the current state to see if there's interest in this work.I plan to:
Further-more:
hook
, these functions would be specific for each Tree-type.I'm aware that there have been attempts to "fix-up" this module and those attempts ended-up in separate stand-alone projects. Despite of that I think there still is a value in improving the code-formatter shipped with Erlang/OTP, as it may be used by other internal libraries.
I've decided to simplify the module before attempting to expand on the Layout-Configurability. So, I consider this PR as stage-1 to be honest towards the end-goal: "Make the layout configurable." - Solving the leading-comma formatting would be a good driving principle for configurabilty.
There are a lot of similarities between Erlang statements, like case-clauses and function-clauses, or between data-structure like lists, tuples and binaries, so I've tried to collapse these cases into one, so that they have the same layout.
The produced code-layout relies only on what's possible with the
prettypr
. Only the 4 different layouts:sep/1
,par/1
,above/2
andbeside/2
are used. These are surprisingly versatile and I've found thefloat
layout nondeterministic (don't really understand how it supposed to work).With this PR a simple, sensible layout is produced for those who just want it to work without any configuration.