[Rd] Patch proposal for R style consistency (concerning deparse.c)

[Hervé Pagès]

On 05/01/2013 07:20 PM, Duncan Murdoch wrote:
> On 13-05-01 4:08 PM, Tim Triche, Jr. wrote:
>> What harm comes of having the code be cut-and-paste-able?
>>
>> I do not mean to be contrary but a downside to applying the patch
>> seems to
>> be lacking.
>> Perhaps I am missing something obvious and if so I beg your pardon for
>> wasting your time.
>
> I think you are missing some downsides which may not be obvious:
>
>   - it would mean that lots of published results would no longer match
> what R produces.

What kind of published results? Results that do statistics on the nb
of lines of code in a function based on the output of print.function()?

Would it make sense to try to reproduce results that were published 5
or 10 years ago with R >= 3.0.0? Too many things have changed in R
and on CRAN anyway so it's hopeless. The only reasonable/realistic way
to reproduce is to use the version of R and packages that were used
at the time of the publication.

>   - it would mean that lots of tests for changes in output would
> suddenly fail.

Lots of tests really? Where are they?

>   - it would support the mistaken belief that some people have that the
> current output is not valid code (even though there are nearly 200,000
> instances of similar usage on CRAN).

Is that number supposed to impress someone?

Running

   grep -E '^[[:space:]]*else' */R/*

produces 112,518 lines of output on the 4479 source packages currently 
available on CRAN. So 112,518 "if else" statements use the formatting
that breaks copy/paste.

Also, interestingly, running

   grep else */R/*

on those packages produces 276028 lines of output. So only 34% of the
"if else" statements use the formatting that breaks copy/paste. Far
from being the dominant idiom, which is probably a good sign for CRAN.

Unfortunately, with the current output of print.function(), 100% of
the "if else" statements on CRAN break copy/paste. Unfair for the
majority of CRAN contributors to see their nicely formatted code
exposed that way to the end-user. Unfair for the end-user, especially
the R novice, to get code s/he cannot copy/paste.

>
> Perhaps 20 years ago it should have been written the way you suggest,
> but it would cause far more harm than benefit to change it now.

You clearly underestimate the harm the current formatting causes
every day to many R users, developers, teachers, students...

H.

>
> Duncan Murdoch
>
>>
>> Thanks,
>>
>> --t
>>
>>
>>
>> On Wed, May 1, 2013 at 12:19 PM, Duncan Murdoch
>> <murdoch.duncan at gmail.com>wrote:
>>
>>> On 01/05/2013 1:34 PM, Tim Triche, Jr. wrote:
>>>
>>>> +1 to having runnable code emitted
>>>>
>>>
>>> It does emit runnable code, which is why Herve's complaint was nonsense.
>>>   It doesn't emit code of which every substring is runnable.
>>>
>>> Duncan Murdoch
>>>
>>>
>>>
>>>> patch seems to work nicely, hopefully R-core will agree to apply it to
>>>> HEAD
>>>>
>>>>
>>>>
>>>> On Wed, May 1, 2013 at 9:45 AM, Paul Johnson <pauljohn32 at gmail.com>
>>>> wrote:
>>>>
>>>>> Whoa.
>>>>>
>>>>> Don't let my valuable suggestion get lost.
>>>>>
>>>>>   I want "} else {".  Yihue wants "} else {".  And I have not heard
>>>> anybody
>>>>> say they prefer the other way, unless you interpret Duncan's comment
>>>>> "that's nonsense" as a blanket defense of the status quo. But I don't
>>>> think
>>>>> he meant that.  This is a matter of style consistency and avoidance of
>>>> new
>>>>> R-user confusion and error.
>>>>>
>>>>> After reading the help for "if", I don't see how anybody can argue
>>>> against
>>>>> this.  Good R code has this style:
>>>>>
>>>>> } else {
>>>>>
>>>>> and not
>>>>>
>>>>> }
>>>>>   else
>>>>>
>>>>> because the latter fails if it is run line-by-line.  While trying to
>>>> teach
>>>>> people how to write R programs, it would be nice if the output of
>>>>> print.function was consistent with the good way, the way that is
>>>> actually
>>>>> practiced in the R source code itself. This is a major source of new
>>>>> programmer confusion. Its very tough to explain and teach.
>>>>>
>>>>> pj
>>>>> --
>>>>> Paul E. Johnson
>>>>> Professor, Political Science      Assoc. Director
>>>>> 1541 Lilac Lane, Room 504      Center for Research Methods
>>>>> University of Kansas                 University of Kansas
>>>>> http://pj.freefaculty.org               http://quant.ku.edu
>>>>>
>>>>>          [[alternative HTML version deleted]]
>>>>>
>>>>> ______________________________**________________
>>>>> R-devel at r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/**listinfo/r-devel<https://stat.ethz.ch/mailman/listinfo/r-devel>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319