IxSet ids management solution

[Nikita Volkov]

I came up with a general solution for management of ids in IxSet. I'd like to get some comments on it and get it considered to be merged into the IxSet project. 

For more details please visit this gist: https://gist.github.com/nikita-volkov/5083268

[dag.od...@gmail.com]

Note that tables [1] and the WIP data-store [2] both provide auto-incrementing fields.  They also fix a number of other issues with ixset.

[1] http://hackage.haskell.org/package/tables
[2] http://palmik.net/data-store/Data-Store.html

On Mon, Mar 4, 2013 at 8:14 PM, Nikita Volkov <nikita....@gmail.com> wrote:

I came up with a general solution for management of ids in IxSet. I'd like to get some comments on it and get it considered to be merged into the IxSet project. 

For more details please visit this gist: https://gist.github.com/nikita-volkov/5083268

--
You received this message because you are subscribed to the Google Groups "HAppS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to happs+un...@googlegroups.com.
To post to this group, send email to ha...@googlegroups.com.
Visit this group at http://groups.google.com/group/happs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jeremy Shaw]

Hello!

Sorry about the delay.

This looks nice. At first I was concerned that there was only a single
Id type -- and so you might accidentally mix up ids from artists and
albums. But looking closer, it seems that you use a phantom type so
that there is only one concrete Id type, but you can still enforce
type-safety to prevent the mixup of Artists and Records?

I am going to try to actually use this for something and see how it
works out. But, so far I really like it. If everything seems kosher
I'll add it to IxSet.

As dag mentioned, we are working on alternatives to IxSet -- but that
doesn't mean IxSet will just go away. Each solution has it's ups and
downs.

thanks!
- jeremy

[Nikita Volkov]

On Mar 7, 2013, at 10:00 PM, Jeremy Shaw <jer...@n-heptane.com> wrote:

> it seems that you use a phantom type so
> that there is only one concrete Id type, but you can still enforce
> type-safety to prevent the mixup of Artists and Records?

Right. That's exactly the point. This also quite elegantly solves the issue of managing unidentified entities: until the entity is associated with a set it can't have a meaningful id-value, so we need a way to express unidentified entities, right? With this approach because entities are freed from the id field, there's no need to awkwardly initialize it with some zero-ish value.

> I am going to try to actually use this for something and see how it
> works out. But, so far I really like it. If everything seems kosher
> I'll add it to IxSet.

All right!

[Jeremy Shaw]

We definitely will not merge it if it depends on classyprelude. We
would like to have a few dependencies as possible. And classyprelude
doesn't really do anything that benefits the end user here.

I've thought about using the nested record approach before. At the
time we did not have fclabels, data-lens, lens, etc, so working with
nested records was a major pain. Now, we have lots of solutions for
working with nested records, but they still leave me .. unexcited.

Here is an incomplete idea I just had, where we have a single, flat record,

http://hpaste.org/84883

It makes the index field polymorphic, so that when you don't have an
index, the type is (), and when you do it is something like, Index
MyRecordIndex.

Functions which do not need the index can just leave the index type
polymorphic and work with Identified or Unidentified records.

This solution could stand to be cleaned up a bit. The SetIndex class
should maybe be merged into the Indexable class or something. And some
of the type signatures seem a bit much. And, of course, it needs all
the associated helper functions.

How do people feel about the two different solutions?

- jeremy


On Mon, Mar 4, 2013 at 1:14 PM, Nikita Volkov <nikita....@gmail.com> wrote:

[Nikita Volkov]

Since it's been taking so long, I've already started developing the proposal as a dedicated package titled "ixset-id". I plan to be maintaining it, so, I guess, for now I call off the suggestion to merge it. It would be nice though if you guys mentioned the package in your docs or tutorials.

I haven't yet made any release to hackage, since I'm still experimenting, but the project's repo is already made public, so you can monitor the progress. It already contains some improvements as compared to what I originally posted in this thread.

Oh, and one more thing. To make the Indexable instances declarations simpler for users of my package I need some way to extract the internals of the Ix type, the "a -> [key]" function specifically, but the current API of IxSet exports no function for that, nor the constructor. Please make a release of IxSet exporting any of those symbols. Here is the code I need it for.

You received this message because you are subscribed to a topic in the Google Groups "HAppS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/happs/l_HbuwE4QhU/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to happs+un...@googlegroups.com.