[darcs-users] Type witness, phase 2
Ben Moseley
ben_moseley at mac.com
Wed Apr 8 17:58:46 UTC 2009
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
More information about the darcs-users
mailing list