ekmett / pointed

pointed and copointed data
Other
23 stars 9 forks source link

data-default 0.3 is also fine #2

Closed loisch closed 13 years ago

loisch commented 13 years ago

Hi Edward,

just noticed, that pointed doesn't build against the latest data-default release. It compiles using the newer version so I guess it's fine.

Cheers, David

ekmett commented 13 years ago

Merged

On Wed, Sep 28, 2011 at 10:35 AM, David Leuschner < reply@reply.github.com>wrote:

Hi Edward,

just noticed, that pointed doesn't build against the latest data-default release. It compiles using the newer version so I guess it's fine.

Cheers, David

You can merge this Pull Request by running:

git pull https://github.com/loisch/pointed patch-1

Or you can view, comment on it, or merge it online at:

https://github.com/ekmett/pointed/pull/2

-- Commit Summary --

  • data-default 0.3 is also fine

-- File Changes --

M pointed.cabal (2)

-- Patch Links --

https://github.com/ekmett/pointed/pull/2.patch https://github.com/ekmett/pointed/pull/2.diff

Reply to this email directly or view it on GitHub: https://github.com/ekmett/pointed/pull/2

loisch commented 13 years ago

Hi Edward,

thanks!

I just installed "pointed" because Gregory Collins "pointed" me to it on Google+ (https://plus.google.com/101263901515972760463/posts). I just need the Pointed class and the instance for Data.Set and it has so many dependencies. You already split "category-extras" in many packages but it would be really nice to have a "pointed" package with just "base" and "containers" as dependencies and another package for all the instances (and all the dependencies to transformers, semigroupoids, etc.).

Cheers,

David

David Leuschner Geschäftsführung

factis research GmbH Merzhauser Straße 177 / 79100 Freiburg i.Br. Tel.: +49 (0)761 8 96 45 - 75 Fax: +49 (0)761 8 96 45 - 69

Geschäftsführung: Dr. Harald Fischer, David Leuschner Handelsregister: Amtsgericht Freiburg HRB 704694

ekmett commented 13 years ago

On Wed, Sep 28, 2011 at 11:22 AM, David Leuschner < reply@reply.github.com>wrote:

Hi Edward,

thanks!

I just installed "pointed" because Gregory Collins "pointed" me to it on Google+ (https://plus.google.com/101263901515972760463/posts). I just need the Pointed class and the instance for Data.Set and it has so many dependencies. You already split "category-extras" in many packages but it would be really nice to have a "pointed" package with just "base" and "containers" as dependencies and another package for all the instances (and all the dependencies to transformers, semigroupoids, etc.).

I understand and appreciate your position. However, this is unfortunately impossible without orphaning a large number of instances for more useful classes.

I have a very simple choice to make with Pointed as it was released after many other packages. I can either

1.) make all of the packages that I own depend on Pointed

2.) I can make Pointed depend on all of those packages

3.) I can accept orphan instances

The thing you overlook in the huge breakout of category-extras is that I did so without introducing any orphans!

Orphan instances are very bad. Since orphan instances lead to lack of confluence and can seriously break packages, 3 isn't a tenable solution for me.

On the other hand, there arises a question of which is the more fundamental concept, Pointed or a class like Apply. Pointed admits no laws that aren't already a free theorem and consequently there are really no interesting combinators that one can write using just Pointed.

The work with semigroups and semigroupoids has shown me that instead of taking a random point and then adding a binary operation it is better in practice to take a binary associative operation and add a point. In this sense Apply is extended with pure to yield Applicative. Moreover there ARE a very large number of combinators that can be written with just that associative law, witness the content of the semigroups and semigroupoids packages compared to the contents of Pointed.

So, I have to choose layering Pointed underneath or over semigroups, and their ilk, and for better or worse it wound up on top of the onion. Arguably I could have made pointed have a smaller dependency set and inverted all but some small fragment of core packages in the breakout of category extras, but then I have to rewrite the better part of 30 packages.

In my experience since I began working on semigroups and the other classes, whenever you are using Pointed you are often leaning on some kind of other law that Pointed doesn't let you express. By way of example, Pointed doesn't tell you that you can use mappend or (<>) to glue together the singleton sets you build with it for instance. So you are relying on an implementation detail and your code even though littered with generic classes is still intrinsically limited to the particular data type you have in mind.

-Edward

loisch commented 13 years ago

Hi Edward,

first of all thank you for taking so much time explaining the rationale behind your decision. I appreciate your work for the Haskell community very much and hope to get to know and use more of your packages!

You already split "category-extras" in many packages but it would be really nice to have a "pointed" package with just "base" and "containers" as dependencies and another package for all the instances (and all the dependencies to transformers, semigroupoids, etc.).

I understand and appreciate your position. However, this is unfortunately impossible without orphaning a large number of instances for more useful classes.

I have a very simple choice to make with Pointed as it was released after many other packages. I can either

1.) make all of the packages that I own depend on Pointed

2.) I can make Pointed depend on all of those packages

3.) I can accept orphan instances

The thing you overlook in the huge breakout of category-extras is that I did so without introducing any orphans!

Orphan instances are very bad. Since orphan instances lead to lack of confluence and can seriously break packages, 3 isn't a tenable solution for me.

You're right, I didn't think enough about how bad orphan instances are. It's a pity there's no way to explicitly import or hide instances. I assume a fundamental type system issue is the reason why it's not possible.

On the other hand, there arises a question of which is the more fundamental concept, Pointed or a class like Apply. Pointed admits no laws that aren't already a free theorem and consequently there are really no interesting combinators that one can write using just Pointed.

...

In my experience since I began working on semigroups and the other classes, whenever you are using Pointed you are often leaning on some kind of other law that Pointed doesn't let you express. By way of example, Pointed doesn't tell you that you can use mappend or (<>) to glue together the singleton sets you build with it for instance. So you are relying on an implementation detail and your code even though littered with generic classes is still intrinsically limited to the particular data type you have in mind.

I am using

findStuff :: (Pointed f, Monoid (f SomeItem)) => SomeData -> f SomeItem

to build Sets and DLists (I need generlized versions of the Set.singleton, Set.empty and Set.union or DList.singleton, DList.empty and DList.append funtions). For this use I only need "Pointed" (in addition to the standard Monoid). But to be honest I don't understand how to use most of the stuff from your other packages and maybe I should be better using something Pointed together with some other class of yours.

Although I studied computer and don't have a good understanding of what many algebraic/categorical concepts really mean, so I don't realize that the java.util.Container I'm looking for is actually "Pointed" together with "Monoid". The concepts in Haskell are much more abstract (which is good!) and maybe it would also help others if there was a catelogue saying "if you think you need something like java.util.Container you're probably looking for these concepts or those concepts".

Thanks again for your work and your explanation. I'll try to get a deeper unstanding of all these concepts!

Cheers,

David

David Leuschner Geschäftsführung

factis research GmbH Merzhauser Straße 177 / 79100 Freiburg i.Br. Tel.: +49 (0)761 8 96 45 - 75 Fax: +49 (0)761 8 96 45 - 69

Geschäftsführung: Dr. Harald Fischer, David Leuschner Handelsregister: Amtsgericht Freiburg HRB 704694

ekmett commented 13 years ago

Sent from my iPhone

On Sep 29, 2011, at 5:54 AM, David Leuschnerreply@reply.github.com wrote:

Hi Edward,

first of all thank you for taking so much time explaining the rationale behind your decision. I appreciate your work for the Haskell community very much and hope to get to know and use more of your packages!

I'm happy to help. :)

You already split "category-extras" in many packages but it would be really nice to have a "pointed" package with just "base" and "containers" as dependencies and another package for all the instances (and all the dependencies to transformers, semigroupoids, etc.).

I understand and appreciate your position. However, this is unfortunately impossible without orphaning a large number of instances for more useful classes.

I have a very simple choice to make with Pointed as it was released after many other packages. I can either

1.) make all of the packages that I own depend on Pointed

2.) I can make Pointed depend on all of those packages

3.) I can accept orphan instances

The thing you overlook in the huge breakout of category-extras is that I did so without introducing any orphans!

Orphan instances are very bad. Since orphan instances lead to lack of confluence and can seriously break packages, 3 isn't a tenable solution for me.

You're right, I didn't think enough about how bad orphan instances are. It's a pity there's no way to explicitly import or hide instances. I assume a fundamental type system issue is the reason why it's not possible.

Hiding instances or allowing local instances can lead to lack of confluence. This means that if you have two sets of Ints you can't know which order was used to construct each as you can't know the Ord instance for Int is unique. This leads to a whole lot of incorrect but mostly working code.

On the other hand, there arises a question of which is the more fundamental concept, Pointed or a class like Apply. Pointed admits no laws that aren't already a free theorem and consequently there are really no interesting combinators that one can write using just Pointed.

...

In my experience since I began working on semigroups and the other classes, whenever you are using Pointed you are often leaning on some kind of other law that Pointed doesn't let you express. By way of example, Pointed doesn't tell you that you can use mappend or (<>) to glue together the singleton sets you build with it for instance. So you are relying on an implementation detail and your code even though littered with generic classes is still intrinsically limited to the particular data type you have in mind.

I am using

findStuff :: (Pointed f, Monoid (f SomeItem)) => SomeData -> f SomeItem

to build Sets and DLists (I need generlized versions of the Set.singleton, Set.empty and Set.union or DList.singleton, DList.empty and DList.append funtions). For this use I only need "Pointed" (in addition to the standard Monoid). But to be honest I don't understand how to use most of the stuff from your other packages and maybe I should be better using something Pointed together with some other class of yours.

As I mentioned above there is no law connecting the point with mappend, so the semantics of the function you gave have to be reasoned about instance by instance. The concept you are looking for is a Reducer, from the reducers package.

findStuff :: (SomeItem s, Monoid s) => SomeData -> s

<> or mappend is your mappend, unit is your point, and snoc and cons give efficient left or right single value appends

and this way if SomeItem is Int you can use a more efficient IntSet for instance, which cannot be Pointed, and moreover you don't have to guess or reason about things casewise.

Although I studied computer and don't have a good understanding of what many algebraic/categorical concepts really mean, so I don't realize that the java.util.Container I'm looking for is actually "Pointed" together with "Monoid". The concepts in Haskell are much more abstract (which is good!) and maybe it would also help others if there was a catelogue saying "if you think you need something like java.util.Container you're probably looking for these concepts or those concepts".

Thanks again for your work and your explanation. I'll try to get a deeper unstanding of all these concepts!

Cheers,

David

David Leuschner Geschäftsführung

factis research GmbH Merzhauser Straße 177 / 79100 Freiburg i.Br. Tel.: +49 (0)761 8 96 45 - 75 Fax: +49 (0)761 8 96 45 - 69

Geschäftsführung: Dr. Harald Fischer, David Leuschner Handelsregister: Amtsgericht Freiburg HRB 704694

Reply to this email directly or view it on GitHub: https://github.com/ekmett/pointed/pull/2#issuecomment-2236127