Hi Eric, I have pushed a simplified version of ec_dictionary to https://github.com/lehoff/erlware_commons
I have taken the liberty to change some of the names for the parameters, but I am not sure my names for those or for the internal data structure is optimal, so please give me a hint on that one. I have avoided using ec_implements for now in order to keep things simple. Cheers, Torben On Fri, Mar 18, 2011 at 15:30, Eric Merritt <[email protected]> wrote: > On Fri, Mar 18, 2011 at 10:59:50AM +0100, Torben Hoffmann wrote: > > One of my pet peeves came to bite me this morning... with any data > > structure make sure that it works with fold* et al. > > > > For ec_dictionary this means swapping the arguments for remove/2 > > -spec remove(key(),dictionary()) -> dictionary(). > > That makes very good sense to me. I would like to be consisant on the > argument ordering though. > > > > > Then you can do lists:foldl(fun ec_dictionary:remove/2, InitialDict, > List) > > which is so nice compared to throwing in an anonymous function that > does > > nothing but swap the arguments... > > > > And for the rest of the functions the current style in dict, gb_trees > is > > to have > > -spec insert(key(),value(),data_structure()) -> data_structure(). > > > > whereas ec_dictionary wants the data_structure first: > > -spec add(dictionary(),key(),value()) -> dictionary(). > > > > I think the ec_dictionary style is on the wrong route - we do not want > to > > make it that different from the existing implementation. > > Lets change it. Matching the existing ordering that people expect is a > very good thing. > > > > Our goal should be to harmonise and remove the small differences there > is > > between the APIs today - not to create a totally new API with new > order of > > arguments. > > A fully agree on all counts. That was a good catch on your part. > > Which branch are your patches on so I can pick them? > > > > > Cheers, > > Torben > > > > On Thu, Mar 17, 2011 at 21:36, Eric Merritt <[1] > [email protected]> > > wrote: > > > > Ok, that works fine. When we get something lets sync back up so we > > know we are going in the same direction. > > > > On Thu, Mar 17, 2011 at 3:34 PM, Torben Hoffmann > > <[2][email protected]> wrote: > > > Leave the dict implementation to me - I need something to work out > the > > > properties with. > > > > > > On Thu, Mar 17, 2011 at 21:32, Eric Merritt > > <[3][email protected]> wrote: > > >> > > >> I will get this backed out and the behaviours implemented against > > >> ec_dictionary for gb_tress and dict while you work on the PropEr > > >> stuff. Then in a day or two we can try running them against each > > >> other. How does that sound? > > >> > > >> On Thu, Mar 17, 2011 at 3:26 PM, Torben Hoffmann > > >> <[4][email protected]> wrote: > > >> > > > >> > > > >> > On Thu, Mar 17, 2011 at 20:19, Eric Merritt > > <[5][email protected]> > > >> > wrote: > > >> >> > > >> >> > > > >> >> > The behaviour should be just the behaviour_info/1 function > for > > the > > >> >> > time > > >> >> > being. > > >> >> > > > >> >> > We use the specs in ec_dictionary as our guiding light for > the > > >> >> > implementation of the functions - simplified a bit to match > the > > >> >> > simple > > >> >> > starting implementation. > > >> >> > > > >> >> > I suggest that we use a record defined in ec_dictionary.hrl > for > > the > > >> >> > common > > >> >> > data structure between the different implementations. > > >> >> > > > >> >> > -record(dict_data, { mod, data }). > > >> >> > > > >> >> > Where mod is the module implementing the ec_dictionary > behaviour > > and > > >> >> > data is > > >> >> > the current value. > > >> >> > With the record it will be easier to extend the functions > later > > on. > > >> >> > > >> >> I am assuming that this will eventually be used by the > abstraction > > >> >> layer. Is there any reason for us to expose this to the > > >> >> implementations? I can't think of a good reason for the > > >> >> implementations to have knowledge of the abstractions > structures > > (I > > >> >> hope that makes sense). > > >> > > > >> > You are right - I just want to build the layers of abstraction > > >> > gradually. > > >> > When we are ready it will go away from the implementing > modules. > > >> > > > >> >> > > >> >> > I am okay with cloning your repo, but wouldn't it be just as > > easy (or > > >> >> > easier) to make the current repo writable by me and work on > > separate > > >> >> > branches? > > >> >> > > >> >> I would rather work between us until we got something > publishable, > > >> >> pulling from peer repos is the same as pulling from a central > repo > > in > > >> >> git ;). However, I am more then happy to open up the canonical > if > > you > > >> >> would like. > > >> > > > >> > Point taken - I will clone and then we take it from there. > > >> > > > >> > Cheers, > > >> > Torben > > >> > > > >> >> > > >> >> > > > >> >> > I will start looking into how PropEr works - I am sure there > are > > some > > >> >> > subtle > > >> >> > differences from QuickCheck that needs a loving hand before > I > > can get > > >> >> > it > > >> >> > rolling... > > >> >> > > >> >> Sweet, When I get the chance I will back out the current > > abstraction > > >> >> implementation until we are ready for that. > > >> >> > > >> >> > Cheers, > > >> >> > Torben > > >> >> > > > >> >> > On Thu, Mar 17, 2011 at 16:30, Eric Merritt > > <[6][email protected]> > > >> >> > wrote: > > >> >> >> > > >> >> >> I am moving this back to the dev list. I suspect it might > be > > >> >> >> interesting and useful for those folks. > > >> >> >> > > >> >> >> On Thu, Mar 17, 2011 at 3:47 AM, Torben Hoffmann > > >> >> >> <[7][email protected]> wrote: > > >> >> >> > Didn't get much done yesterday - my knee was hurting > after my > > >> >> >> > operation > > >> >> >> > on > > >> >> >> > it last Thursday. > > >> >> >> > > >> >> >> No worries, we aren't on a time line here and this is > something > > I > > >> >> >> would like to get right. > > >> >> >> > > >> >> >> > But I did get around to looking at some of your code, so > I > > have a > > >> >> >> > few > > >> >> >> > questions/observations. > > >> >> >> > > >> >> >> Sweet, this is what I really wanted. > > >> >> >> > > >> >> >> > > > >> >> >> > ec_implements puzzles me a bit. Unless I am misreading > things > > it > > >> >> >> > has > > >> >> >> > a > > >> >> >> > big > > >> >> >> > overlap with how behaviours work in Erlang and I think it > > would be > > >> >> >> > better to > > >> >> >> > create a proper behaviour and avoid creating functions > like > > >> >> >> > has_all_callbacks/2. > > >> >> >> > > >> >> >> I agree, thats why I created ec_dictionary. I expect things > to > > be > > >> >> >> based around behaviours. The main reason the check > functions > > are > > >> >> >> there > > >> >> >> is just to give the callee the ability to verify that a > module > > >> >> >> implements a behaviour at runtime. This is just an optional > > >> >> >> verification step. I suspect this is over-engineering on my > > part, > > >> >> >> any > > >> >> >> time you implement something for other to use that you > don't > > use > > >> >> >> yourself its a bad smell. I do wish that Erlang had a > simple > > call to > > >> >> >> see if a module implemented a behaviour. > > >> >> >> > > >> >> >> > Since you are aiming at making ec_dictionary the > behaviour > > then > > >> >> >> > you > > >> >> >> > get > > >> >> >> > the > > >> >> >> > has_all_callbacks/2 functionality for free when you put > > >> >> >> > -behaviour(ec_dictonary) into the implementing module. > > >> >> >> > > >> >> >> This is true an compile time of the implementor, but on the > > 'user' > > >> >> >> side there is no guarantee that the thing being passed to > you > > >> >> >> implements that behaviour. We can probably drop that > > functionality > > >> >> >> though. The errors if that is the case should be pretty > > obvious. > > >> >> >> > > >> >> >> > ec_assoc_list doesn't really leverage the behaviour code, > > which is > > >> >> >> > fine > > >> >> >> > for > > >> >> >> > a first stab at it, but I think a more iterative approach > to > > the > > >> >> >> > creation of > > >> >> >> > this library will keep us saner compared to go for the > big > > thing > > >> >> >> > in > > >> >> >> > the > > >> >> >> > first iteration. > > >> >> >> > > >> >> >> It existed mostly as a quick example I could through > together. > > N > > >> >> >> > > >> >> >> > > > >> >> >> > I would suggest that we start with a simplified > ec_dictionary > > >> >> >> > behaviour > > >> >> >> > that > > >> >> >> > merely defines the behaviour_info/1 function. > > >> >> >> > Then we implement two different dictionary > implementations, > > say > > >> >> >> > lists > > >> >> >> > and > > >> >> >> > orddict, plus a temporary module to instantiate them. > This > > without > > >> >> >> > the > > >> >> >> > abstract type info for starters. > > >> >> >> > > >> >> >> That seems reasonable to me. If nothing else it validates > the > > >> >> >> interface for dictionary we come up with. > > >> >> >> > > >> >> >> > > > >> >> >> > Then we create a PropEr specification of how a dictionary > > should > > >> >> >> > behave > > >> >> >> > and > > >> >> >> > test the hell out of our pathetic code! > > >> >> >> > > >> >> >> That sounds like a damn good idea to me. Once we get things > > along > > >> >> >> and > > >> >> >> I understand PropEr I may add support for it in sinan, > depends > > on > > >> >> >> how > > >> >> >> useful it would be. > > >> >> >> > > >> >> >> > > > >> >> >> > When that is in place we start working on putting real > code > > into > > >> >> >> > the > > >> >> >> > behaviour and continuously re-run our specification after > > each > > >> >> >> > little > > >> >> >> > change. > > >> >> >> > > > >> >> >> > Then we can re-introduce the abstract typing and then we > > should be > > >> >> >> > done. > > >> >> >> > > >> >> >> Except then we get to do the same thing for sets and a > handful > > of > > >> >> >> other types. ;) > > >> >> >> > > >> >> >> > > > >> >> >> > It might be a bit of a detour compared to the code base > you > > have > > >> >> >> > put > > >> >> >> > in > > >> >> >> > place, but I think that it will be easier for us to get a > > good > > >> >> >> > PropEr > > >> >> >> > specification that works by working on simple > implementations > > >> >> >> > before > > >> >> >> > we > > >> >> >> > start throwing in the behaviour code. It might be that we > > should > > >> >> >> > focus > > >> >> >> > on > > >> >> >> > one dictionary implementation first and get a > specification > > that > > >> >> >> > works > > >> >> >> > before we start adding another implementation. > > >> >> >> > > > >> >> >> > I am a total chicken when it comes to these things, which > is > > why I > > >> >> >> > like > > >> >> >> > to > > >> >> >> > get a functional base in place very early and then > improve it > > >> >> >> > along > > >> >> >> > the > > >> >> >> > way. > > >> >> >> > Especially with so many things on the table as we have > here. > > >> >> >> > > > >> >> >> > Does this sound reasonable to you? > > >> >> >> > > >> >> >> It does. To get concrete. Lets start by defining the > behaviour > > and > > >> >> >> the > > >> >> >> PropEr spec then wrap gb_trees and dicts as or first set up > > >> >> >> implementations. Assuming we did everything right both of > our > > >> >> >> implementations should pass the PropEr spec. I like this > > approach > > >> >> >> for > > >> >> >> types in any case. > > >> >> >> > > >> >> >> What do you think? > > >> >> >> > > >> >> >> > > > >> >> >> > If so I suggest we create a temporary github repo for the > > code and > > >> >> >> > work > > >> >> >> > it > > >> >> >> > from there. > > >> >> >> > > >> >> >> I don't see a whole lot of need to create a new repo. Just > > clone > > >> >> >> commons and we can easily work between us there. When we > have > > it > > >> >> >> worked out we can move it up to canonical pretty trivially. > > >> >> >> > > >> >> >> > Cheers, > > >> >> >> > Torben > > >> >> >> > > > >> >> >> > On Wed, Mar 16, 2011 at 14:38, Eric Merritt > > >> >> >> > <[8][email protected]> > > >> >> >> > wrote: > > >> >> >> >> > > >> >> >> >> Sweet man. Thats great news. I am *very* interested in > your > > >> >> >> >> opinion > > >> >> >> >> of the code I sent out last night and I am very > interested > > in > > >> >> >> >> learning > > >> >> >> >> PropEr as well. > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> On Wed, Mar 16, 2011 at 4:00 AM, Torben Hoffmann > > >> >> >> >> <[9][email protected]> wrote: > > >> >> >> >> > Hi Eric, > > >> >> >> >> > > > >> >> >> >> > I was trying to set up PropEr last night on my home > > machine, > > >> >> >> >> > but > > >> >> >> >> > since > > >> >> >> >> > PropEr is based on rebar I had to go through a massive > > update > > >> >> >> >> > of > > >> >> >> >> > my > > >> >> >> >> > tool > > >> >> >> >> > chain. And I was behind on erlware so I ended up > spending > > the > > >> >> >> >> > entire > > >> >> >> >> > night > > >> >> >> >> > upgrading. > > >> >> >> >> > > > >> >> >> >> > I will get on with the code tonight! > > >> >> >> >> > > > >> >> >> >> > Cheers, > > >> >> >> >> > Torben > > >> >> >> >> > -- > > >> >> >> >> > [10]http://www.linkedin.com/in/torbenhoffmann > > >> >> >> >> > > > >> >> >> > > > >> >> >> > > > >> >> >> > > > >> >> >> > -- > > >> >> >> > [11]http://www.linkedin.com/in/torbenhoffmann > > >> >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > -- > > >> >> > [12]http://www.linkedin.com/in/torbenhoffmann > > >> >> > > > >> > > > >> > > > >> > > > >> > -- > > >> > [13]http://www.linkedin.com/in/torbenhoffmann > > >> > > > > > > > > > > > > > -- > > > [14]http://www.linkedin.com/in/torbenhoffmann > > > > > > > -- > > [15]http://www.linkedin.com/in/torbenhoffmann > > > > References > > > > Visible links > > 1. mailto:[email protected] > > 2. mailto:[email protected] > > 3. mailto:[email protected] > > 4. mailto:[email protected] > > 5. mailto:[email protected] > > 6. mailto:[email protected] > > 7. mailto:[email protected] > > 8. mailto:[email protected] > > 9. mailto:[email protected] > > 10. http://www.linkedin.com/in/torbenhoffmann > > 11. http://www.linkedin.com/in/torbenhoffmann > > 12. http://www.linkedin.com/in/torbenhoffmann > > 13. http://www.linkedin.com/in/torbenhoffmann > > 14. http://www.linkedin.com/in/torbenhoffmann > > 15. http://www.linkedin.com/in/torbenhoffmann > > -- > Eric Merritt > Erlang & OTP in Action (Manning) http://manning.com/logan > http://twitter.com/ericbmerritt > http://erlware.org > -- http://www.linkedin.com/in/torbenhoffmann -- You received this message because you are subscribed to the Google Groups "erlware-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/erlware-dev?hl=en.
