On Sun, Apr 5, 2009 at 4:53 PM, Eric Kow <[email protected]> wrote: > Hi, > > On Sat, Mar 28, 2009 at 14:29:21 -0700, Jason Dagit wrote: >> My proposal to (c) is that we don't turn on the type witness checking >> until near the end. We use the philosophy that until the type checker >> looks at it, there is no promise. > > That's not quite what I meant. I think I was just saying that we should > try to find ways to avoid lying about the types, in other words, > minimise needless unsafeCoerce(P) usage or the other more insidious > variants you pointed out. I'm ready for us to take a more conservative > slower approach as the price for this > >> A complication to (b) is that the modules compile in a specific order. >> In the past, that's the order David had asked me to work in. I think >> that's a decent order, as you can usually work in smaller patches but >> there is a tiny bit more churn at the end if you get something wrong >> in the middle. And I don't like amending patches in the middle of a >> sequence as I've had rather bad experiences with it. > > Right, hence the emphasis on keeping things small and working in > separate repos on unrelated things. Let a thousand branches bloom > or something. > >> I think (a) isn't really an issue. Until the witnesses are there I >> don't feel comfortable rearranging code, so it rarely happens. > > OK > >> I think we need (d): >> (d) Patches need to be very small and 'atomic' > > Within reason of course. A whole mess of 'small' patches can be just as > incomprehensible as a big chunk of burning patch. This will take some > experimentation to get right, but on the whole, I agree. > >> > For the question of orthogonality, how do we make it so that we can >> > accept some subset of the patches without having to accept the others? >> >> My experience has been than they always depend on each other due to >> the compilation order. And that, a module either completely type >> checks or it can't be checked with witnesses. David's recommendation >> in the past to deal with individual modules was to make one pass >> adding witness types that are known wrong. Record that patch. Next >> pass you start making it actually compile. This takes a long time so >> you keep amending your patch as you find time to work on it. Once it >> works, record that patch and record a third patch that adds your >> module to witnesses. Submit the patches. > > Sounds good so far. > >> For the command modules I presume you'd find IO actions that are not >> expressive enough. That's when I propose you start a new branch >> locally, write a new RIO version of that IO action and make a patch >> with just it. Then you'd make a patch that uses the RIO version in >> the command module. > > I wonder if it would make sense to just wrap the whole of IO into one > big RIO first and only later break it up into small RIO actions... > >> Submit those two patches. >> No promises in the command code, but the RIO code should be in a >> module where promises are made and kept. At this point, I guess the >> safest thing is to wait for those patches to appear in unstable. Once >> they appear you can pull them into your repo where you're working on >> the command, amend your current witnesses patch to use the RIO stuff >> and then keep going. Possibly sending in corrections to the new RIO >> code as you find them. >> >> Sound reasonable? > > I would try this approach one on one command or something, maybe > commenting how you're going about it along the way... > >> > How do we minimise the stress involved in asking for a revision to some >> > of the patches. >> >> The simplest way, and the one that may work best with my allotted free >> time, is just to stop all progress until my patches get accepted then >> move on to the next part. It doesn't scale, but that may not be >> important now. > > OK by me. I think an easy-going mañana type approach is sane. > >> > I might even consider doing parts of the type witness >> > work in separate branches to keep us honest. This may result in a few >> > conflicts here and there, but I think it's worthwhile. >> >> That's what we should have done when I was stressed and just wanted to >> make it work :0 Actually, I think I offered that to David. > > Still viable? > >> > Yeah, we have to be prepared to make mistakes. But I think we should >> > also keep an eye on getting things right the first time, this meaning >> > that if we do manage to spot or to see a mistake coming, we should try >> > to fix it right away, rather than saying "let's apply this now and fix >> > it later". Again, no hurrying. But you can relax about the problem of >> > doing something in good faith, and only later discovering it's wrong >> > when you work on a different module. Also keep in mind that when I >> > speak of orthogonality, I don't necessarily mean working in separate >> > modules. >> >> I'll assume that fixing it the right way now is adding a RIO action >> which will eventually replace the IO action version. Otherwise what >> you've said sounds fine but is too abstract for my poor little brain. > > The only thing I meant by this is that we should avoid the situation > where we deliberately do something we think is wrong for expediency > because we expect to get around to it later. So the idea is that we > should do this work as if we were half expecting to get hit by a bus > the next day... > >> > Jason >> > - identify tasks that can be done in parallel >> > - write up type witness roadmap (again, nothing fancy) >> >> My past experience tells me that there is very little that can be done >> in parallel with respect to the witnesses themselves. Possibly the >> RIO stuff can be done in parallel where different people add RIO >> versions of different things as they spot a future need. >> >> As for the write up, what do you think of my verbage earlier in this message? > > Please check with Ganesh > >> > - check if Ganesh if he is prepared to review type witness patches >> >> That's wise. > > Done. > > I'll repeat part of his response below: > | I'd call this a 'maybe'. If we're going to do it this way, I think one > | of us (whoever gets to it first?) needs to write up a rough plan for the > | final code - I guess that mainly means what the types are - and then > | secure the other's agreement to it. > > Also, Ben Moseley is offering to work on this during the sprint. Any > thoughts on whether this is something a newbie could do having read your > thesis? He will likely not get all the way, but how could you work with > him, hypothetically? Would you be wiling to review HIS patches? > The need for a plan becomes more urgent.
I'll reply to the rest later, but I wanted to get this in, in a timely manner. If Ben wants to submit patches on this then I say wonderful! I'll do my best to review them. I understand the witness types very well, but I don't always understand darcs itself that well. I anticipate it will require a lot of head scratching, some incorrect conjectures, and some genuine learning by everyone. In other words, it sounds like a great challenge and consequent learning experience. > > I say we take this to darcs-users. I approve. Adding darcs-users on the CC. Jason _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
