commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [functor] Change default arity of Function, Predicate and Procedure
Date Wed, 13 Feb 2013 15:48:19 GMT
TBH, I can't recall what the argument was against "Functor" either; I think
it had something to do with potentially confusing users of other libraries?

Functor
|_NullaryFunctor
|_UnaryFunctor
|_BinaryFunctor

*is* the current state.  :)  Now, when I woke up this morning I did so with
another concept floating around in my brain (it may be crazy, or not work):

interface Arity {
}

interface Argumented<A extends Arity> {
}

interface Unary<A> extends Arity {
}

interface UnaryFunction<A, T> extends Argumented<Unary<A>> {
}

Bear in mind the goal is to be able to inspect the type of a functor to
determine its arity (momentarily disregarding the fact that this goal is
seeming less worth the trouble all the while :P ).  This approach would
make that a bit more complex, but still seemingly doable.

Thoughts?

Matt

On Wed, Feb 13, 2013 at 4:50 AM, Benedikt Ritter <britter@apache.org> wrote:

> Hi Bruno,
>
>
> 2013/2/12 Bruno P. Kinoshita <kinow@apache.org>
>
> > Hi Benedikt,
> >
> > Thanks for taking a look at the github repo and for posting your thoughts
> > here.
> >
> > If I understand it correctly, your concern is:
> >
> > - In the github repo, a BinaryFunction is a Binary, and a Binary is an
> > Arity.
> >
> > - But at same time, it is intuitive that a BinaryFunction "has" an arity,
> > which is binary.
>
>
> > Is that right? If so, I think it's a question of changing the
> > nomenclature. The issue started because in functional languages like
> > Haskell, a functor has a broader meaning (e.g.: a list is a functor in
> > Haskell [1]).
> >
>
> Yes, I guess it boils down to this :)
> As Matt has pointed out, there does not seem to be a name for the superset
> of things that have an arity and "SomethingThatHasArity" really is a bad
> name :)
>
>
> >
> > Maybe we could revert this changes, or find a better name? I thought
> about
> > something like Operation or Operator, but in project lambda, the
> interface
> > BinaryOperator extends BiFunction [2]. So maybe it would be confusing
> too,
> > if the user was used to Java 8 (assuming both interfaces are released
> with
> > Java 8).
>
>
> Yes, this may confuse users. Better prevent collisions with core java
> terminology.
>
>
> > What do you think? Back to Functors (and maybe document the difference
> > from haskell and [functor]?), or do you have some other name in mind?
> > Academics papers might be a good place to find a better name.
> >
>
> Sorry, as I'm no expert on functional programming I don't know the
> terminology in that domain. The question is, what is the superset of
> Predicates, Functions and Procedures (those are the concepts in [functor]
> that have an arity, right?).
>
> This superset seems to be "functor". I haven't understood yet, why you
> think it is a bad name.
>
> Again: If it practical to just call it Arity, then you should go ahead
> (pragmatism wins over oo purism ;-)
>
> Benedikt
>
>
> >
> > Thanks!!
> >
> > [1] http://en.wikibooks.org/wiki/Haskell/Applicative_Functors
> > [2]
> >
> http://download.java.net/lambda/b76/docs/api/java/util/function/BinaryOperator.html
> >
> > Bruno P. Kinoshita
> > http://kinoshita.eti.br
> > http://tupilabs.com
> >
> >
> > ----- Original Message -----
> > > From: Benedikt Ritter <britter@apache.org>
> > > To: Commons Developers List <dev@commons.apache.org>
> > > Cc:
> > > Sent: Tuesday, February 12, 2013 2:45 PM
> > > Subject: Re: [functor] Change default arity of Function, Predicate and
> > Procedure
> > >
> > > Hi Matt,
> > >
> > > 2013/2/12 Matt Benson <gudnabrsam@gmail.com>
> > >
> > >>  Hi Benedikt,
> > >>    So what you are pointing out is the "is a" vs. "has
> > > a" dichotomy?  To an
> > >>  extent, I see your point.  I could argue that the semantics of the
> word
> > >>  "implements" perhaps leaves a bit of so-called wiggle room on the
> > > is a/has
> > >>  a subject.
> > >
> > >
> > > Now we are mixing things up. I was referring to the inheritance
> > > relationships between the interfaces.
> > >
> > > The java "implements" keyword is a different concept. Indeed, I'm
> > > not sure
> > > if it (or the notion of Interfaces) is part of the OO paradigm at all.
> > > There is an interesting paper about this topic (what are the core
> > conecpts
> > > of object orientation?) [1]...
> > >
> > > Anyway the reason I'm bringing this rather academic topic up is, that I
> > > believe that a clear object-orient design will lead to a better (=
> easier
> > > to understand) API. People will work with the API. They will browse the
> > > type hierarchy to understand how things are tied together.
> > > This will lead to situations like: "okay, I have a BinaryFunction...
> what
> > > is a BinaryFuncation? Ah, it's a Binary... what is a Binary? A Binary
> > seems
> > > to be an Arity... wait.. what?"
> > >
> > > Maybe I can make myself clearer by giving a less abstract example.
> > > Consider the following set of thinks: Cars, Trucks, Motorcycles.
> > > They all have wheels of some sort. How would you model this using
> > > Interfaces?
> > > I'm sure you wouldn't define an interface "Wheel" that is
> > > extended by Car,
> > > Truck and Motorcycle.
> > > Instead you would probably define "Vehicle" with a
> > > "getNumberOfWheels()"
> > > method and let Car, Truck and Motorcycle extend Vehicle.
> > > This is what I meant when I said "Arity is not a superset of
> > > functors". it
> > > is a property, like the number of Wheels is a property of all vehicles.
> > >
> > > Again, this is all very academic. If you see it fit to create Arity and
> > > have the different functors extend it, then do it :-)
> > >
> > >
> > >>  This could devolve into a long discussion of the most
> > >>  semantically correct place to use "implements Arity*" vs.
> > > "extends Arity*"
> > >>  throughout the API, but the final result, IMO, is that the intent of
> > any
> > >>  given concrete class is clear enough, and
> Arity|Nullary|Unary|Binary|ad
> > >>  infinitum seems more convenient than e.g.
> > > "SomethingThatHasArity", etc.
> > >>
> > >
> > > I agree!
> > >
> > >
> > >>
> > >>  Does that make sense?
> > >>
> > >
> > > As I said, I think pragmatism should win over OO purism :)
> > >
> > >
> > >>
> > >>  Matt
> > >>
> > >
> > > Benedikt
> > >
> > > [1] http://dl.acm.org/citation.cfm?id=1113040
> > >
> > >>
> > >>
> > >>  On Tue, Feb 12, 2013 at 7:29 AM, Benedikt Ritter <britter@apache.org
> >
> > >>  wrote:
> > >>
> > >>  > Hi Guys,
> > >>  >
> > >>  > I've had a look at the github repo and let me say at first that
> > > I'm no
> > >>  > expert in functional programming. So maybe what I'm talking is
> > > complete
> > >>  > nonsense :)
> > >>  >
> > >>  > From what I learned about the concept of arity at wikipedia it
> seems
> > > that
> > >>  > an arity is a property of a functor.
> > >>  > One could say: "A binary functor has an arity of two"
> > > (right?!)
> > >>  >
> > >>  > In the github repo you introduced an inheritance relationship
> between
> > >>  > functors and arity.
> > >>  > This maybe a good thing to do from a pracmatic POV because all
> > > functors
> > >>  > share the fact that say have an arity.
> > >>  >
> > >>  > From an object oriented POV inheritance is more then pure reuse.
> When
> > >>  > defining an inheritance relationship between concept Super and
> > concept
> > >>  Sub
> > >>  > we basically say "Every instance of Sub is also an instance of
> > > Super" or
> > >>  > short "Every Sub is also a Super"
> > >>  >
> > >>  > Now coming back to functors you have introduced a relationship that
> > > says
> > >>  > "Every BinaryFunction is a Binary and every Binary is an
> > > Arity".
> > >>  > Keeping in mind that arity is only a property of a functor (rather
> > > than a
> > >>  > superset) this seems strange (from an OO POV).
> > >>  > But as I'm no expert on functional programming this maybe the
> > > right thing
> > >>  > to do... :)
> > >>  >
> > >>  > just my 2 cents :)
> > >>  > Benedikt
> > >>  >
> > >>  >
> > >>  >
> > >>  > 2013/2/11 Bruno P. Kinoshita <kinow@apache.org>
> > >>  >
> > >>  > > Hi Matt!
> > >>  > >
> > >>  > > Great! I'll commit these changes tomorrow if there are no
> > > objections.
> > >>  > >
> > >>  > > Thanks!
> > >>  > >
> > >>  > > Bruno P. Kinoshita
> > >>  > > http://kinoshita.eti.br
> > >>  > > http://tupilabs.com
> > >>  > >
> > >>  > >
> > >>  > > ----- Original Message -----
> > >>  > > > From: Matt Benson <gudnabrsam@gmail.com>
> > >>  > > > To: Commons Developers List <dev@commons.apache.org>
> > >>  > > > Cc:
> > >>  > > > Sent: Monday, February 11, 2013 8:39 PM
> > >>  > > > Subject: Re: [functor] Change default arity of Function,
> > > Predicate
> > >>  and
> > >>  > > Procedure
> > >>  > > >
> > >>  > > > Hi Bruno,
> > >>  > > >   No objections here about the Arity interfaces.  I see
that
> > > your
> > >>  > master
> > >>  > > > branch also contains changes to migrate Unary* to * and
* to
> > >>  Nullary*.
> > >>  > > > Personally I am satisfied to align with lambda/guava if
> > > noone else
> > >>  > > objects.
> > >>  > > >
> > >>  > > > Thanks,
> > >>  > > > Matt
> > >>  > > >
> > >>  > > >
> > >>  > > > On Mon, Feb 11, 2013 at 4:25 PM, Bruno P. Kinoshita <
> > >>  > > > brunodepaulak@yahoo.com.br> wrote:
> > >>  > > >
> > >>  > > >>  Hi Matt, all,
> > >>  > > >>
> > >>  > > >>  I'm messing with [functor] in my GitHub mirror [1].
> > > You can find
> > >>  the
> > >>  > > >>  commits in the master branch [2].
> > >>  > > >>
> > >>  > > >>  The Arity->Unary/Binary/Nullary interfaces look
> > > good. If there are
> > >>  no
> > >>  > > >>  objections I would like to commit this change to the
> > > trunk in SVN.
> > >>  > > >>
> > >>  > > >>  There are other changes that I'll omit in this
> > > commit, but will
> > >>  start
> > >>  > > > new
> > >>  > > >>  threads here in the mailing list :o)
> > >>  > > >>
> > >>  > > >>  Thank you in advance!
> > >>  > > >>
> > >>  > > >>  [1] https://github.com/kinow/functor
> > >>  > > >>  [2] https://github.com/kinow/functor/commits/master
> > >>  > > >>
> > >>  > > >>  Bruno P. Kinoshita
> > >>  > > >>  http://kinoshita.eti.br
> > >>  > > >>  http://tupilabs.com
> > >>  > > >>
> > >>  > > >>
> > >>  > > >>  >________________________________
> > >>  > > >>  > From: Bruno P. Kinoshita <kinow@apache.org>
> > >>  > > >>  >To: Commons Developers List
> > > <dev@commons.apache.org>; "
> > >>  > > >>  gudnabrsam@gmail.com" <gudnabrsam@gmail.com>
> > >>  > > >>  >Sent: Wednesday, January 30, 2013 3:58 PM
> > >>  > > >>  >Subject: Re: [functor] Change default arity of
> > > Function, Predicate
> > >>  > and
> > >>  > > >>  Procedure
> > >>  > > >>  >
> > >>  > > >>  >I think it makes sense and is clear what is does.
> > >>  > > >>  >
> > >>  > > >>  >I thought in using {arity}Operation, but in Java
8
> > > there are
> > >>  > > interfaces
> > >>  > > >>  like BinaryOperator, and BinaryOperator extends
> > > BiFunction, so it
> > >>  > > would be
> > >>  > > >>  confusing to users having something like interface
> > > BinaryFunction
> > >>  > > extends
> > >>  > > >>  BinaryOperation in [functor].
> > >>  > > >>  >
> > >>  > > >>  >Bruno P. Kinoshita
> > >>  > > >>  >http://kinoshita.eti.br
> > >>  > > >>  >http://tupilabs.com
> > >>  > > >>  >
> > >>  > > >>  >
> > >>  > > >>  >----- Original Message -----
> > >>  > > >>  >> From: Matt Benson <gudnabrsam@gmail.com>
> > >>  > > >>  >> To: Bruno P. Kinoshita
> > > <brunodepaulak@yahoo.com.br>
> > >>  > > >>  >> Cc: Commons Developers List
> > > <dev@commons.apache.org>
> > >>  > > >>  >> Sent: Wednesday, January 30, 2013 1:29 PM
> > >>  > > >>  >> Subject: Re: [functor] Change default arity
of
> > > Function,
> > >>  Predicate
> > >>  > > > and
> > >>  > > >>  Procedure
> > >>  > > >>  >>
> > >>  > > >>  >> What about:
> > >>  > > >>  >>
> > >>  > > >>  >> Arity (Marker)
> > >>  > > >>  >> |_Nullary extends Arity
> > >>  > > >>  >> |_Unary<A> extends Arity
> > >>  > > >>  >> |_Binary<L, R> extends Arity
> > >>  > > >>  >>
> > >>  > > >>  >> ?
> > >>  > > >>  >>
> > >>  > > >>  >> Matt
> > >>  > > >>  >>
> > >>  > > >>  >>
> > >>  > > >>  >> On Tue, Jan 29, 2013 at 6:09 PM, Bruno P.
> > > Kinoshita <
> > >>  > > >>  >> brunodepaulak@yahoo.com.br> wrote:
> > >>  > > >>  >>
> > >>  > > >>  >>>  In Haskell you define your functions
and
> > > its arity.
> > >>  > > >>  >>>
> > >>  > > >>  >>>  // nullary function
> > >>  > > >>  >>>  a :: () => () -> String
> > >>  > > >>  >>>  a = "Hello World"
> > >>  > > >>  >>>
> > >>  > > >>  >>>  // unary function
> > >>  > > >>  >>>  b :: (Integral c) => c -: String
> > >>  > > >>  >>>  b x = "Hello Integral"
> > >>  > > >>  >>>
> > >>  > > >>  >>>  I think in Clojure and Scala you can
> > > define the arity of the
> > >>  > > > function
> > >>  > > >>  too.
> > >>  > > >>  >>>
> > >>  > > >>  >>>  For the users of [functor] I think it
> > > would be easier to
> > >>  > > > migrate their
> > >>  > > >>  >>>  code to Java 8, or use it with Java
8, if
> > > both [functor] and
> > >>  > > > Java 8
> > >>  > > >>  >>>  Function classes had similar behaviour.
> > > That would be
> > >>  > > > interesting
> > >>  > > >>  >>>  especially if the lambda project provided
> > > a backport jar.
> > >>  > > >>  >>>
> > >>  > > >>  >>>  [functor] and lambda project provide
1
> > > and 2 arities by
> > >>  > > > default, but
> > >>  > > >>  >>>  lambda doesn't provide nullary
> > > interfaces (or at least I
> > >>  > > > couldn't
> > >>  > > >>  >> find them
> > >>  > > >>  >>>  in java.util.functions).
> > >>  > > >>  >>>
> > >>  > > >>  >>>  Cheers
> > >>  > > >>  >>>
> > >>  > > >>  >>>  Bruno P. Kinoshita
> > >>  > > >>  >>>  http://kinoshita.eti.br
> > >>  > > >>  >>>  http://tupilabs.com
> > >>  > > >>  >>>
> > >>  > > >>  >>>
> > >>  > > >>  >>>  ----- Original Message -----
> > >>  > > >>  >>>  > From: Matt Benson
> > > <gudnabrsam@gmail.com>
> > >>  > > >>  >>>  > To: Commons Developers List
> > >>  > > > <dev@commons.apache.org>; Bruno P.
> > >>  > > >>  >>>  Kinoshita
> > > <brunodepaulak@yahoo.com.br>
> > >>  > > >>  >>>  > Cc:
> > >>  > > >>  >>>  > Sent: Tuesday, January 29, 2013
8:57
> > > PM
> > >>  > > >>  >>>  > Subject: Re: [functor] Change
> > > default arity of Function,
> > >>  > > > Predicate
> > >>  > > >>  and
> > >>  > > >>  >>>  Procedure
> > >>  > > >>  >>>  >
> > >>  > > >>  >>>  > What about in pure functional
> > > languages e.g. Haskell?
> > >>  > > >>  >>>  >
> > >>  > > >>  >>>  > Matt
> > >>  > > >>  >>>  >
> > >>  > > >>  >>>  >
> > >>  > > >>  >>>  > On Tue, Jan 29, 2013 at 4:55 PM,
> > > Bruno P. Kinoshita <
> > >>  > > >>  >>>  > brunodepaulak@yahoo.com.br>
> > > wrote:
> > >>  > > >>  >>>  >
> > >>  > > >>  >>>  >>  Hi all,
> > >>  > > >>  >>>  >>
> > >>  > > >>  >>>  >>  In Java 8 and Guava the default
> > > arity of a Function
> > >>  > > > is 1, but in
> > >>  > > >>  >>>  [functor]
> > >>  > > >>  >>>  >>  it is 0, IOW, in Java 8 and
> > > Guava a Function is by
> > >>  > > > default a
> > >>  > > >>  >>>  UnaryFunction,
> > >>  > > >>  >>>  >>  while in [functor] it is a
> > > NullaryFunction.
> > >>  > > >>  >>>  >>
> > >>  > > >>  >>>  >>  What do you guys think of
> > > changing the default
> > >>  > > > arity of Function,
> > >>  > > >>  >>>  >>  Procedure and Predicate in
> > > [functor] to 1, rather
> > >>  > > > than 0?
> > >>  > > >>  >>>  >>
> > >>  > > >>  >>>  >>  Cheers
> > >>  > > >>  >>>  >>
> > >>  > > >>  >>>  >>  Bruno P. Kinoshita
> > >>  > > >>  >>>  >>  http://kinoshita.eti.br
> > >>  > > >>  >>>  >>  http://tupilabs.com
> > >>  > > >>  >>>  >>
> > >>  > > >>  >>>  >>
> > >>  > > >>  >>
> > >>  > > >
> > > ---------------------------------------------------------------------
> > >>  > > >>  >>>  >>  To unsubscribe, e-mail:
> > >>  > > > dev-unsubscribe@commons.apache.org
> > >>  > > >>  >>>  >>  For additional commands,
> > > e-mail:
> > >>  > > > dev-help@commons.apache.org
> > >>  > > >>  >>>  >>
> > >>  > > >>  >>>  >>
> > >>  > > >>  >>>  >
> > >>  > > >>  >>>
> > >>  > > >>  >>
> > >>  > > >>  >
> > >>  > > >>
> > >>  >
> > >> ---------------------------------------------------------------------
> > >>  > > >>  >To unsubscribe, e-mail:
> > > dev-unsubscribe@commons.apache.org
> > >>  > > >>  >For additional commands, e-mail:
> > > dev-help@commons.apache.org
> > >>  > > >>  >
> > >>  > > >>  >
> > >>  > > >>  >
> > >>  > > >>  >
> > >>  > > >>
> > >>  > > >
> > >>  > >
> > >>  > >
> > > ---------------------------------------------------------------------
> > >>  > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>  > > For additional commands, e-mail: dev-help@commons.apache.org
> > >>  > >
> > >>  > >
> > >>  >
> > >>  >
> > >>  > --
> > >>  > http://people.apache.org/~britter/
> > >>  > http://www.systemoutprintln.de/
> > >>  > http://twitter.com/BenediktRitter
> > >>  > http://github.com/britter
> > >>  >
> > >>
> > >
> > >
> > >
> > > --
> > > http://people.apache.org/~britter/
> > > http://www.systemoutprintln.de/
> > > http://twitter.com/BenediktRitter
> > > http://github.com/britter
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message