Torben, Just as an FYI the patches in my types branch are not super clean as yet. When we get a complete implementation I will refactor the patches before we push them to canonical.
Eric On Fri, Mar 18, 2011 at 4:06 PM, Torben Hoffmann <[email protected]> wrote: > 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.
