[darcs-users] Type witness, phase 2

[Ben Moseley]

Hi Jason,

This all sounds good - what's the best thing to look at next?

Are there a bunch of relevant issues in the bug tracker? (I couldn't  
see a topic there which obviously corresponded to the witness work).  
Or is it best to dive into the code (maybe reading through some of the  
existing witnesses modules?)

--Ben

On 6 Apr 2009, at 05:16, Jason Dagit wrote:

> On Sun, Apr 5, 2009 at 4:53 PM, Eric Kow <kowey at darcs.net> 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
> darcs-users at darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-users