[darcs-users] darcs patch: add "parallel pairs" (and 6 more)

Jason Dagit dagit at codersbase.com
Sat Sep 19 08:09:07 UTC 2009

On Sat, Sep 19, 2009 at 8:31 AM, Peter B. West <lists at pbw.id.au> wrote:

> On 19/09/2009, at 5:18 AM, Nicolas Pouillard wrote:
>  Excerpts from Eric Kow's message of Fri Sep 18 09:14:25 +0200 2009:
>>> On Thu, Sep 17, 2009 at 22:52:30 +0100, Ganesh Sittampalam wrote:
>>>> This is an initial attempt at adding interactive editing of hunk
>>>> patches. I don't necessarily expect this sequence to be applied
>>>> as-is, though it could be.
>>> What a treat!  I'm going to push the easy patches first
>>> * add "parallel pairs"
>>> * break out and export run_editor utility function
>>> * Add utility code for editing text
>>> And leave the meat of this bundle for later (perhaps somebody else
>>> wants to tag themselves in?)
>> I have a question about the hunk editing feature.
>> Does it leave the pristine tree as is (like git), or not?
>> [...]
>>  break out and export run_editor utility function
>>> ------------------------------------------------
>>>> +run_editor :: FilePath -> IO ExitCode
>>>> +run_editor f = do
>>>> +  ed <- get_editor
>>>> +  exec_interactive ed f
>>>> +       `ortryrunning` exec_interactive "emacs" f
>>>> +       `ortryrunning` exec_interactive "emacs -nw" f
>>>> +       `ortryrunning` exec_interactive "nano" f
>>>> +#ifdef WIN32
>>>> +       `ortryrunning` exec_interactive "edit" f
>>>> +#endif
>>> I think all new functions should be camelCase.  It's not that I care,
>>> it's just that I want it to stop even being a question.  The desired
>>> outcome is that we never get anybody having to scratch their heads
>>> looking for a deeper meaning or conventions behind the case.
>> I think (if my memory serve me well) that it is one of David's convention;
>> that is: camel case for exported values and underscores for internal ones.
>> Which would make sense since you are exporting a previously internal
>> thing,
>> right?
> I'm a mere user of darcs, waiting for the day when I can unreservedly
> recommend it for all SCM users, but...
> CamelCase is one of my pet loathings. It dramatically impacts readability
> in long names, consequently discouraging their use. That much, I think, is
> unexceptionable.
> If you would argue against long names, fair enough.
> IMO, CamelCase has a general negative impact on readability. I have heard
> the argument that it draws the eye to the functions and variables, which I
> take to support my point.

Hi Don,

CamelCase is the defacto standard in the Haskell Community.  For example,
the Haskell Prelude uses CamelCase instead of other conventions.  In the
Darcs project we currently use several styles and this creates confusion and
generates discussions like this one.  Without reiterating the rationale, the
majority of the Darcs developers feel that sticking with one convention,
camaleCase in this context, is beneficial.

I'm sorry this convention is not your favorite, but please realize we would
like to follow the style guidelines of the larger Haskell Community when we

When you say that it draws the eyes to functions and variables, what
argument are you referring too?  I find the psychology of programming to be
an interesting topic so if you know of a research paper about this I would
like to read it.  Finally, since Haskell is emphasizes functions and named
values (variables rarely exist in Haskell), it is not clear to me how
CamelCase is a detriment here.  Do you think you could explain what you

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090919/dca222f8/attachment.htm>

More information about the darcs-users mailing list