You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2003/01/03 02:31:44 UTC
[functor] Next step
One good thing this series of discussions has shown is that there is a lot
of interest in functors. Rodney, Stephen and Costin have all shown
creative input in this set of mail, and the original authors of functors
[Ola? Stephen? Steven? others?] obviously also have shown that input.
I believe that:
1) IFF [functor] is to see its scope widen very soon, ie) Costin's ideas,
then it should form its own project. Functor with a lot of mail arguing,
increase in size and a big need for good documentation will quickly become
the pig in [lang]'s belly.
2) IFF [functor] is seen to be pretty much complete, then it should go
into [lang], to be promoted out IFF it is shown to grow in scope at a
later date.
[IFF = if and only if]
I would like to suggest that those involved in [functor] should discuss
the future of [functor] as a series of functionalities and concepts, and
not as a position. Forget where it lives and just argue the cool Java-ness
of it all. Then when you're deep in there, look around and see what feels
right.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [functor] Next step
Posted by Costin Manolache <cm...@yahoo.com>.
Rodney Waldhoff wrote:
> ...
> Functors are a (arguably *the*) central organizing principle behind
> functional programming languages like these.
And that's the reason why commons-functor needs to be aproached as a
fundamental interface, and we should require a very strong support and
participation across Apache in it's implementation.
Functor may affect all apache java projects - must extension mechanisms can
be implemented using functors. Each apache project defines 2-3 callback
mechanisms.
In order for this to happen they need to be flexible and powerfull enough
to cover the existing patterns, and provide at least the same features
as found in the various projects.
One thing I wouldn't want to see is "yet another callback mechanism".
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [functor] Next step
Posted by Stephen Colebourne <sc...@btopenworld.com>.
A useful selection of links below. They help clarify in my own mind why I
believe what I do.
Aims
------
The wiki link (http://c2.com/cgi/wiki?BlocksInJava) and the JGL perhaps
demonstrate functors done fully. Predicate, UnaryPredicate, BinaryPredicate
et al. Which is fine....However some of the others are examples of those
that have caused problems before, notably Avalon code (re [pattern]). Once
bitten, twice shy.
So, it comes down to what do you want to achieve with functors in commons.
The existing package has the aims of
- providing the interface
- providing a consistent exception technique
- providing the most commonly used implementations (over 50 I should think,
I haven't counted)
- sticking to the simple interfaces that arose in [collections]
The existing functor interfaces are
Predicate Object-->boolean
Transformer Object-->Object
Executor Object-->void
Factory void-->Object
IMO there should be one more to complete the set
Enumerator Object-->int
These are really simple conceptually.
History
--------
My original goal with functors was to extract code from [collections] and
place it somewhere sharable for [io] and other components. Ironically, if I
had just coded within [collections], there would have been virtually no
arguments.
The initial location for the extracted functors was [pattern], where I tried
to grow it with extra functors. That failed, creating serious religious wars
and shaping my views of OSS. I believe attempting it again will also fail.
What next
-----------
The existing package is compact, simple to understand, yet powerful (High
power to conceptual weight).
The functors described in the wiki are undoubtably clever, but they are
much, much more complex to grasp. IMO, they are a religion, aka framework.
So functors along the lines of the wiki would clearly NOT be in-scope for
[lang].
Commons might choose to create an [advanced-functor] for these advanced
functors. I appeal to all however, to *_keep_the_simple_
functors_separate_from_any_advanced_ones_*.
The advanced ones will be religious, theoretical and spark endless debate.
Or, to put it another way, the simple functors appeal to me as a developer
and a user, the advanced ones do not.
This is exactly the same as the whole argument for [lang]. It does the
simple, basic stuff. Other components do the more advanced stuff. See
separate thread on [lang] scope.
Stephen
----- Original Message -----
From: "Rodney Waldhoff" <rw...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Friday, January 03, 2003 11:39 PM
Subject: Re: [functor] Next step
> There is, by the way, a rather detailed presentation of one
> implementation of functors in java at
<http://c2.com/cgi/wiki?BlocksInJava>.
>
> On Fri, 3 Jan 2003, Rodney Waldhoff wrote:
>
> > On Fri, 3 Jan 2003, Henri Yandell wrote:
> >
> > > As they apply to Java, is there anyone who has created a library
without
> > > needed preprocessors/other-compilers? If not, then I think the people
I
> > > list form a fine list to discuss it.
> >
> > Yes, of course. Frankly I'm not aware of any functor library for java
> > that requires a pre-processor or other compiler. (Functors are often
> > useful when implementing things like compilers and interpreters. Is that
> > what you're thinking of?)
> >
> > Here's some utility libraries that implement generic functors:
> >
> > * JGL - available from
<http://www.recursionsw.com/products/jgl/jgl.asp>,
> > but there's some old javadocs at
> > <http://www.student.dtu.dk/~ewww/java/doc-jgl/api/packages.html>
> >
> > * Colt -
<http://hoschek.home.cern.ch/hoschek/colt/V1.0.3/doc/cern/colt/function/pack
age-summary.html>
> >
> > * Orbital -
<http://wwwstud.ira.uka.de/~s_platze/orbital/Orbital-doc/api/overview-summar
y.html>
> >
> > * JUtil -
<http://org-jutil.sourceforge.net/doc/coal/0.2/org/jutil/predicate/package-s
ummary.html>
> >
> > * Avalon -
<http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/activity/p
ackage-summary.html
> > (also in Turbine/Stratum
> >
<http://jakarta.apache.org/turbine/stratum/apidocs/org/apache/stratum/lifecy
cle/package-summary.html>)
> >
> > * The JDK -
(<http://java.sun.com/j2se/1.4/docs/api/java/lang/Runnable.html>,
> > <http://java.sun.com/j2se/1.4/docs/api/java/util/Comparator.html>)
> >
> > Here some more examples of generic functors, a bit more buried and
> > seemingly intended for internal use:
> >
> > *
<http://nagoya.apache.org/gump/javadoc/jakarta-ant/build/javadocs/org/apache
/tools/ant/taskdefs/condition/Condition.html>
> > * <http://gef.tigris.org/v0.6/docs/api/uci.util.Predicate.html>
> > * <http://gef.tigris.org/v0.6/docs/api/uci.util.Functor.html>
> > *
<http://www.japisoft.com/formula/javadoc/com/japisoft/formula/lib/standard/A
bstractFunction.html>
> > * <http://www.gjt.org/javadoc/org/gjt/rm/util/Task.html>
> > * <http://www.mpi-sb.mpg.de/~hubert/PS96-97/documents/java/mvc9.html>
> > * <http://www.mpi-sb.mpg.de/~hubert/PS96-97/documents/java/mvc10.html>
> >
> > Here's some examples of specialized applications of or extensions the
> > functor idiom:
> >
> > * <http://java.sun.com/j2se/1.4/docs/api/java/io/FileFilter.html>
> > *
<http://nagoya.apache.org/gump/javadoc/jakarta-ant/build/javadocs/org/apache
/tools/ant/Task.html>
> > *
<http://jakarta.apache.org/turbine/turbine-3/apidocs/org/apache/turbine/modu
les/Action.html>
> > * <http://kweelt.sourceforge.net/docs/api/xacute/common/Predicate.html>
> > * <http://axion.tigris.org/nonav/api/org/axiondb/Selectable.html>
> > * <http://axion.tigris.org/nonav/api/org/axiondb/WhereNode.html>
> > *
<http://jakarta.apache.org/commons/sandbox/jelly/apidocs/org/apache/commons/
jelly/expression/Expression.html>
> >
> > (all these from memory and/or a few quick google searches)
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [functor] Next step
Posted by Rodney Waldhoff <rw...@apache.org>.
There is, by the way, a rather detailed presentation of one
implementation of functors in java at <http://c2.com/cgi/wiki?BlocksInJava>.
On Fri, 3 Jan 2003, Rodney Waldhoff wrote:
> On Fri, 3 Jan 2003, Henri Yandell wrote:
>
> > As they apply to Java, is there anyone who has created a library without
> > needed preprocessors/other-compilers? If not, then I think the people I
> > list form a fine list to discuss it.
>
> Yes, of course. Frankly I'm not aware of any functor library for java
> that requires a pre-processor or other compiler. (Functors are often
> useful when implementing things like compilers and interpreters. Is that
> what you're thinking of?)
>
> Here's some utility libraries that implement generic functors:
>
> * JGL - available from <http://www.recursionsw.com/products/jgl/jgl.asp>,
> but there's some old javadocs at
> <http://www.student.dtu.dk/~ewww/java/doc-jgl/api/packages.html>
>
> * Colt - <http://hoschek.home.cern.ch/hoschek/colt/V1.0.3/doc/cern/colt/function/package-summary.html>
>
> * Orbital - <http://wwwstud.ira.uka.de/~s_platze/orbital/Orbital-doc/api/overview-summary.html>
>
> * JUtil - <http://org-jutil.sourceforge.net/doc/coal/0.2/org/jutil/predicate/package-summary.html>
>
> * Avalon - <http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/activity/package-summary.html
> (also in Turbine/Stratum
> <http://jakarta.apache.org/turbine/stratum/apidocs/org/apache/stratum/lifecycle/package-summary.html>)
>
> * The JDK - (<http://java.sun.com/j2se/1.4/docs/api/java/lang/Runnable.html>,
> <http://java.sun.com/j2se/1.4/docs/api/java/util/Comparator.html>)
>
> Here some more examples of generic functors, a bit more buried and
> seemingly intended for internal use:
>
> * <http://nagoya.apache.org/gump/javadoc/jakarta-ant/build/javadocs/org/apache/tools/ant/taskdefs/condition/Condition.html>
> * <http://gef.tigris.org/v0.6/docs/api/uci.util.Predicate.html>
> * <http://gef.tigris.org/v0.6/docs/api/uci.util.Functor.html>
> * <http://www.japisoft.com/formula/javadoc/com/japisoft/formula/lib/standard/AbstractFunction.html>
> * <http://www.gjt.org/javadoc/org/gjt/rm/util/Task.html>
> * <http://www.mpi-sb.mpg.de/~hubert/PS96-97/documents/java/mvc9.html>
> * <http://www.mpi-sb.mpg.de/~hubert/PS96-97/documents/java/mvc10.html>
>
> Here's some examples of specialized applications of or extensions the
> functor idiom:
>
> * <http://java.sun.com/j2se/1.4/docs/api/java/io/FileFilter.html>
> * <http://nagoya.apache.org/gump/javadoc/jakarta-ant/build/javadocs/org/apache/tools/ant/Task.html>
> * <http://jakarta.apache.org/turbine/turbine-3/apidocs/org/apache/turbine/modules/Action.html>
> * <http://kweelt.sourceforge.net/docs/api/xacute/common/Predicate.html>
> * <http://axion.tigris.org/nonav/api/org/axiondb/Selectable.html>
> * <http://axion.tigris.org/nonav/api/org/axiondb/WhereNode.html>
> * <http://jakarta.apache.org/commons/sandbox/jelly/apidocs/org/apache/commons/jelly/expression/Expression.html>
>
> (all these from memory and/or a few quick google searches)
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [functor] Next step
Posted by Rodney Waldhoff <rw...@apache.org>.
On Fri, 3 Jan 2003, Henri Yandell wrote:
> As they apply to Java, is there anyone who has created a library without
> needed preprocessors/other-compilers? If not, then I think the people I
> list form a fine list to discuss it.
Yes, of course. Frankly I'm not aware of any functor library for java
that requires a pre-processor or other compiler. (Functors are often
useful when implementing things like compilers and interpreters. Is that
what you're thinking of?)
Here's some utility libraries that implement generic functors:
* JGL - available from <http://www.recursionsw.com/products/jgl/jgl.asp>,
but there's some old javadocs at
<http://www.student.dtu.dk/~ewww/java/doc-jgl/api/packages.html>
* Colt - <http://hoschek.home.cern.ch/hoschek/colt/V1.0.3/doc/cern/colt/function/package-summary.html>
* Orbital - <http://wwwstud.ira.uka.de/~s_platze/orbital/Orbital-doc/api/overview-summary.html>
* JUtil - <http://org-jutil.sourceforge.net/doc/coal/0.2/org/jutil/predicate/package-summary.html>
* Avalon - <http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/activity/package-summary.html
(also in Turbine/Stratum
<http://jakarta.apache.org/turbine/stratum/apidocs/org/apache/stratum/lifecycle/package-summary.html>)
* The JDK - (<http://java.sun.com/j2se/1.4/docs/api/java/lang/Runnable.html>,
<http://java.sun.com/j2se/1.4/docs/api/java/util/Comparator.html>)
Here some more examples of generic functors, a bit more buried and
seemingly intended for internal use:
* <http://nagoya.apache.org/gump/javadoc/jakarta-ant/build/javadocs/org/apache/tools/ant/taskdefs/condition/Condition.html>
* <http://gef.tigris.org/v0.6/docs/api/uci.util.Predicate.html>
* <http://gef.tigris.org/v0.6/docs/api/uci.util.Functor.html>
* <http://www.japisoft.com/formula/javadoc/com/japisoft/formula/lib/standard/AbstractFunction.html>
* <http://www.gjt.org/javadoc/org/gjt/rm/util/Task.html>
* <http://www.mpi-sb.mpg.de/~hubert/PS96-97/documents/java/mvc9.html>
* <http://www.mpi-sb.mpg.de/~hubert/PS96-97/documents/java/mvc10.html>
Here's some examples of specialized applications of or extensions the
functor idiom:
* <http://java.sun.com/j2se/1.4/docs/api/java/io/FileFilter.html>
* <http://nagoya.apache.org/gump/javadoc/jakarta-ant/build/javadocs/org/apache/tools/ant/Task.html>
* <http://jakarta.apache.org/turbine/turbine-3/apidocs/org/apache/turbine/modules/Action.html>
* <http://kweelt.sourceforge.net/docs/api/xacute/common/Predicate.html>
* <http://axion.tigris.org/nonav/api/org/axiondb/Selectable.html>
* <http://axion.tigris.org/nonav/api/org/axiondb/WhereNode.html>
* <http://jakarta.apache.org/commons/sandbox/jelly/apidocs/org/apache/commons/jelly/expression/Expression.html>
(all these from memory and/or a few quick google searches)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [functor] Next step
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 3 Jan 2003, Rodney Waldhoff wrote:
> On Thu, 2 Jan 2003, Henri Yandell wrote:
>
> > [functor]'s are about 18 years old it seems. They're not quite ready to
> > live on their own, but they want to be out there it seems. I am happy to
> > accept functors [and the name does seem to fit the pattern [see
> > proposal]] being their own project, but believe they will suffer to
> > start with. They have sufficient size to overcome the slowness of being
> > a new project.
>
> It's funny you should put it that way Hen, because functors have been
> around for literally more than 40 years, and have done very well "out on
> their own". The term "functor" has been applied to this concept for more
> than 20 years, and the concept (and likely the term as well) has been
> around for more than 40. Functors appear:
It was a metaphor! 18 years old as in a teenager leaving home, in terms of
code-maturity and scope.
> Call me an early adopter, but I think that the utility and viability of
> functors is well established.
[functor] different to functor.
> > One good thing this series of discussions has shown is that there is a
> > lot of interest in functors. Rodney, Stephen and Costin have all shown
> > creative input in this set of mail, and the original authors of functors
> > [Ola? Stephen? Steven? others?] obviously also have shown that input.
>
> There is no one on this thread that can claim a notable contribution to
> the concept of functors, myself included of course.
As they apply to Java, is there anyone who has created a library without
needed preprocessors/other-compilers? If not, then I think the people I
list form a fine list to discuss it.
> Also, the folks behind functional programming might take issue with the
> phase "the original authors of functors" as it is applied here. So might
> folks like Rudolf Carnap or Haskell Curry, if they weren't dead for more
> than 20 years.
Sorry, should have been "the original authors of [functor]".
> Commons-lang is not an appropriate place to incubate new commons projects,
> for the reasons including but not limited to those I've previously
> enumerated.
I don't agree with your project concepts. I even have the support of the
charter in this I think [with the exception of the [functor] package].
Going with the spirit of Commons as I understand it:
**
Commons code comes from other Jakarta projects. It does not get written
from scratch, ie) Jelly is a bit of an odd one here and shows that it
really should have grown in Maven and then branched out.
Now, I see no reason why Commons code cannot come from another Jakarta
Commons project. It's ludicrous to suggest that a Commons project
should not grow after joining Commons, so by that criteria there is no
reason that code cannot incubate in a Commons project. Just an
intepretation of the charter though.
**
> [functors] are not especially in need of incubation, there is
> a well established precedence for both how and why to do this, and proven
> value in doing so.
Only because [functor] has already part-incubated in Collections, and then
had more work in the sandbox as [patterns]. Other projects you suggest
such as [math] and [time] are in need of incubation somewhere and I
believe that [lang] is the place for that.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [functor] Next step
Posted by Rodney Waldhoff <rw...@apache.org>.
On Thu, 2 Jan 2003, Henri Yandell wrote:
> [functor]'s are about 18 years old it seems. They're not quite ready to
> live on their own, but they want to be out there it seems. I am happy to
> accept functors [and the name does seem to fit the pattern [see
> proposal]] being their own project, but believe they will suffer to
> start with. They have sufficient size to overcome the slowness of being
> a new project.
It's funny you should put it that way Hen, because functors have been
around for literally more than 40 years, and have done very well "out on
their own". The term "functor" has been applied to this concept for more
than 20 years, and the concept (and likely the term as well) has been
around for more than 40. Functors appear:
* in LISP (late 1950s) as funargs or closures
* in Smalltalk (early 1960s) as blocks and closures
* in Prolog (early 1970s) as functors
* in ML and its variants (early 1980s) as functors
* in Haskell (early 1980s) as a literal keyword "functor"
Functors are a (arguably *the*) central organizing principle behind
functional programming languages like these.
And they have long been popular within the the C family of languages as
well. James Coplien described (but likely didn't invent) the functor idiom
as applied to C++ in _Advanced C++ Programming Styles and Idioms_ (1992).
It's become a part of the STL, RougeWave and other C++ libraries, which in
turn inspired the JGL and a number of other Java implementations (and a
lot of people complain that the "algorithms" aspect of the STL and later
the JGL wasn't part of Java's collections API). The functor concept
continues to be used by newer languages like Ruby (where many people would
argue it's one of the major advantages Ruby has over Java).
Try a google search on "functor" or "functor object" to find dozens of
examples of functors in C++, Java and other languages. Try a citeseer
search on functor (<http://citeseer.nj.nec.com/cs?q=functor>) to find
literally hundreds of examples of the term and concept as used in
literature (and the bulk of the really seminal work on functors predates
internet publication in the large).
Similarly, the term "functor" has been used in category theory with a
related but more constrained meaning for nearly 70 years.
Call me an early adopter, but I think that the utility and viability of
functors is well established.
> One good thing this series of discussions has shown is that there is a
> lot of interest in functors. Rodney, Stephen and Costin have all shown
> creative input in this set of mail, and the original authors of functors
> [Ola? Stephen? Steven? others?] obviously also have shown that input.
There is no one on this thread that can claim a notable contribution to
the concept of functors, myself included of course.
Also, the folks behind functional programming might take issue with the
phase "the original authors of functors" as it is applied here. So might
folks like Rudolf Carnap or Haskell Curry, if they weren't dead for more
than 20 years.
> It seems that [functor] needs to do some soul-searching. If this were a
> company and I were a big-cat CEO [get my shoes Smithers], then I would
> suggest [this is why I'm not a CEO, I think I'm meant to demand or
> order] that those involved start discussing the next step for functor.
>
> IFF [functor] is to see its scope widen very soon, ie) Costin's ideas,
> then it should form its own project. Functor with a lot of mail arguing,
> increase in size and a big need for good documentation will quickly
> become the pig in [lang]'s belly.
>
> IFF [functor] is seen to be pretty much complete, then it should go into
> [lang], to be promoted out IFF it is shown to grow in scope at a later
> date.
Commons-lang is not an appropriate place to incubate new commons projects,
for the reasons including but not limited to those I've previously
enumerated. [functors] are not especially in need of incubation, there is
a well established precedence for both how and why to do this, and proven
value in doing so.
> Hen
- Rod
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>