12 ms·

Amusingly horrible question. Functional programming languages don't typically have class-based or prototype mechanisms, so why on earth would a named set of ob

by jherber 18y ago

Amusingly horrible question. Functional programming languages don't typically have class-based or prototype mechanisms, so why on earth would a named set of object interaction mechanisms be relevant - let alone displaceable? I also think it is funny the status quo in language design is to effectively combine objects and functions but programmers and writers are not acknowledging this fusion. Ocaml, Javascript, F#, Scala, Ruby, Nemerle ... with varying ease, these languages all let you create lambdas, compose functions, functions as values. Even mainstream languages like C# and Java are awkwardly moving in this direction. Scala does some crazy stuff to make "fusion" interesting. They allow objects in pattern matching by providing a specific mechanism for allowing an object to expose encapsulated behavior (extractors). Functions all belong to a parametric set of classes and have an "apply" method e.g. def add(x:Int,y:Int) = x+y is really Function2[Int,Int,Int]{ def apply(x:Int,y:Int):Int = x + y }. Likewise, any class or singleton object can invoked as a function by providing an "apply" method implementation.

dangrover 18y ago
I think it's because you can easily make your own object system in a functional language. Make yourself a function (representing an object) that takes in a parameter that it uses to dispatch a function contained in it. Return the function, and the user can then call that with their args. And you still maintain encapsulation, too, because the returned function may access stuff that was only available inside the containing closure (where it was dispatched). Put all of this together in a nice "class" macro, and bam, you've got objects. Though, yeah, I guess this would be really tedious if your functional language didn't have good macros.
- omouse 18y ago
  "And you still maintain encapsulation, too, because the returned function may access stuff that was only available inside the containing closure (where it was dispatched)." That only works if your functions can maintain state and if they can, well they're basically objects aren't they...
  - silentbicycle 18y ago
    Well, strictly speaking, they're closures. There's a lot of overlap between objects and closures, though using one or the other will frame the problem in a slightly different way. See also: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
  - dangrover 18y ago
    That's my point. You don't need to have a separate special construct for objects, or any kind of support for them, when you have first-class functions. As for state information, you could just put a 'let' inside there with your variables, and call mutators on them from inside the "object"'s functions. Hmm, I think all these Scheme-centric classes I've taken have warped my mind. I should seek therapy.
    - apgwoz 18y ago
      > when you have first-class functions. This isn't enough without the ability to close over the lexical environment. See Python pre 3.0, without the dictionary/list "hacks".

by jherber 18y ago

dangrover 18y ago

I think it's because you can easily make your own object system in a functional language. Make yourself a function (representing an object) that takes in a parameter that it uses to dispatch a function contained in it. Return the function, and the user can then call that with their args. And you still maintain encapsulation, too, because the returned function may access stuff that was only available inside the containing closure (where it was dispatched). Put all of this together in a nice "class" macro, and bam, you've got objects. Though, yeah, I guess this would be really tedious if your functional language didn't have good macros.

omouse 18y ago
"And you still maintain encapsulation, too, because the returned function may access stuff that was only available inside the containing closure (where it was dispatched)." That only works if your functions can maintain state and if they can, well they're basically objects aren't they...
- silentbicycle 18y ago
  Well, strictly speaking, they're closures. There's a lot of overlap between objects and closures, though using one or the other will frame the problem in a slightly different way. See also: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
- dangrover 18y ago
  That's my point. You don't need to have a separate special construct for objects, or any kind of support for them, when you have first-class functions. As for state information, you could just put a 'let' inside there with your variables, and call mutators on them from inside the "object"'s functions. Hmm, I think all these Scheme-centric classes I've taken have warped my mind. I should seek therapy.
  - apgwoz 18y ago
    > when you have first-class functions. This isn't enough without the ability to close over the lexical environment. See Python pre 3.0, without the dictionary/list "hacks".