Generalizing Support for Functional OOP in R • Hacker News Board

Re: Generalizing Support for Functional OOP in R

#31

Post by CornCobs » Wed, May 29, 2024, 12:11 AM UTC

orhmeh09 wrote: post #29

civilized wrote: post #25

Earlier quoted context omitted.

R is not lazy. It has non-standard evaluation mechanisms (formulas, promises, quosures...) that enable to you to write domain-specific languages that "do what the user meant". If your code (or the code of the libraries you're using) doesn't use any non-standard evaluation tools, evaluation will be eager and work like any other ALGOL language. It is possible to make some objects behave in a lazy way, but this is also…

Thank you for the correction. Is it possible to use NSE in say Python or JavaScript?

Yes, though the languages do not support it explicitly you can simulate lazy evaluation by wrapping all your arguments in closures. This way they won't be evaluated until called within the function body.

Re: Generalizing Support for Functional OOP in R

#32

Post by CornCobs » Wed, May 29, 2024, 12:28 AM UTC

usgroup wrote: post #12

rossdavidh wrote: post #2

To be honest, OOP never really seemed like a good fit for R. Functional programming is a much more natural fit, given that both it and R come from a mathematical point of view. R is a great language for the mathematical/statistical stuff it was invented to do, but I don't think it will ever be a general-purpose language, and it probably would become worse at its core purpose if it tried to. More work on being easily…

Yet you’re using OOP every time you call plot, predict, summary and so on: possibly without realising.

I actually think this "multi-tiered" system of OOP is quite cool, when compared to languages that stick OOP in your face upfront.

1. Basic users don't even know it's there, they're just calling regular functions.

2. S3 in base is super simple to understand and easy to extend the first time you need to implement your own summary.

3. Full blown OOP with slots and methods is available when you really need it (rare for a user and not library author imo, lists and S3 are sufficient for most things).

The big issue I see is the incompatibilities in the various systems making this "ramp up" not so smooth. But it looks like that's what S7 is trying to address so that's cool.

Re: Generalizing Support for Functional OOP in R

#33

Post by aquasync » Wed, May 29, 2024, 12:35 AM UTC

civilized wrote: post #25

agumonkey wrote: post #16

Earlier quoted context omitted.

> I suspect lazy evaluation is a part of this. I had no idea R was lazy. Makes me wanna learn it now.

R is not lazy. It has non-standard evaluation mechanisms (formulas, promises, quosures...) that enable to you to write domain-specific languages that "do what the user meant". If your code (or the code of the libraries you're using) doesn't use any non-standard evaluation tools, evaluation will be eager and work like any other ALGOL language. It is possible to make some objects behave in a lazy way, but this is also…

R's evaluation of arguments is lazy, so while not at the level of Haskell it feels like a lazy language to me. Try eg:

  f = function(x) { print('hello'); x }
  f(print('world'))

X is not evaluated in f until referenced. Indeed if you remove x from f, world is not printed.

Re: Generalizing Support for Functional OOP in R

#34

Post by CornCobs » Wed, May 29, 2024, 12:39 AM UTC

Something interesting I realized about their choice of name - S7.

1. It's a combination of S3 and S4 obviously.

2. It's also linked to another OOP system called R6. Interesting how it's a step forward one way (6->7) and a step 'backwards' in another way (S->R).

To me it shows the philosophy of not creating something entirely new but improving the existing systems quite nicely!

Re: Generalizing Support for Functional OOP in R

#35

Post by civilized » Wed, May 29, 2024, 1:01 AM UTC

civilized wrote: post #25

agumonkey wrote: post #16

Earlier quoted context omitted.

> I suspect lazy evaluation is a part of this. I had no idea R was lazy. Makes me wanna learn it now.

R is not lazy. It has non-standard evaluation mechanisms (formulas, promises, quosures...) that enable to you to write domain-specific languages that "do what the user meant". If your code (or the code of the libraries you're using) doesn't use any non-standard evaluation tools, evaluation will be eager and work like any other ALGOL language. It is possible to make some objects behave in a lazy way, but this is also…

Apologies, my bad, but I'm a bit too late to edit. The experts say that R qualifies as a lazy language [1, 2].

My impression was that R was mostly an eager language that somehow allowed for laziness. I will research this further and hopefully suss out why I got confused.

[1] https://dl.acm.org/doi/10.1145/3360579

[2] https://www.r-bloggers.com/2018/07/about-lazy-evaluation/

Re: Generalizing Support for Functional OOP in R

#36

Post by int_19h » Wed, May 29, 2024, 2:22 AM UTC

orhmeh09 wrote: post #4

rossdavidh wrote: post #2

To be honest, OOP never really seemed like a good fit for R. Functional programming is a much more natural fit, given that both it and R come from a mathematical point of view. R is a great language for the mathematical/statistical stuff it was invented to do, but I don't think it will ever be a general-purpose language, and it probably would become worse at its core purpose if it tried to. More work on being easily…

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`.

Re: Generalizing Support for Functional OOP in R

#37

Post by int_19h » Wed, May 29, 2024, 2:27 AM UTC

civilized wrote: post #25

agumonkey wrote: post #16

Earlier quoted context omitted.

> I suspect lazy evaluation is a part of this. I had no idea R was lazy. Makes me wanna learn it now.

R is not lazy. It has non-standard evaluation mechanisms (formulas, promises, quosures...) that enable to you to write domain-specific languages that "do what the user meant". If your code (or the code of the libraries you're using) doesn't use any non-standard evaluation tools, evaluation will be eager and work like any other ALGOL language. It is possible to make some objects behave in a lazy way, but this is also…

R is lazy, because it does not evaluate arguments upon function call unless and until used. It is also unusual in that the function can avoid evaluating the argument at all, and instead ask for the quoted expression that produced it (which can then be evaluated manually at the desired point, or multiple times, or in a different environment etc), but that is orthogonal to laziness.

To be even more precisely, R itself is lazy "all the way through". Because literally every expression in R is syntactic sugar for a function call (including assignments and control structures such as "if"), the only thing that a function can really do with an argument is pass it on to another function, so, strictly speaking, there's no distinction between use and non-use even. It's just that any R function, in order to do something useful, will ultimately call some non-R leaf function implemented in native code, and some of those leaf functions will actually do the eval if they're defined in terms of argument values (e.g. obviously addition needs to do so to actually compute the value etc).

Re: Generalizing Support for Functional OOP in R

#38

Post by int_19h » Wed, May 29, 2024, 2:32 AM UTC

epgui wrote: post #21

PheonixPharts wrote: post #14

Earlier quoted context omitted.

Functional programming is not orthogonal to object oriented programming, they are paradigms that can be used together and the popular object system developed in Java is not close to the only way to do OOP. R, like Common Lisp, uses an OOP system based on generic functions (well, one of many OOP systems in R, but that's a different topic), where the function handles dispatching to match the object. Effectively instead…

> Effectively instead of object.method() you have method(object) This reflects a very deep misunderstanding of the distinctive characteristics of each paradigm. It's so far off that it's "not even wrong". Functional programming is much more about things like purity and referential transparency, about composing functions and/or combinators, about a particular way of managing or modelling effects, about a way of thinki…

What GP is saying is that while Java is object-centric, R (and CLOS etc) is method-centric: you don't have classes with multiple methods, you have generic functions with multiple methods (each of which implements that function for particular argument types): http://adv-r.had.co.nz/OO-essentials.html#s3

This is not about functional programming at all; the distinction here is completely orthogonal to that.

Re: Generalizing Support for Functional OOP in R

#39

Post by barfbagginus » Wed, May 29, 2024, 2:34 AM UTC

orhmeh09 wrote: post #4

rossdavidh wrote: post #2

To be honest, OOP never really seemed like a good fit for R. Functional programming is a much more natural fit, given that both it and R come from a mathematical point of view. R is a great language for the mathematical/statistical stuff it was invented to do, but I don't think it will ever be a general-purpose language, and it probably would become worse at its core purpose if it tried to. More work on being easily…

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…

Pathlib gives a decent oop interface to most file operations. The pathlib docs has a handy Rosetta Stone table for replacing `os` and `shutil` invocations which is very handy.

It could still be better, and sadly being in the stdlib means it probably won't be improved.

For example, we still need shutil.rmtree to recursively nuke a directory. The pathlib way of doing it is laborious and error prone: https://stackoverflow.com/questions/13118029/deleting-folder...

Re: Generalizing Support for Functional OOP in R

#40

Post by [deleted] » Wed, May 29, 2024, 3:14 AM UTC

epgui wrote: post #21

PheonixPharts wrote: post #14

Earlier quoted context omitted.

Functional programming is not orthogonal to object oriented programming, they are paradigms that can be used together and the popular object system developed in Java is not close to the only way to do OOP. R, like Common Lisp, uses an OOP system based on generic functions (well, one of many OOP systems in R, but that's a different topic), where the function handles dispatching to match the object. Effectively instead…

> Effectively instead of object.method() you have method(object) This reflects a very deep misunderstanding of the distinctive characteristics of each paradigm. It's so far off that it's "not even wrong". Functional programming is much more about things like purity and referential transparency, about composing functions and/or combinators, about a particular way of managing or modelling effects, about a way of thinki…

[deleted]