Skip to content
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

Data declarations #4

Open
superbobry opened this issue Aug 19, 2013 · 3 comments
Open

Data declarations #4

superbobry opened this issue Aug 19, 2013 · 3 comments

Comments

@superbobry
Copy link

Following haskell-style-guide data declarations should be indented as follows:

  1. Basic case:

    data Tree a = Branch !a !(Tree a) !(Tree a)
                  | Leaf
  2. Constructors with long names:

    data HttpException
        = InvalidStatusCode Int
        | MissingContentHeader
  3. Records

    data Person = Person
        { firstName :: !String  -- ^ First name
        , lastName  :: !String  -- ^ Last name
        , age       :: !Int     -- ^ Age
        } deriving (Eq, Show)

The current implementations handles the first two cases correctly, the problem is with record indentation:

data Person = Person
              { firstName :: !String  -- ^ First name
              , lastName  :: !String  -- ^ Last name
              , age       :: !Int     -- ^ Age
              } deriving (Eq, Show)      
@errge
Copy link
Member

errge commented Aug 19, 2013

Yes, I agree with this. For now if you put the constructor name in a newline, then it works correctly.

I've made a no in the parser todos section in the code about this.

@kuribas
Copy link

kuribas commented Aug 19, 2013

I'll look at this. May I suggest to keep issues in git, not to clutter the files? Documentation in the source is fine, and TODO list also, but debatable items or bugs can be handled more conveniently in git.

@errge
Copy link
Member

errge commented Aug 19, 2013

Yes, I'm happy if we use github for discussion. I moved these bugs into the code as TODO items, because I'm almost sure that I want to implement them at some point, so it makes sense to have them here. It's much more easier to hack on a git repository locally, then click around in a browser.

For example, I haven't written anything in the code about the bug report that suggested to run a ghc process just to do indentation and communicate with it to do indentation. I don't think we will implement that soon, so no point in having it in the code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants