Update datadecl branch #161

Closed
opened 2018-07-10 06:54:04 +02:00 by eborden · 9 comments
eborden commented 2018-07-10 06:54:04 +02:00 (Migrated from github.com)

I have rebased and fixed up the datadecl branch from the latest brittany master.

https://github.com/eborden/brittany/tree/datadecl

The rebase however makes opening a PR for this branch extremely noisy. I'm not sure how you'd like to proceed with merging it.

I have rebased and fixed up the datadecl branch from the latest `brittany` master. https://github.com/eborden/brittany/tree/datadecl The rebase however makes opening a PR for this branch extremely noisy. I'm not sure how you'd like to proceed with merging it.
lspitzner commented 2018-07-16 01:03:04 +02:00 (Migrated from github.com)

that's fine, i can pull the change without using github. will have a look later.

that's fine, i can pull the change without using github. will have a look later.
lspitzner commented 2018-07-16 01:04:24 +02:00 (Migrated from github.com)

(the github PR interface of course, i still fetch from github..)

(the github PR interface of course, i still fetch from github..)
lspitzner commented 2018-07-16 23:09:30 +02:00 (Migrated from github.com)

done. do you have an overview which data-decl aspects are finished? I assume GADTs are missing, and perhaps multiple-constructor records?

might be feasible/sensible to gradually add support. pattern-match/guard any things we don't support and use exactprint for those.

done. do you have an overview which data-decl aspects are finished? I assume GADTs are missing, and perhaps multiple-constructor records? might be feasible/sensible to gradually add support. pattern-match/guard any things we don't support and use exactprint for those.
eborden commented 2018-07-17 02:49:36 +02:00 (Migrated from github.com)

There is very little that is currently supported, just a simple implementation of records with multiple deriving clauses. I haven't had a chance to spend any more time on this, just trying to keep it up to date so I or someone else could possibly come back to it.

Current tests are:

#test single record
data Foo = Bar { foo :: Baz }

#test record multiple names
data Foo = Bar { foo, bar :: Baz }

#test record multiple types
data Foo = Bar
  { foo  :: Baz
  , bars :: Bizzz
  }

#test record multiple types and names
data Foo = Bar
  { foo, biz :: Baz
  , bar      :: Bizzz
  }

#test record multiple types deriving
data Foo = Bar
  { fooz :: Baz
  , bar  :: Bizzz
  }
  deriving Show

#test record multiple types deriving
data Foo = Bar
  { foo  :: Baz
  , bars :: Bizzz
  }
  deriving (Show, Eq, Monad, Functor, Traversable, Foldable)

#test record multiple deriving strategies
data Foo = Bar
  { foo  :: Baz
  , bars :: Bizzz
  }
  deriving Show
  deriving anyclass (Show, Eq, Monad, Functor)
  deriving newtype (Traversable, Foldable)

It is probably worth defining milestones in this project and determining where are seams are for shipping incremental improvements. Otherwise the monolith will never move.

There is very little that is currently supported, just a simple implementation of records with multiple `deriving` clauses. I haven't had a chance to spend any more time on this, just trying to keep it up to date so I or someone else could possibly come back to it. Current tests are: ``` #test single record data Foo = Bar { foo :: Baz } #test record multiple names data Foo = Bar { foo, bar :: Baz } #test record multiple types data Foo = Bar { foo :: Baz , bars :: Bizzz } #test record multiple types and names data Foo = Bar { foo, biz :: Baz , bar :: Bizzz } #test record multiple types deriving data Foo = Bar { fooz :: Baz , bar :: Bizzz } deriving Show #test record multiple types deriving data Foo = Bar { foo :: Baz , bars :: Bizzz } deriving (Show, Eq, Monad, Functor, Traversable, Foldable) #test record multiple deriving strategies data Foo = Bar { foo :: Baz , bars :: Bizzz } deriving Show deriving anyclass (Show, Eq, Monad, Functor) deriving newtype (Traversable, Foldable) ``` It is probably worth defining milestones in this project and determining where are seams are for shipping incremental improvements. Otherwise the monolith will never move.
tfausak commented 2019-06-18 04:23:24 +02:00 (Migrated from github.com)

I would be very happy to get these changes merged into master and released, even if they only represent a subset for formatting data declarations.

https://github.com/lspitzner/brittany/compare/master...lspitzner:datadecl

Edit: Also somehow this issue isn't connected to #47 yet.

I would be very happy to get these changes merged into master and released, even if they only represent a subset for formatting data declarations. https://github.com/lspitzner/brittany/compare/master...lspitzner:datadecl Edit: Also somehow this issue isn't connected to #47 yet.
expipiplus1 commented 2020-02-26 07:58:30 +01:00 (Migrated from github.com)

Is it possible to look at getting this merged before it bitrots again (hopefully it's not too late).

Is it possible to look at getting this merged before it bitrots again (hopefully it's not too late).
lspitzner commented 2020-02-26 11:26:59 +01:00 (Migrated from github.com)

172866755cc43b49ad82521b6b2917bf08016173..00c6854887f3de22f5e036f652d6f16748a78be4 got merged in 434854f8f3. Those were rebased commits of the previous datadecl branch. Afaik, any existing data-decl work is on master by now.

This does not mean that all datadecls are formatted yet - I think we have not approached the multiple-constructor case. And there might be something unfortunate happening with GADTs atm, but I have not looked into it yet.

I'll close this. Let's use #47 to discuss the remaining items.

172866755cc43b49ad82521b6b2917bf08016173..00c6854887f3de22f5e036f652d6f16748a78be4 got merged in 434854f8f365c625a49604f9b1905cbe488acbb0. Those were rebased commits of the previous datadecl branch. Afaik, any existing data-decl work is on master by now. This does not mean that all datadecls are formatted yet - I think we have not approached the multiple-constructor case. And there might be something unfortunate happening with GADTs atm, but I have not looked into it yet. I'll close this. Let's use #47 to discuss the remaining items.
expipiplus1 commented 2020-02-26 15:45:03 +01:00 (Migrated from github.com)

Thanks! I must have been using some ancient version.

Thanks! I must have been using some ancient version.
andys8 commented 2020-02-28 16:58:43 +01:00 (Migrated from github.com)

Awesome to see there is progress and the next release might include the feature :)

Awesome to see there is progress and the next release might include the feature :)
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: hexagoxel/brittany#161
There is no content yet.