Re: [Rd] Wish list
A few comments thrown in, and some general comments at the bottom. On 1/1/2007 1:28 AM, Gabor Grothendieck wrote: This is my 2007 New Year wishlist for R features: 1. Matrix Multiplication Enhance matrix multiplication to work with multidimensional arrays such that the last dimension of the first multiplicand must equal the first dimension of the second. See: https://www.stat.math.ethz.ch/pipermail/r-devel/2006-July/038497.html 2. Grid - logical-valued function as first arg of grid.edit - transparency under Windows (not sure if this involves grid or just the Windows graphics device) - shading patterns - more interactivity features - safe way to get name of a grid object, e.g. names.vpPath - names.viewport - function(x) x$name - safe way to get children of a grid object getChildren.viewport - function(x) x$children and the order; see: https://www.stat.math.ethz.ch/pipermail/r-devel/2005-June/033532.html - facility for using a name, viewport or vpPath interchangably so that, for example, any of them can be specified in in print.trellis(..., draw.in=...) or draw.key(..., vp=...) 3. Lattice. - make panel functions generic - allow print.trellis args to be specified in xyplot, etc. - shading patterns (once grid implements them) - safe way to access lattice:::getStatus and lattice:::updateList - allow name, viewport or vpPath to be specified in draw.in= arg of print.trellis (and vp= arg of draw.key?) - document parameters, i.e. those output from trellis.par.get() - support for groups in histogram 4. Higher level Windows clipboard functions. Since R 2.3.0 R can handle non-text objects on the Windows clipboard. We now need some higher level functionality that makes use of that to read in non-text from the clipboard. For example, one can select a table on an HTML page in Internet Explorer and invoke copy and it will copy it to the clipboard in a non-text format. If one invokes paste in Excel, Excel will automatically detect the non-text format and copy it in the expected way so that it appears in Excel one table cell per Excel cell. However, R does not currently support this level of integration. (Current workaround is to paste it into Excel and then copy it back out of Excel. Excel will insert tabs between text that is so copied.) R doesn't have HTML parsing built in, so this would be a fairly major addition. It's a much better idea to write a package to do this. If the R clipboard support is missing something that such a package would need, that would be a reasonable addition to R. 6. Allow attributes to be associated with an environment variable without having them associated with the environment itself. This would allow more powerful inheritance in the case of subclasses of environment. See: https://stat.ethz.ch/pipermail/r-devel/2006-July/038377.html and subsequent postings in that thread. Any package that uses the list(env = whatever) idiom to define objects could make use of this. As I said in that thread, this is not a good suggestion. 7. documentation standards for packages - NEWS/ChangeLog (also should be accessible from CRAN page for package and should be included in built version of package) - package?mypackage I don't understand the second part of this. We already support a package?mypackage topic, and recommend that people put it in. Are you saying packages should be rejected if they don't? That's an awful lot of work you're asking other people to do. 8. Need to be able to distinguish between ordinary missing values and structurally missing ones. I think this is something that you need to do in a different way. There are tons of possible semantics for what NA should mean. I don't think this should be made more complicated for everyone. 9. bidirectional pipes in Windows 10. Create a log updated at a regular frequency (daily or real time) that tracks all changes on CRAN, e.g. Date(GMT) Package Version Action 2006-09-20 21:22:01 mypkg 1.0.1 new 2006-09-20 22:00:23 mypkg2 0.2.1 updated 11. make integrate generic. Ryacas could use that. 12. Remove all R CMD dependencies on the find.exe command. find is a built in command in Windows and having find.exe on my path causes problems with other programs. A simpler fix for this would be for you to define a wrapper for R CMD that installed the R tools path before executing, and uninstalls it afterwards. But this is unnecessary for most people, because Microsoft's find.exe is pretty rarely used. 13. Make upper/lower case of simplify/SIMPLIFY consistent on all apply commands and add a simplify= arg to by. It would have been good not to introduce the inconsistency years ago, but it's too late to change now. 14. better reporting of location of errors and warnings in R CMD
Re: [Rd] Wish list
On Mon, 1 Jan 2007, Duncan Murdoch wrote: A few comments thrown in, and some general comments at the bottom. On 1/1/2007 1:28 AM, Gabor Grothendieck wrote: This is my 2007 New Year wishlist for R features: 1. [deleted thru 12] 13. Make upper/lower case of simplify/SIMPLIFY consistent on all apply commands and add a simplify= arg to by. It would have been good not to introduce the inconsistency years ago, but it's too late to change now. Really? The consistency issue only concerns mapply, I think. How 'bout changing the formals of mapply to $FUN $... $MoreArgs NULL $SIMPLIFY simplify $USE.NAMES [1] TRUE $simplify [1] TRUE i.e. add simplify = TRUE and change SIMPLIFY's default to 'simplify' Then the default behavior is retained, specifying a value for either SIMPLIFY or simplify gives the desired behavior and SIMPLIFY takes precedence over simplify if both are given values. Not pretty, perhaps, but it does the job. I suppose this could get one into trouble if one of the ... args is named 'simplify', but I do not imagine that is a big deal. 14. [rest deleted] Charles C. Berry(858) 534-2098 Dept of Family/Preventive Medicine E mailto:[EMAIL PROTECTED] UC San Diego http://biostat.ucsd.edu/~cberry/ La Jolla, San Diego 92093-0717 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish list
Gabor Grothendieck wrote: On 1/1/07, Duncan Murdoch [EMAIL PROTECTED] wrote: A few comments thrown in, and some general comments at the bottom. On 1/1/2007 1:28 AM, Gabor Grothendieck wrote: This is my 2007 New Year wishlist for R features: 1. Matrix Multiplication Enhance matrix multiplication to work with multidimensional arrays such that the last dimension of the first multiplicand must equal the first dimension of the second. See: https://www.stat.math.ethz.ch/pipermail/r-devel/2006-July/038497.html 2. Grid - logical-valued function as first arg of grid.edit - transparency under Windows (not sure if this involves grid or just the Windows graphics device) - shading patterns - more interactivity features - safe way to get name of a grid object, e.g. names.vpPath - names.viewport - function(x) x$name - safe way to get children of a grid object getChildren.viewport - function(x) x$children and the order; see: https://www.stat.math.ethz.ch/pipermail/r-devel/2005-June/033532.html - facility for using a name, viewport or vpPath interchangably so that, for example, any of them can be specified in in print.trellis(..., draw.in=...) or draw.key(..., vp=...) 3. Lattice. - make panel functions generic - allow print.trellis args to be specified in xyplot, etc. - shading patterns (once grid implements them) - safe way to access lattice:::getStatus and lattice:::updateList - allow name, viewport or vpPath to be specified in draw.in= arg of print.trellis (and vp= arg of draw.key?) - document parameters, i.e. those output from trellis.par.get() - support for groups in histogram 4. Higher level Windows clipboard functions. Since R 2.3.0 R can handle non-text objects on the Windows clipboard. We now need some higher level functionality that makes use of that to read in non-text from the clipboard. For example, one can select a table on an HTML page in Internet Explorer and invoke copy and it will copy it to the clipboard in a non-text format. If one invokes paste in Excel, Excel will automatically detect the non-text format and copy it in the expected way so that it appears in Excel one table cell per Excel cell. However, R does not currently support this level of integration. (Current workaround is to paste it into Excel and then copy it back out of Excel. Excel will insert tabs between text that is so copied.) R doesn't have HTML parsing built in, so this would be a fairly major addition. It's a much better idea to write a package to do this. If the R clipboard support is missing something that such a package would need, that would be a reasonable addition to R. 6. Allow attributes to be associated with an environment variable without having them associated with the environment itself. This would allow more powerful inheritance in the case of subclasses of environment. See: https://stat.ethz.ch/pipermail/r-devel/2006-July/038377.html and subsequent postings in that thread. Any package that uses the list(env = whatever) idiom to define objects could make use of this. As I said in that thread, this is not a good suggestion. Yes, but I disagree with that assessment and I am not the only one. Nor is Duncan alone in his. best wishes Robert 7. documentation standards for packages - NEWS/ChangeLog (also should be accessible from CRAN page for package and should be included in built version of package) - package?mypackage I don't understand the second part of this. We already support a package?mypackage topic, and recommend that people put it in. Are you saying packages should be rejected if they don't? That's an awful lot of work you're asking other people to do. There should be some guidelines as to what goes into mypackage-package.Rd . 8. Need to be able to distinguish between ordinary missing values and structurally missing ones. I think this is something that you need to do in a different way. There are tons of possible semantics for what NA should mean. I don't think this should be made more complicated for everyone. Although one does not want to overcomplicate things the fact is that there are two issues here: structural and non-structural and trying to force them into a single construct is not simplifying -- rather it fails to model what is required adequately. 9. bidirectional pipes in Windows 10. Create a log updated at a regular frequency (daily or real time) that tracks all changes on CRAN, e.g. Date(GMT) Package Version Action 2006-09-20 21:22:01 mypkg 1.0.1 new 2006-09-20 22:00:23 mypkg2 0.2.1 updated 11. make integrate generic. Ryacas could use that. 12. Remove all R CMD dependencies on the find.exe command. find is a built in command in Windows and having find.exe on my path causes problems with other
Re: [Rd] Wish list
On 1/1/07, Robiert Gentleman [EMAIL PROTECTED] wrote: Gabor Grothendieck wrote: On 1/1/07, Duncan Murdoch [EMAIL PROTECTED] wrote: A few comments thrown in, and some general comments at the bottom. On 1/1/2007 1:28 AM, Gabor Grothendieck wrote: This is my 2007 New Year wishlist for R features: 1. Matrix Multiplication Enhance matrix multiplication to work with multidimensional arrays such that the last dimension of the first multiplicand must equal the first dimension of the second. See: https://www.stat.math.ethz.ch/pipermail/r-devel/2006-July/038497.html 2. Grid - logical-valued function as first arg of grid.edit - transparency under Windows (not sure if this involves grid or just the Windows graphics device) - shading patterns - more interactivity features - safe way to get name of a grid object, e.g. names.vpPath - names.viewport - function(x) x$name - safe way to get children of a grid object getChildren.viewport - function(x) x$children and the order; see: https://www.stat.math.ethz.ch/pipermail/r-devel/2005-June/033532.html - facility for using a name, viewport or vpPath interchangably so that, for example, any of them can be specified in in print.trellis(..., draw.in=...) or draw.key(..., vp=...) 3. Lattice. - make panel functions generic - allow print.trellis args to be specified in xyplot, etc. - shading patterns (once grid implements them) - safe way to access lattice:::getStatus and lattice:::updateList - allow name, viewport or vpPath to be specified in draw.in= arg of print.trellis (and vp= arg of draw.key?) - document parameters, i.e. those output from trellis.par.get() - support for groups in histogram 4. Higher level Windows clipboard functions. Since R 2.3.0 R can handle non-text objects on the Windows clipboard. We now need some higher level functionality that makes use of that to read in non-text from the clipboard. For example, one can select a table on an HTML page in Internet Explorer and invoke copy and it will copy it to the clipboard in a non-text format. If one invokes paste in Excel, Excel will automatically detect the non-text format and copy it in the expected way so that it appears in Excel one table cell per Excel cell. However, R does not currently support this level of integration. (Current workaround is to paste it into Excel and then copy it back out of Excel. Excel will insert tabs between text that is so copied.) R doesn't have HTML parsing built in, so this would be a fairly major addition. It's a much better idea to write a package to do this. If the R clipboard support is missing something that such a package would need, that would be a reasonable addition to R. 6. Allow attributes to be associated with an environment variable without having them associated with the environment itself. This would allow more powerful inheritance in the case of subclasses of environment. See: https://stat.ethz.ch/pipermail/r-devel/2006-July/038377.html and subsequent postings in that thread. Any package that uses the list(env = whatever) idiom to define objects could make use of this. As I said in that thread, this is not a good suggestion. Yes, but I disagree with that assessment and I am not the only one. Nor is Duncan alone in his. Nor am I. Read the thread. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Connections to https: URLs -- IE expert help needed
Duncan Temple Lang writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Prof Brian Ripley wrote: I've added to R-devel the ability to use download.file() and url() to https: URLs, *only* if --internet2 is used on Windows. This uses the Internet Explorer internals, and only works if the certificate is accepted (so e.g. does not work for https://svn.r-project.org). Now I use IE (and Windows for that matter) only when really necessary, and Firefox has simple ways to permanently accept non-verifiable certificates. I would be grateful if someone who is much more familiar with IE could write a note explaining how to deal with this that we could add to the rw-FAQ. To forestall the inevitable question: there are no plans to add https: support on any other platform, but it is something that would make a nice project for a user contribution. The current internal code is based on likxml2, and that AFAICS still does not have https: support. Generally (i.e. not in particular response to Brian but related to this thread) With a similar disclaimer: Brian's efforts were triggered by me asking how to use url() to read R's mailing list archive files, such as https://stat.ethz.ch/pipermail/r-help/2007-January.txt.gz directly into R. Turns out we cannot ... which, in a way, is a shame (R cannot read its own web pages) :-( Best -k An alternative is to use RCurl and leave HTTPS and a host of other protocols and details to an external library (e.g. libcurl, libwww, etc.) and an R package that interfaces to it. If we want the facilities to be accessible via the connections interface, then we can make that API extensible by packages. Jeff Horner has a proposal on that. Generally, it is important if R is to continue to evolve that the R internals become extensible by package developers so that we can do some new experiments and provide alternative implementations of the basic structures rather than being tied to the existing representation. An object oriented framework underlying the R source code would enable this and would solve numerous problems that have arisen recently and I strongly suspect many more that will arise. D. - -- Duncan Temple Lang[EMAIL PROTECTED] Department of Statistics work: (530) 752-4782 4210 Mathematical Sciences Building fax: (530) 752-7099 One Shields Ave. University of California at Davis Davis, CA 95616, USA -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFibTh9p/Jzwa2QP4RAgBiAJ9YojjDf0DMIo9FQ7yW1MiMdANvogCfRgCX zci7UsavJESdidbyiCl2Xgw= =HiuE -END PGP SIGNATURE- __ 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] Wish list
On 1/1/2007 1:10 PM, Gabor Grothendieck wrote: On 1/1/07, Duncan Murdoch [EMAIL PROTECTED] wrote: A few comments thrown in, and some general comments at the bottom. On 1/1/2007 1:28 AM, Gabor Grothendieck wrote: This is my 2007 New Year wishlist for R features: 1. Matrix Multiplication Enhance matrix multiplication to work with multidimensional arrays such that the last dimension of the first multiplicand must equal the first dimension of the second. See: https://www.stat.math.ethz.ch/pipermail/r-devel/2006-July/038497.html 2. Grid - logical-valued function as first arg of grid.edit - transparency under Windows (not sure if this involves grid or just the Windows graphics device) - shading patterns - more interactivity features - safe way to get name of a grid object, e.g. names.vpPath - names.viewport - function(x) x$name - safe way to get children of a grid object getChildren.viewport - function(x) x$children and the order; see: https://www.stat.math.ethz.ch/pipermail/r-devel/2005-June/033532.html - facility for using a name, viewport or vpPath interchangably so that, for example, any of them can be specified in in print.trellis(..., draw.in=...) or draw.key(..., vp=...) 3. Lattice. - make panel functions generic - allow print.trellis args to be specified in xyplot, etc. - shading patterns (once grid implements them) - safe way to access lattice:::getStatus and lattice:::updateList - allow name, viewport or vpPath to be specified in draw.in= arg of print.trellis (and vp= arg of draw.key?) - document parameters, i.e. those output from trellis.par.get() - support for groups in histogram 4. Higher level Windows clipboard functions. Since R 2.3.0 R can handle non-text objects on the Windows clipboard. We now need some higher level functionality that makes use of that to read in non-text from the clipboard. For example, one can select a table on an HTML page in Internet Explorer and invoke copy and it will copy it to the clipboard in a non-text format. If one invokes paste in Excel, Excel will automatically detect the non-text format and copy it in the expected way so that it appears in Excel one table cell per Excel cell. However, R does not currently support this level of integration. (Current workaround is to paste it into Excel and then copy it back out of Excel. Excel will insert tabs between text that is so copied.) R doesn't have HTML parsing built in, so this would be a fairly major addition. It's a much better idea to write a package to do this. If the R clipboard support is missing something that such a package would need, that would be a reasonable addition to R. 6. Allow attributes to be associated with an environment variable without having them associated with the environment itself. This would allow more powerful inheritance in the case of subclasses of environment. See: https://stat.ethz.ch/pipermail/r-devel/2006-July/038377.html and subsequent postings in that thread. Any package that uses the list(env = whatever) idiom to define objects could make use of this. As I said in that thread, this is not a good suggestion. Yes, but I disagree with that assessment and I am not the only one. It doesn't matter how many people disagree: what matters is achieving a consensus about what change is needed. I don't think you could convince me that the proposal you made is the right way to solve this problem, and I know there are others who don't agree with the proposal I made to solve it. So it is unlikely to be changed, unless someone comes up with a new proposal. 7. documentation standards for packages - NEWS/ChangeLog (also should be accessible from CRAN page for package and should be included in built version of package) - package?mypackage I don't understand the second part of this. We already support a package?mypackage topic, and recommend that people put it in. Are you saying packages should be rejected if they don't? That's an awful lot of work you're asking other people to do. There should be some guidelines as to what goes into mypackage-package.Rd . There are, in the Writing R Extensions manual. 8. Need to be able to distinguish between ordinary missing values and structurally missing ones. I think this is something that you need to do in a different way. There are tons of possible semantics for what NA should mean. I don't think this should be made more complicated for everyone. Although one does not want to overcomplicate things the fact is that there are two issues here: structural and non-structural and trying to force them into a single construct is not simplifying -- rather it fails to model what is required adequately. There aren't just two types of missingness, there are hundreds. For example, I might have some values missing because I couldn't
Re: [Rd] Wish list
Anyone who uses batch files will use it quite a bit. It certainly causes me problems on an ongoing basis and is an unacceptable conflict in my opinion. If you're using batch files, the fix I suggested is trivial for you. The batch files could come from other programs you are using which one does not really want to have to figure them out and modify them. In any case, R should not be written in a way which conflicts with system utilities. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish list
On 1/1/2007 12:59 PM, Charles C. Berry wrote: On Mon, 1 Jan 2007, Duncan Murdoch wrote: A few comments thrown in, and some general comments at the bottom. On 1/1/2007 1:28 AM, Gabor Grothendieck wrote: This is my 2007 New Year wishlist for R features: 1. [deleted thru 12] 13. Make upper/lower case of simplify/SIMPLIFY consistent on all apply commands and add a simplify= arg to by. It would have been good not to introduce the inconsistency years ago, but it's too late to change now. Really? The consistency issue only concerns mapply, I think. mapply and its wrapper Vectorize, and perhaps some functions in contributed packages. How 'bout changing the formals of mapply to $FUN $... $MoreArgs NULL $SIMPLIFY simplify $USE.NAMES [1] TRUE $simplify [1] TRUE i.e. add simplify = TRUE and change SIMPLIFY's default to 'simplify' Then the default behavior is retained, specifying a value for either SIMPLIFY or simplify gives the desired behavior and SIMPLIFY takes precedence over simplify if both are given values. Not pretty, perhaps, but it does the job. This allows mapply(..., simplify=TRUE), but is that really the job? I think the point of consistency is to make code easier to read and write, and I'm not sure making this one parameter partially case-insensitive achieves that. Should the same thing be done to the functions that currently use simplify, to achieve even more consistency? Yecch. I suppose this could get one into trouble if one of the ... args is named 'simplify', but I do not imagine that is a big deal. I think the reasoning behind the choice of SIMPLIFY was probably to avoid a clash with one of the ... args. I'd prefer a more general solution to this problem, like what the Mac GUI does, and giving argument hints as a function call is being typed. (I think ESS may do this too, but I don't use it.) There are lots of inconsistencies in R functions, and I think making the syntax looser in order to accept a consistent superset is not the right approach: instead, the editor should make it easier for a user to discover what is appropriate in any given context. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish list
On 1/1/2007 7:17 PM, Gabor Grothendieck wrote: Anyone who uses batch files will use it quite a bit. It certainly causes me problems on an ongoing basis and is an unacceptable conflict in my opinion. If you're using batch files, the fix I suggested is trivial for you. The batch files could come from other programs you are using which one does not really want to have to figure them out and modify them. You don't need to modify any other batch files, you just need to create a new batch file named R.bat as a wrapper for R. I forget batch file syntax, so I'm sure this is wrong, but it would look something like this: SAVEPATH=%PATH% PATH=Rtools\bin;R\bin;... R %1 %2 ... PATH=%SAVEPATH% In any case, R should not be written in a way which conflicts with system utilities. I'd guess the find that R uses predates the one that Microsoft invented. Think of the R toolset as an attempt to correct the mistakes that Microsoft made, by making the environment more Unix-like. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Connections to https: URLs -- IE expert help needed
Kurt Hornik wrote: Duncan Temple Lang writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Prof Brian Ripley wrote: I've added to R-devel the ability to use download.file() and url() to https: URLs, *only* if --internet2 is used on Windows. This uses the Internet Explorer internals, and only works if the certificate is accepted (so e.g. does not work for https://svn.r-project.org). Now I use IE (and Windows for that matter) only when really necessary, and Firefox has simple ways to permanently accept non-verifiable certificates. I would be grateful if someone who is much more familiar with IE could write a note explaining how to deal with this that we could add to the rw-FAQ. To forestall the inevitable question: there are no plans to add https: support on any other platform, but it is something that would make a nice project for a user contribution. The current internal code is based on likxml2, and that AFAICS still does not have https: support. Generally (i.e. not in particular response to Brian but related to this thread) With a similar disclaimer: Brian's efforts were triggered by me asking how to use url() to read R's mailing list archive files, such as https://stat.ethz.ch/pipermail/r-help/2007-January.txt.gz directly into R. Turns out we cannot ... which, in a way, is a shame (R cannot read its own web pages) :-( Indeed, it is a shame. Although, when I process mail messages, I use Perl's very rich collection of modules for processing mail in so many different formats. And then I use RSPerl to control this and get the data into R pretty quickly. So we can do it in R and probably the delegation to mail-processing software is a good given the number of special cases, etc. And even if we had HTTPs in R, we would still want to deal with the certificate on that page, which gets us to more details. Which is the reason I think leaving things to libcurl, libwww, etc. will be best as they continue to evolve to handle new protocols and settings. D. Best -k An alternative is to use RCurl and leave HTTPS and a host of other protocols and details to an external library (e.g. libcurl, libwww, etc.) and an R package that interfaces to it. If we want the facilities to be accessible via the connections interface, then we can make that API extensible by packages. Jeff Horner has a proposal on that. Generally, it is important if R is to continue to evolve that the R internals become extensible by package developers so that we can do some new experiments and provide alternative implementations of the basic structures rather than being tied to the existing representation. An object oriented framework underlying the R source code would enable this and would solve numerous problems that have arisen recently and I strongly suspect many more that will arise. D. - -- Duncan Temple Lang[EMAIL PROTECTED] Department of Statistics work: (530) 752-4782 4210 Mathematical Sciences Building fax: (530) 752-7099 One Shields Ave. University of California at Davis Davis, CA 95616, USA -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFibTh9p/Jzwa2QP4RAgBiAJ9YojjDf0DMIo9FQ7yW1MiMdANvogCfRgCX zci7UsavJESdidbyiCl2Xgw= =HiuE -END PGP SIGNATURE- __ 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 -- Duncan Temple Lang[EMAIL PROTECTED] Department of Statistics work: (530) 752-4782 4210 Mathematical Sciences Bldg. fax: (530) 752-7099 One Shields Ave. University of California at Davis Davis, CA 95616, USA pgpGagOBzSxIn.pgp Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish list
Henrik Bengtsson wrote: On 1/2/07, Duncan Murdoch [EMAIL PROTECTED] wrote: On 1/1/2007 12:59 PM, Charles C. Berry wrote: On Mon, 1 Jan 2007, Duncan Murdoch wrote: A few comments thrown in, and some general comments at the bottom. On 1/1/2007 1:28 AM, Gabor Grothendieck wrote: This is my 2007 New Year wishlist for R features: 1. [deleted thru 12] 13. Make upper/lower case of simplify/SIMPLIFY consistent on all apply commands and add a simplify= arg to by. It would have been good not to introduce the inconsistency years ago, but it's too late to change now. Really? The consistency issue only concerns mapply, I think. mapply and its wrapper Vectorize, and perhaps some functions in contributed packages. How 'bout changing the formals of mapply to $FUN $... $MoreArgs NULL $SIMPLIFY simplify $USE.NAMES [1] TRUE $simplify [1] TRUE i.e. add simplify = TRUE and change SIMPLIFY's default to 'simplify' Then the default behavior is retained, specifying a value for either SIMPLIFY or simplify gives the desired behavior and SIMPLIFY takes precedence over simplify if both are given values. Not pretty, perhaps, but it does the job. This allows mapply(..., simplify=TRUE), but is that really the job? I think the point of consistency is to make code easier to read and write, and I'm not sure making this one parameter partially case-insensitive achieves that. Should the same thing be done to the functions that currently use simplify, to achieve even more consistency? Yecch. Given that you want to take the step to change/remove an argument, I think this is a good strategy; first provide a backward compatible API and announce that the original argument is deprecated, and then when everyone had a chance to update and test dependent code, you can safely remove the argument. Given that premise, and with the addition that at some point in the process using the obsolete parameter would generate a warning, I'd agree. But I don't see that the value of the change *in this particular case* is worth the effort. Duncan Murdoch My $.02 Henrik I suppose this could get one into trouble if one of the ... args is named 'simplify', but I do not imagine that is a big deal. I think the reasoning behind the choice of SIMPLIFY was probably to avoid a clash with one of the ... args. I'd prefer a more general solution to this problem, like what the Mac GUI does, and giving argument hints as a function call is being typed. (I think ESS may do this too, but I don't use it.) There are lots of inconsistencies in R functions, and I think making the syntax looser in order to accept a consistent superset is not the right approach: instead, the editor should make it easier for a user to discover what is appropriate in any given context. Duncan Murdoch __ 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
