commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [functor] Change default arity of Function, Predicate and Procedure
Date Wed, 13 Feb 2013 10:50:41 GMT
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