Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Generalizing Support for Functional OOP in R

blog.r-project.org

Post reply on HN
Print view View original

51–53 of 53 posts

Re: Generalizing Support for Functional OOP in R

#51

Post by orhmeh09 »

int_19h wrote: post #36
orhmeh09 wrote: post #4

Earlier quoted context omitted.

OOP has been a critical part of real-life R for a long time, especially in complex implementations of classes of kernels, algorithms, and so on with S4, and more general-purpose with R6. Without these frameworks it would be difficult to implement them. Personally I find it more expressive for general-purpose computation than Python. The "fs" library is much better at working with files and paths than Python "os" and…

In modern idiomatic Python, you should really be using `pathlib` and `io`, not `os`.

Yeah, you're absolutely right. The `os` methods are closest to the base R file operations and those in `pathlib` are closest to `fs` (which is a third-party library for R that requires installation).

Re: Generalizing Support for Functional OOP in R

#52

Post by int_19h »

klibertp wrote: post #49
int_19h wrote: post #41

Earlier quoted context omitted.

R is such a weird little language. It's basically lazy Lisp dressed up in C syntax. For example, the only operator it really has is a function call. Everything else is syntactic sugar for a function call, and I mean literally everything : assignments, conditionals, loops, even function definitions and curly braces are all function calls. For example: a and so on. You can actually see what things look like under the h…

Thanks for a great explanation. It looks like the thing Scala does with its by-name parameters, but for every parameter by default. Even closer analogy, I think Io works in a very similar way - bodies of methods can access their arguments as Message (ie. unevaluated calls) objects and then decide to evaluate them as needed (which differs from your example in that the body can choose the context in which the message s…

In R, you can also choose the context in which the argument expression is to be evaluated. If you just use the promise as if it were a value and rely on implicit evaluation, then it happens in the context of the caller, yes. But environments (i.e. sets of name-value bindings) in R are first-class objects, so they can be captured at any given point, and later used to explicitly evaluate promises after retrieving the latter's associated expression.

   foo
Side note: substitute() seems like a weird name for a function that returns the underlying expression of the promise. It's named that way because it's actually similar in intended use to quasiquotation - it lets you explicitly substitute variable names for something else in the expression before evaluating it. So e.g. substitute(x <- x + 1, x=2) returns the expression object for (1 <- 1 + 2). Not passing any named arguments is just a special case where no substitutions are made and the original expression is returned instead, although in practice that is probably the most common way to use it.

Re: Generalizing Support for Functional OOP in R

#53

Post by andrewla »

rossdavidh wrote: post #47
andrewla wrote: post #6

Earlier quoted context omitted.

OOP as used in R is very much a function of API design and not a function of routine R usage for data analysis. To many users of R they are not even aware that they are using OOP at all, especially for the S3 style of objects. When you have an object, like `model summary()` ends up being very natural, and when you fit in the tidyverse operators many very complex workflows end up being very easy to digest. But when yo…

Interesting! To prove your point, I was unaware that I was using OOP in R when I did those kinds of things. But, it feels more like functional programming, and I wonder if "OOP" is even a good way of describing that, if that's what they mean?

There are really only two situations where it matters. One is in developing tooling; you have to understand how all this works together so that the user can do things like call `summary` or `plot` on your objects.

The other is when you are trying to debug why something isn't working -- a lot of the time you can dump an R function just by typing the name, so you can run `table` with no parameters to get the `table()` function, if you're trying to figure out why it's not working right for your data. But if you execute `plot` you'll get some thing saying "UseMethod("plot")" which feels a bit recursive -- "in order to plot, plot", and then you end up going down that rabbit hole, which leads you to contributing to R packages, developing some of your own, and eventually posting on HN about how R's class system works.

Post reply on HN