[Rd] Another wish (?) for R 4.0.0: print(*, width = )
One of the things I often wish R would work with:
When calling print() explicitly --- as I do not so rarely, e.g.,
specifying digits = ---
it sometimes seems awkward that from the printing options() ,
one can specify 'digits' and it has default digits = NULL which is
documented to be equivalent to digits = getOption("digits"),
but one cannot specify 'width'
... well "even worse": one *can* specify 'width = .' but it is
silently ignored - as well documented on ?print.default
Before considering to add this for R 4.0.0, doing the work
myself, I'd quickly wanted to hear opinions / caveats / .. about this.
wishing you all a Happy New Year,
Martin
Martin Maechler
ETH Zurich and R Core Team
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] standard naming for components of R data structures
Thank you: the R Language Definition is very helpful. On Mon, Jan 6, 2020 at 3:18 PM Abby Spurdle wrote: > Do you just need something on pen and paper? > (In which case, I don't see why it needs to be "standard"). > > Or do you need something that can be used with bison/yacc/cup/etc to > produce a parser? > > On a side note, I would say that the R Language Definition is the > "standard" way. > But I do recognize that this has a different flavour to modern > language implementation *theory*. > > https://cran.r-project.org/doc/manuals/r-release/R-lang.html > > > On Tue, Jan 7, 2020 at 5:17 AM Steve Dutky wrote: > > > > I need to write some documentation: > > > > I'm looking for a standard, consistent way of referring to the > components > > and attributes of R data structures. Googling and Stackoverflow yield a > > variety of github sites that do not seem to be particularly > authoritative. > > > > I was hoping to find a BNF/ABNF grammar for R. > > > > I've looked at the output of bison -v ./R-3.6.2/src/main/gram.y but it > does > > not appear helpful. > > > > I appreciate any suggestions for where to look or what to do. > > > > Thanks, Steve > > > > -- > > > > Ever tried, Ever failed, No Matter: > > > > Try again, Fail again, Fail Better. > > > > Samuel Beckett *Worstward Ho* > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Ever tried, Ever failed, No Matter: Try again, Fail again, Fail Better. Samuel Beckett *Worstward Ho* [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Another wish (?) for R 4.0.0: print(*, width = )
For whatever my 2c are worth I think this would be nice. I'm still
uncomfortable at having to call `options` in my package `diffobj` to set output
width.
And since the topic is here, what about `show`? Feels like it should accept
`...` so that it too could be given some set of standard or non standard
parameters, including `width`.
Happy new decade.
B.
On Tuesday, January 7, 2020, 6:58:32 AM EST, Martin Maechler
wrote:
One of the things I often wish R would work with:
When calling print() explicitly --- as I do not so rarely, e.g.,
specifying digits = ---
it sometimes seems awkward that from the printing options() ,
one can specify 'digits' and it has default digits = NULL which is
documented to be equivalent to digits = getOption("digits"),
but one cannot specify 'width'
... well "even worse": one *can* specify 'width = .' but it is
silently ignored - as well documented on ?print.default
Before considering to add this for R 4.0.0, doing the work
myself, I'd quickly wanted to hear opinions / caveats / .. about this.
wishing you all a Happy New Year,
Martin
Martin Maechler
ETH Zurich and R Core Team
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Another wish (?) for R 4.0.0: print(*, width = )
On Tue, Jan 7, 2020 at 6:14 AM brodie gaslam via R-devel
wrote:
>
> For whatever my 2c are worth I think this would be nice. I'm still
> uncomfortable at having to call `options` in my package `diffobj` to set
> output width.
Adding a few more cents: It might be worth considering "who" should be
allow to control the 'width' argument. In an interactive session,
it's neat for the user to quickly be able to adjust 'width'. But in
what cases should this be controlled by a (package) developer? What
assumptions can the developer safely make about the 'width' of the end
user? I don't know the answer to this and I'm sure one can find valid
cases where it makes sense to set the 'width' in a package - maybe
like width = 0.90 * getOption("width", 80)?
Could it be that print() ignoring 'width' has protected us from
packages producing output with a fixed, hardcoded width that is set by
the developer? If print() us updated to acknowledge 'width', will we
start seeing print(..., width = 120) and so on in package code? Is
this good or bad? This might be a complementary problem to what we
have with 'stringsAsFactors' where the user's settings can override
the intention of the developer.
/Henrik
>
> And since the topic is here, what about `show`? Feels like it should accept
> `...` so that it too could be given some set of standard or non standard
> parameters, including `width`.
> Happy new decade.
> B.
>
> On Tuesday, January 7, 2020, 6:58:32 AM EST, Martin Maechler
> wrote:
>
> One of the things I often wish R would work with:
>
> When calling print() explicitly --- as I do not so rarely, e.g.,
> specifying digits = ---
> it sometimes seems awkward that from the printing options() ,
> one can specify 'digits' and it has default digits = NULL which is
> documented to be equivalent to digits = getOption("digits"),
> but one cannot specify 'width'
> ... well "even worse": one *can* specify 'width = .' but it is
> silently ignored - as well documented on ?print.default
>
> Before considering to add this for R 4.0.0, doing the work
> myself, I'd quickly wanted to hear opinions / caveats / .. about this.
>
> wishing you all a Happy New Year,
> Martin
>
> Martin Maechler
> ETH Zurich and R Core Team
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Another wish (?) for R 4.0.0: print(*, width = )
On 1/7/20 06:13, brodie gaslam via R-devel wrote: ... > Happy new decade. *** caught segfault *** conflicting decade boundaries Traceback: 1: new_decade <- 2020:2029 2: previous_decade <- 2011:2020 3: previous_previous_decade <- 2001:2010 4: current_millenium <- 2001:3000 5: previous_millenium <- 1001:2000 6: previous_previous_millenium <- 1:1000 Cheers, H. -- 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: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Another wish (?) for R 4.0.0: print(*, width = )
On Wed, 8 Jan 2020 at 02:05, Pages, Herve wrote: > > On 1/7/20 06:13, brodie gaslam via R-devel wrote: > ... > > Happy new decade. > > *** caught segfault *** > conflicting decade boundaries https://xkcd.com/2249/ ;-) > > Traceback: > 1: new_decade <- 2020:2029 > 2: previous_decade <- 2011:2020 > 3: previous_previous_decade <- 2001:2010 > 4: current_millenium <- 2001:3000 > 5: previous_millenium <- 1001:2000 > 6: previous_previous_millenium <- 1:1000 > > Cheers, > H. Iñaki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
