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(). 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. 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. Cheers, Torben On Thu, Mar 17, 2011 at 21:36, Eric Merritt <[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 > <[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 <[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 > >> <[email protected]> wrote: > >> > > >> > > >> > On Thu, Mar 17, 2011 at 20:19, Eric Merritt <[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 < > [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 > >> >> >> <[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 > >> >> >> > <[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 > >> >> >> >> <[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 > >> >> >> >> > -- > >> >> >> >> > http://www.linkedin.com/in/torbenhoffmann > >> >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > -- > >> >> >> > http://www.linkedin.com/in/torbenhoffmann > >> >> >> > > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > http://www.linkedin.com/in/torbenhoffmann > >> >> > > >> > > >> > > >> > > >> > -- > >> > http://www.linkedin.com/in/torbenhoffmann > >> > > > > > > > > > -- > > http://www.linkedin.com/in/torbenhoffmann > > > -- 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.
