(1998). Java existed, but neither Scala nor Java-with-generics did.
From the conclusion:
"We have presented a programming protocol, Extensible Visitor, that can be used to construct systems with extensible recursive data domains and toolkits. It is a novel combination of the functional and object-oriented programming styles that draws on the strengths of each. The object-oriented style is essential to achieve extensibility along the data dimension, yet tools are organized in a functional fashion, enabling extensibility in the functional dimension. Systems based on the Extensible Visitor can be extended without modification to existing code or recompilation (which is an increasingly important concern)."
If you insist on doing everything without modifying existing code, what you are doing is throwing new patches of mud onto a growing ball of mud, and that ball of mud is nothing like what you would develop if you had to implement all the current requirements in a blank slate.
Didn't Lisp solve this problem in the 1980's with generic functions and multiple dispatch? I'm referring to the Common Lisp Object System (CLOS), and its predecessors, New Flavors and CommonLoops. I see no mention of this prior art in the paper.
CLOS is an object-oriented system, which solves the problem of adding new functions without modifying existing class definitions, by placing generic functions outside of class definitions.
The paper presents an "Extensible Visitor" pattern that adds functional "processors" to OO datatypes. One interesting part is that, like Kotlin extensions, you do not have to modify existing classes to do so.
While interesting on a surface level, I find this paper curious. What it describes here is essentially a roundabout way to try and express open type associations ("extending the data set" as it calls it) when the class hierarchy is already occupied as a primitive cognate to sum-types. This is more or less just a grammar to express type classes stapled over a class hierarchy grammar. I think the almost pun-like structure of that is funny, but in all actuality this feels pretty needless.
The strangest aspect of it is that they cite Haskell. Given the date of the paper, I would understand unfamiliarity with Haskell given the implementations[1] that were available at the time weren't very "useful" if you had any kind of latency requirements on your software. That being said it's strange that somebody in 1998 would write a paper like this, know that Haskell was a thing, and also have no knowledge of type classes, which are explicitly designed to fill the role of open type sets.
For those note in the know, functional languages tend to be able to express this open type association in various ways. Type classes are one way, another example beyond Haskell is MaPLe[2]. SML (and ML-only style OCAML) has a somewhat restricted form by way of its module and functor system, and eqtype. MLPolyR has an unrestricted form by way of row polymorphism.
(1998). Java existed, but neither Scala nor Java-with-generics did.
From the conclusion:
"We have presented a programming protocol, Extensible Visitor, that can be used to construct systems with extensible recursive data domains and toolkits. It is a novel combination of the functional and object-oriented programming styles that draws on the strengths of each. The object-oriented style is essential to achieve extensibility along the data dimension, yet tools are organized in a functional fashion, enabling extensibility in the functional dimension. Systems based on the Extensible Visitor can be extended without modification to existing code or recompilation (which is an increasingly important concern)."
If you insist on doing everything without modifying existing code, what you are doing is throwing new patches of mud onto a growing ball of mud, and that ball of mud is nothing like what you would develop if you had to implement all the current requirements in a blank slate.
For context, see the recent HN discussion on “The Expression Problem and its solutions”:
https://news.ycombinator.com/item?id=45155877
Didn't Lisp solve this problem in the 1980's with generic functions and multiple dispatch? I'm referring to the Common Lisp Object System (CLOS), and its predecessors, New Flavors and CommonLoops. I see no mention of this prior art in the paper.
CLOS is an object-oriented system, which solves the problem of adding new functions without modifying existing class definitions, by placing generic functions outside of class definitions.
A group of generic functions comprise a protocol of some kind. Sometimes you cannot extend in the way you need without changing the protocol.
The paper presents an "Extensible Visitor" pattern that adds functional "processors" to OO datatypes. One interesting part is that, like Kotlin extensions, you do not have to modify existing classes to do so.
Was this an important paper in its field?
While interesting on a surface level, I find this paper curious. What it describes here is essentially a roundabout way to try and express open type associations ("extending the data set" as it calls it) when the class hierarchy is already occupied as a primitive cognate to sum-types. This is more or less just a grammar to express type classes stapled over a class hierarchy grammar. I think the almost pun-like structure of that is funny, but in all actuality this feels pretty needless.
The strangest aspect of it is that they cite Haskell. Given the date of the paper, I would understand unfamiliarity with Haskell given the implementations[1] that were available at the time weren't very "useful" if you had any kind of latency requirements on your software. That being said it's strange that somebody in 1998 would write a paper like this, know that Haskell was a thing, and also have no knowledge of type classes, which are explicitly designed to fill the role of open type sets.
For those note in the know, functional languages tend to be able to express this open type association in various ways. Type classes are one way, another example beyond Haskell is MaPLe[2]. SML (and ML-only style OCAML) has a somewhat restricted form by way of its module and functor system, and eqtype. MLPolyR has an unrestricted form by way of row polymorphism.
[1] - https://www.haskell.org/hugs/
[2] - https://github.com/MPLLang/mpl