> We are talking about functions with side effects, i.e. functions which usually do not return an object.
Oh, okay! I'm actually all for that. Cheers, -Dave B On Tue, Jan 27, 2026 at 10:14 AM Klaus Schliep <[email protected]> wrote: > Dear all, > here are a few explanations of the suggested changes and some subjective > comments. > > First to Dave > > It's hard to evaluate the effect of (5) without knowing what functions we > > are talking about. I will point out that invisible returns are very > > confusing to novice R users. > > -Dave > > > > We are talking about functions with side effects, i.e. functions which > usually do not return an object. Examples are plot(), print(), summary() > and as you see these functions are often generic functions. The tidyverse > relies heavily on this for piping. > In phangorn this allows you to do things like pml_bb(alignment, "JC") |> > plot() |> print(). > And users would not be confused, as the object is returned invisible. If > you don't assign the output you won't notice. However they might wonder > nowadays why piping is not working. > > and now to Vojtěch > > > Hello, > > this a perfect idea. :-) I'd love to see one two things: > > 1) Support for parallelization whenever possible (various distance, work > > with > > multi.whatever objects, ...) to speed things up. > > > > This is generally a good idea. The problem is that parallelization depends > on the hardware (cluster, multicore machine) of the user, the operating > system (usually easy on Linux, tricky on OSX and Windows) and additionally > whether you run R inside a GUI or from the console. > Additionally some matrix algebra code might already be parallelized. > This depends on the BLAS library you use, so if you use parallelization on > top you might slow down your computer. > This is why I started using the future and future.apply packages in > phangorn instead of mclapply. This puts the user in control to choose the > parallelization framework to use and I don't need to check the operating > system, number of cores, GUI etc. > Some low level openMP stuff in C/C++ code might be still nice. > > > > 2) Removal of all the *.mutliPhylo functions, i.e. IMHO the best would be > > if > > every relevant function would support phylo as well as multiPhylo > objects. > > Now > > it's a bit confusing whenever to use which function... > > > > I think there might be a misconception here. We introduced a lot of generic > functions to ape, e.g. root, is.rooted, is.ultrametric etc. > Now while there exist is.rooted.phylo() and is.rooted.multiPhylo(), users > should only need to use is.rooted(x) and don't need to care about the phylo > or multiPhylo versions. Maybe it is more a problem with the documentation? > > > > So here are my proposals for the discussion. :-) > > Sincerely, > > V. > > > Cheers, > Klaus > > > > > > > > On Mon, Jan 26, 2026 at 9:31 AM Emmanuel Paradis < > [email protected]> > > wrote: > > > > > Dear all, > > > > > > We are in the process of reviewing the "old" code in ape (some written > in > > > 2001). Here are a few things that came out recently: > > > > > > 1) During a recent discussion, we wondered if the option "..." of > > > read.tree() is useful; it is passed internally to scan(). A review of > the > > > CRAN packages suggests this option is useless so it could be removed, > at > > > least without breaking those packages. There may be other bits of code > > that > > > can be removed safely in other functions. > > > > > > 2) Printing of objects could be improved. > > > > > > 3) I've (re)introduced a function mafft() in ape. A function with the > > same > > > name was formerly in ips which is now orphaned on CRAN. > > > > > > 4) A review of the man pages (help) would be useful. For instance, in > > > ?read.tree one can read: "If there are two root edges (e.g., > > > "(((A:1,B:1):10):10);"), then the tree is not read and an error message > > is > > > issued." [1] which is wrong since all types of Newick tree can be read. > > > There are certainly similar outdated statements in the 300 pages of the > > > manual. > > > > > > 5) Klaus suggests to have more functions returning their "return value" > > > invisibly to make easier the use of pipe operators (|> or %>%). > > > > > > Any thoughts, ideas, or comments are welcome. > > > > > > Best, > > > > > > Emmanuel > > > > > > [1] In version 5.8-1 currently on CRAN; now fixed on GitHub. > > > > > > _______________________________________________ > > > R-sig-phylo mailing list - [email protected] > > > https://stat.ethz.ch/mailman/listinfo/r-sig-phylo > > > Searchable archive at > > > http://www.mail-archive.com/[email protected]/ > > > > > > > [[alternative HTML version deleted]] > > > > _______________________________________________ > > R-sig-phylo mailing list - [email protected] > > https://stat.ethz.ch/mailman/listinfo/r-sig-phylo > > Searchable archive at > > http://www.mail-archive.com/[email protected]/ > > > > > -- > Klaus Schliep > > Senior Scientist > Institute of Molecular Biotechnology > TU Graz > https://www.imbt.tugraz.at > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-phylo mailing list - [email protected] > https://stat.ethz.ch/mailman/listinfo/r-sig-phylo > Searchable archive at > http://www.mail-archive.com/[email protected]/ > [[alternative HTML version deleted]] _______________________________________________ R-sig-phylo mailing list - [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-phylo Searchable archive at http://www.mail-archive.com/[email protected]/
