Re: [functor] Change default arity of Function, Predicate and Procedure

[Bruno P. Kinoshita]

Hi all, 

If there are no objections, I'll start working on this issue (FUNCTOR-24 [1]) 
and will commit the changes throughout the next days. 

Let me know if you have any thoughts on this, please :) 

Thanks!

[1] https://issues.apache.org/jira/browse/FUNCTOR-24

Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com


--- Em sex, 15/2/13, Bruno P. Kinoshita ki...@apache.org escreveu:

 De: Bruno P. Kinoshita ki...@apache.org
 Assunto: Re: [functor] Change default arity of Function, Predicate and 
 Procedure
 Para: Commons Developers List dev@commons.apache.org, 
 gudnabr...@gmail.com gudnabr...@gmail.com
 Data: Sexta-feira, 15 de Fevereiro de 2013, 15:28
  Wouldn't that technically have
 to be:
  
  public Boolean evaluate(Integer obj) { ...
  
  ?
  
 You're right indeed. 
 
 
  Then the user has to either rely on autoboxing or use
 the object.  While it
  might be nice to have the *option* to use our functors
 interchangeably, it
  feel nice to me that the specialized functor
 interfaces use 
  primitive or
  void return types.
 
 You're right again. Java 8 Predicate interface has a boolean
 test(T t) method, with no autoboxing needed, but it shares
 only the @FunctionalInterface annotation with Function or
 Consumer.
 
 I think we just have to find a good name to the
 superinterface then, or stick with Functor.
  
 
 Bruno P. Kinoshita
 http://kinoshita.eti.br
 http://tupilabs.com
 
 
 - Original Message -
  From: Matt Benson gudnabr...@gmail.com
  To: Bruno P. Kinoshita ki...@apache.org
  Cc: Commons Developers List dev@commons.apache.org
  Sent: Friday, February 15, 2013 3:16 PM
  Subject: Re: [functor] Change default arity of
 Function, Predicate and Procedure
  
  On Fri, Feb 15, 2013 at 11:12 AM, Bruno P. Kinoshita 
  ki...@apache.orgwrote:
  
   Hi Matt,
  
   Thanks for the pointer, I forgot it had
 already been asked here.
  
   Do we want to do this?
  
  
   Indeed that wouldn't be very pleasant for the
 users of [functor] API.
  
  
   But my idea was to have the interfaces in the
 api module extending
   Function, and let users write their own
 implementation, without the need
   for abstract classes... but maybe I'm missing
 something.
  
   I was thinking in:
  
   // Unary predicate
   public interface PredicateT extends
 FunctionT, Boolean {
  
   }
  
   PredicateInteger isLessThanTwo = new
 PredicateInteger() {
  
     public boolean evaluate(Integer obj) {
       return obj != null  obj 
 2;
     }
   };
  
  
  Wouldn't that technically have to be:
  
  public Boolean evaluate(Integer obj) { ...
  
  ?
  
  Then the user has to either rely on autoboxing or use
 the object.  While it
  might be nice to have the *option* to use our functors
 interchangeably, it
  feel nice to me that the specialized functor
 interfaces use 
  primitive or
  void return types.
  
  Matt
  
  
   Instead of test(), we would have to change to
 evaluate() :-/
  
   It's hard to find a good compromise for this.
 And Guava, FunctionalJava
   and Java 8 have no super interface for
 Function/Procedure/Predicate (names
   differ in each API). And our original super
 interface has different
   meanings accross functional programming
 languages :)
  
   Bruno P. Kinoshita
   http://kinoshita.eti.br
   http://tupilabs.com
  
  
   
    From: Matt Benson gudnabr...@gmail.com
   To: Commons Developers List dev@commons.apache.org;
 Bruno P. 
  Kinoshita
   ki...@apache.org
   Sent: Friday, February 15, 2013 2:25 PM
   Subject: Re: [functor] Change default
 arity of Function, Predicate and
   Procedure
   
   Hi Bruno,
     This idea was talked about some time
 ago; Emmanuel Bourg had asked:
   
   why Predicate isn't an extension of
 FunctionBoolean ?
   
   My answer is at
   http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc.
 .
   
   Now, thinking about it more, I feel more
 amenable to the idea of
   everything
   inheriting from a single interface, but
 the fact remains that something
   has
   to be sacrificed to do this.  I suppose
 the least painful approach 
  would
   be
   to implement abstract predicate/procedure
 classes for each supported
   arity;
   these could implement {Arity}Function in
 terms of the abstract method 
  e.g.
   
   public abstract class
 AbstractUnaryPredicateA implements
   UnaryPredicateA {
     public final Boolean evaluate(A
 argument) {
       return
 Boolean.valueOf(test(argument));
     }
   
     public abstract boolean test(A
 argument);
   
   }
   
   Do we want to do this?
   
   Matt
   
   
   On Fri, Feb 15, 2013 at 4:11 AM, Bruno P.
 Kinoshita 
  ki...@apache.org
   wrote:
   
    Hi all,
   
    This thread started after I received
 feedback about [functor] from 
  a FP
    programmer with knowledge in
 Haskell. Among his observations, was 
  that
    Functors in Haskell have a different
 meaning  and using Functors 
  as
    function objects can mislead
 programmers from Haskell, scalaz

Re: [functor] Change default arity of Function, Predicate and Procedure

[Benedikt Ritter]

2013/2/14 Oliver Heger oliver.he...@oliver-heger.de

 Am 14.02.2013 16:51, schrieb Matt Benson:

  I would say that certainly one would often want to create an API like
 you've described.  What I am reluctant not to support is:

 class Foo {
static void add(ArgumentedBinary? extends CharSequence, ? extends
 CharSequence functor);
 }

 Foo.add(new BinaryFunctionString, String, String() {});
 Foo.add(new BinaryProcedureString, StringBuffer() {});
 Foo.add(new BinaryPredicateString, StringBuilder() {});

 The arguments are alike in their argumentedness while having different
 functional interfaces.  Convince me this can never be useful, and we can
 drop the whole thing ;P

 Matt


 Scala seems to use a similar approach: There are traits (a trait is
 something like a more advanced interface in Java) like Function1,
 Function2, ... with type parameters for the argument types and the result
 type.

 The nice thing in Scala is that its syntax allows you to write function
 literals in a pretty comprehensive form. The compiler maps this
 automatically to the corresponding FunctionX trait.

 Oliver


I'd say, let's try Matts proposal out and see how it feels. WDYT?

Benedikt






 On Thu, Feb 14, 2013 at 8:55 AM, Jörg Schaible
 joerg.schai...@scalaris.com**wrote:

  Hi Matt,

 Matt Benson wrote:

  Once again, an enum wouldn't readily be able to contribute to your
 functor's being able to participate in some method by type signature;
 i.e., I want to support the use case of:

 add(ArgumentedBinary somethingThatTakesTwoArguments**);

 Maybe this isn't a worthwhile goal, but so far I don't see anything else
 that accomplishes this.


 In any case, I wonder if we really want to support type safety for the
 argument *types* themselves.

 [snip]


 interface Arity {
 }

 interface ArgumentedA extends Arity {
 }

 interface UnaryA extends Arity {
 }

 interface UnaryFunctionA, T extends ArgumentedUnaryA {
 }


  This is more complicated then having the functors extend Arity, but

 it

 makes better use of inheritance from an OO POV I think.

 Just to make sure I understand correctly: If I had an UnaryFunction
 that take a Boolean argument and return an Integer I would model this
 as: class MyFunction implements UnaryFunctionBoolean, Integer,
 right?


   class Foo {
   static CharSequence add(UnaryFunction? extends CharSequence, ? extends
 CharSequence f);
   }

   Foo.add(new UnaryFunctionString, String(){});
   Foo.add(new UnaryFunctionStringBuilder, String(){});
   Foo.add(new UnaryFunctionStringBuilder, StringBuilder(){});


 This could get really nasty to use.

 - Jörg


 --**--**
 -
 To unsubscribe, e-mail: 
 dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org





 --**--**-
 To unsubscribe, e-mail: 
 dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Change default arity of Function, Predicate and Procedure

[Bruno P. Kinoshita]

Hi all, 

This thread started after I received feedback about [functor] from a FP 
programmer with knowledge in Haskell. Among his observations, was that Functors 
in Haskell have a different meaning  and using Functors as function objects can 
mislead programmers from Haskell, scalaz and other functional programming 
languages. 

However, in C++ a Functor has a meaning similar to [functor] Functor (pun 
inteded :-).

In the beginning I liked the idea to replace it by the Arity interface, but 
after Benedikt's comments, and thinking from a FP programmer coming from 
Haskell, or even from other non pure FP languages like Python or Perl, I think 
it may cause some confusion too. So between Functor and Arity I would now 
prefer Functor.

But there's a third option, that I want to experiment in my GitHub repo too. 
Use the Function interface as the superinterface in [functor]. This was 
suggested to me by the same guy that noticed the use of Functors with different 
meaning. I invited him to join us here in the mailing list, so hopefully he 
will chime in later.

Basically, we would have:

public interface FunctionA, B

public interface PredicateA extends FunctionA, Boolean

public interface ProcedureA extends FunctionA, Void

I have the feeling this could be useful with function currying and function 
folding. I'll experiment with while playing with the adapter and composite 
packages. But I think maybe the Function interface could be indeed used as the 
superinterface, replacing the Functor concept in [functor].

What do you guys think? 

Thank you in advance!

ps: in Java 8, the @FunctionalInterface does not guarantee the arity of 
classes, but raises compile time errors if you define an invalid functional 
interface (like one interface with two abstract public methods). This applies 
to [functor] interfaces, any subclasses of Functor can be annotated with 
@FunctionalInterface and used with lambdas :)

Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com



 From: Benedikt Ritter benerit...@gmail.com
To: Commons Developers List dev@commons.apache.org 
Sent: Friday, February 15, 2013 6:54 AM
Subject: Re: [functor] Change default arity of Function, Predicate and 
Procedure
 
2013/2/14 Oliver Heger oliver.he...@oliver-heger.de

 Am 14.02.2013 16:51, schrieb Matt Benson:

  I would say that certainly one would often want to create an API like
 you've described.  What I am reluctant not to support is:

 class Foo {
    static void add(ArgumentedBinary? extends CharSequence, ? extends
 CharSequence functor);
 }

 Foo.add(new BinaryFunctionString, String, String() {});
 Foo.add(new BinaryProcedureString, StringBuffer() {});
 Foo.add(new BinaryPredicateString, StringBuilder() {});

 The arguments are alike in their argumentedness while having different
 functional interfaces.  Convince me this can never be useful, and we can
 drop the whole thing ;P

 Matt


 Scala seems to use a similar approach: There are traits (a trait is
 something like a more advanced interface in Java) like Function1,
 Function2, ... with type parameters for the argument types and the result
 type.

 The nice thing in Scala is that its syntax allows you to write function
 literals in a pretty comprehensive form. The compiler maps this
 automatically to the corresponding FunctionX trait.

 Oliver


I'd say, let's try Matts proposal out and see how it feels. WDYT?

Benedikt






 On Thu, Feb 14, 2013 at 8:55 AM, Jörg Schaible
 joerg.schai...@scalaris.com**wrote:

  Hi Matt,

 Matt Benson wrote:

  Once again, an enum wouldn't readily be able to contribute to your
 functor's being able to participate in some method by type signature;
 i.e., I want to support the use case of:

 add(ArgumentedBinary somethingThatTakesTwoArguments**);

 Maybe this isn't a worthwhile goal, but so far I don't see anything else
 that accomplishes this.


 In any case, I wonder if we really want to support type safety for the
 argument *types* themselves.

 [snip]


 interface Arity {
 }

 interface ArgumentedA extends Arity {
 }

 interface UnaryA extends Arity {
 }

 interface UnaryFunctionA, T extends ArgumentedUnaryA {
 }


  This is more complicated then having the functors extend Arity, but

 it

 makes better use of inheritance from an OO POV I think.

 Just to make sure I understand correctly: If I had an UnaryFunction
 that take a Boolean argument and return an Integer I would model this
 as: class MyFunction implements UnaryFunctionBoolean, Integer,
 right?


   class Foo {
   static CharSequence add(UnaryFunction? extends CharSequence, ? extends
 CharSequence f);
   }

   Foo.add(new UnaryFunctionString, String(){});
   Foo.add(new UnaryFunctionStringBuilder, String(){});
   Foo.add(new UnaryFunctionStringBuilder, StringBuilder(){});


 This could get really nasty to use.

 - Jörg


 --**--**
 -
 To unsubscribe, e-mail: 
 dev-unsubscribe@commons

Re: [functor] Change default arity of Function, Predicate and Procedure

[Matt Benson]

Hi Bruno,
  This idea was talked about some time ago; Emmanuel Bourg had asked:

why Predicate isn't an extension of FunctionBoolean ?

My answer is at
http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc. .

Now, thinking about it more, I feel more amenable to the idea of everything
inheriting from a single interface, but the fact remains that something has
to be sacrificed to do this.  I suppose the least painful approach would be
to implement abstract predicate/procedure classes for each supported arity;
these could implement {Arity}Function in terms of the abstract method e.g.

public abstract class AbstractUnaryPredicateA implements
UnaryPredicateA {
  public final Boolean evaluate(A argument) {
return Boolean.valueOf(test(argument));
  }

  public abstract boolean test(A argument);

}

Do we want to do this?

Matt


On Fri, Feb 15, 2013 at 4:11 AM, Bruno P. Kinoshita ki...@apache.orgwrote:

 Hi all,

 This thread started after I received feedback about [functor] from a FP
 programmer with knowledge in Haskell. Among his observations, was that
 Functors in Haskell have a different meaning  and using Functors as
 function objects can mislead programmers from Haskell, scalaz and other
 functional programming languages.

 However, in C++ a Functor has a meaning similar to [functor] Functor (pun
 inteded :-).

 In the beginning I liked the idea to replace it by the Arity interface,
 but after Benedikt's comments, and thinking from a FP programmer coming
 from Haskell, or even from other non pure FP languages like Python or Perl,
 I think it may cause some confusion too. So between Functor and Arity I
 would now prefer Functor.

 But there's a third option, that I want to experiment in my GitHub repo
 too. Use the Function interface as the superinterface in [functor]. This
 was suggested to me by the same guy that noticed the use of Functors with
 different meaning. I invited him to join us here in the mailing list, so
 hopefully he will chime in later.

 Basically, we would have:

 public interface FunctionA, B

 public interface PredicateA extends FunctionA, Boolean

 public interface ProcedureA extends FunctionA, Void

 I have the feeling this could be useful with function currying and
 function folding. I'll experiment with while playing with the adapter and
 composite packages. But I think maybe the Function interface could be
 indeed used as the superinterface, replacing the Functor concept in
 [functor].

 What do you guys think?

 Thank you in advance!

 ps: in Java 8, the @FunctionalInterface does not guarantee the arity of
 classes, but raises compile time errors if you define an invalid functional
 interface (like one interface with two abstract public methods). This
 applies to [functor] interfaces, any subclasses of Functor can be annotated
 with @FunctionalInterface and used with lambdas :)

 Bruno P. Kinoshita
 http://kinoshita.eti.br
 http://tupilabs.com


 
  From: Benedikt Ritter benerit...@gmail.com
 To: Commons Developers List dev@commons.apache.org
 Sent: Friday, February 15, 2013 6:54 AM
 Subject: Re: [functor] Change default arity of Function, Predicate and
 Procedure
 
 2013/2/14 Oliver Heger oliver.he...@oliver-heger.de
 
  Am 14.02.2013 16:51, schrieb Matt Benson:
 
   I would say that certainly one would often want to create an API like
  you've described.  What I am reluctant not to support is:
 
  class Foo {
 static void add(ArgumentedBinary? extends CharSequence, ? extends
  CharSequence functor);
  }
 
  Foo.add(new BinaryFunctionString, String, String() {});
  Foo.add(new BinaryProcedureString, StringBuffer() {});
  Foo.add(new BinaryPredicateString, StringBuilder() {});
 
  The arguments are alike in their argumentedness while having
 different
  functional interfaces.  Convince me this can never be useful, and we
 can
  drop the whole thing ;P
 
  Matt
 
 
  Scala seems to use a similar approach: There are traits (a trait is
  something like a more advanced interface in Java) like Function1,
  Function2, ... with type parameters for the argument types and the
 result
  type.
 
  The nice thing in Scala is that its syntax allows you to write function
  literals in a pretty comprehensive form. The compiler maps this
  automatically to the corresponding FunctionX trait.
 
  Oliver
 
 
 I'd say, let's try Matts proposal out and see how it feels. WDYT?
 
 Benedikt
 
 
 
 
 
 
  On Thu, Feb 14, 2013 at 8:55 AM, Jörg Schaible
  joerg.schai...@scalaris.com**wrote:
 
   Hi Matt,
 
  Matt Benson wrote:
 
   Once again, an enum wouldn't readily be able to contribute to your
  functor's being able to participate in some method by type signature;
  i.e., I want to support the use case of:
 
  add(ArgumentedBinary somethingThatTakesTwoArguments**);
 
  Maybe this isn't a worthwhile goal, but so far I don't see anything
 else
  that accomplishes this.
 
 
  In any case, I wonder if we really want to support type safety

Re: [functor] Change default arity of Function, Predicate and Procedure

[Bruno P. Kinoshita]

Hi Matt, 

Thanks for the pointer, I forgot it had already been asked here.

Do we want to do this?


Indeed that wouldn't be very pleasant for the users of [functor] API.


But my idea was to have the interfaces in the api module extending Function, 
and let users write their own implementation, without the need for abstract 
classes... but maybe I'm missing something. 

I was thinking in: 

// Unary predicate
public interface PredicateT extends FunctionT, Boolean {
   
}

PredicateInteger isLessThanTwo = new PredicateInteger() {

  public boolean evaluate(Integer obj) {
    return obj != null  obj  2;
  }
};


Instead of test(), we would have to change to evaluate() :-/

It's hard to find a good compromise for this. And Guava, FunctionalJava and 
Java 8 have no super interface for Function/Procedure/Predicate (names differ 
in each API). And our original super interface has different meanings accross 
functional programming languages :)

Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com



 From: Matt Benson gudnabr...@gmail.com
To: Commons Developers List dev@commons.apache.org; Bruno P. Kinoshita 
ki...@apache.org 
Sent: Friday, February 15, 2013 2:25 PM
Subject: Re: [functor] Change default arity of Function, Predicate and 
Procedure
 
Hi Bruno,
  This idea was talked about some time ago; Emmanuel Bourg had asked:

why Predicate isn't an extension of FunctionBoolean ?

My answer is at
http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc. .

Now, thinking about it more, I feel more amenable to the idea of everything
inheriting from a single interface, but the fact remains that something has
to be sacrificed to do this.  I suppose the least painful approach would be
to implement abstract predicate/procedure classes for each supported arity;
these could implement {Arity}Function in terms of the abstract method e.g.

public abstract class AbstractUnaryPredicateA implements
UnaryPredicateA {
  public final Boolean evaluate(A argument) {
    return Boolean.valueOf(test(argument));
  }

  public abstract boolean test(A argument);

}

Do we want to do this?

Matt


On Fri, Feb 15, 2013 at 4:11 AM, Bruno P. Kinoshita ki...@apache.orgwrote:

 Hi all,

 This thread started after I received feedback about [functor] from a FP
 programmer with knowledge in Haskell. Among his observations, was that
 Functors in Haskell have a different meaning  and using Functors as
 function objects can mislead programmers from Haskell, scalaz and other
 functional programming languages.

 However, in C++ a Functor has a meaning similar to [functor] Functor (pun
 inteded :-).

 In the beginning I liked the idea to replace it by the Arity interface,
 but after Benedikt's comments, and thinking from a FP programmer coming
 from Haskell, or even from other non pure FP languages like Python or Perl,
 I think it may cause some confusion too. So between Functor and Arity I
 would now prefer Functor.

 But there's a third option, that I want to experiment in my GitHub repo
 too. Use the Function interface as the superinterface in [functor]. This
 was suggested to me by the same guy that noticed the use of Functors with
 different meaning. I invited him to join us here in the mailing list, so
 hopefully he will chime in later.

 Basically, we would have:

 public interface FunctionA, B

 public interface PredicateA extends FunctionA, Boolean

 public interface ProcedureA extends FunctionA, Void

 I have the feeling this could be useful with function currying and
 function folding. I'll experiment with while playing with the adapter and
 composite packages. But I think maybe the Function interface could be
 indeed used as the superinterface, replacing the Functor concept in
 [functor].

 What do you guys think?

 Thank you in advance!

 ps: in Java 8, the @FunctionalInterface does not guarantee the arity of
 classes, but raises compile time errors if you define an invalid functional
 interface (like one interface with two abstract public methods). This
 applies to [functor] interfaces, any subclasses of Functor can be annotated
 with @FunctionalInterface and used with lambdas :)

 Bruno P. Kinoshita
 http://kinoshita.eti.br
 http://tupilabs.com


 
  From: Benedikt Ritter benerit...@gmail.com
 To: Commons Developers List dev@commons.apache.org
 Sent: Friday, February 15, 2013 6:54 AM
 Subject: Re: [functor] Change default arity of Function, Predicate and
 Procedure
 
 2013/2/14 Oliver Heger oliver.he...@oliver-heger.de
 
  Am 14.02.2013 16:51, schrieb Matt Benson:
 
   I would say that certainly one would often want to create an API like
  you've described.  What I am reluctant not to support is:
 
  class Foo {
     static void add(ArgumentedBinary? extends CharSequence, ? extends
  CharSequence functor);
  }
 
  Foo.add(new BinaryFunctionString, String, String() {});
  Foo.add(new BinaryProcedureString, StringBuffer() {});
  Foo.add(new

Re: [functor] Change default arity of Function, Predicate and Procedure

[Matt Benson]

On Fri, Feb 15, 2013 at 11:12 AM, Bruno P. Kinoshita ki...@apache.orgwrote:

 Hi Matt,

 Thanks for the pointer, I forgot it had already been asked here.

 Do we want to do this?


 Indeed that wouldn't be very pleasant for the users of [functor] API.


 But my idea was to have the interfaces in the api module extending
 Function, and let users write their own implementation, without the need
 for abstract classes... but maybe I'm missing something.

 I was thinking in:

 // Unary predicate
 public interface PredicateT extends FunctionT, Boolean {

 }

 PredicateInteger isLessThanTwo = new PredicateInteger() {

   public boolean evaluate(Integer obj) {
 return obj != null  obj  2;
   }
 };


Wouldn't that technically have to be:

public Boolean evaluate(Integer obj) { ...

?

Then the user has to either rely on autoboxing or use the object.  While it
might be nice to have the *option* to use our functors interchangeably, it
feel nice to me that the specialized functor interfaces use primitive or
void return types.

Matt


 Instead of test(), we would have to change to evaluate() :-/

 It's hard to find a good compromise for this. And Guava, FunctionalJava
 and Java 8 have no super interface for Function/Procedure/Predicate (names
 differ in each API). And our original super interface has different
 meanings accross functional programming languages :)

 Bruno P. Kinoshita
 http://kinoshita.eti.br
 http://tupilabs.com


 
  From: Matt Benson gudnabr...@gmail.com
 To: Commons Developers List dev@commons.apache.org; Bruno P. Kinoshita
 ki...@apache.org
 Sent: Friday, February 15, 2013 2:25 PM
 Subject: Re: [functor] Change default arity of Function, Predicate and
 Procedure
 
 Hi Bruno,
   This idea was talked about some time ago; Emmanuel Bourg had asked:
 
 why Predicate isn't an extension of FunctionBoolean ?
 
 My answer is at
 http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc. .
 
 Now, thinking about it more, I feel more amenable to the idea of
 everything
 inheriting from a single interface, but the fact remains that something
 has
 to be sacrificed to do this.  I suppose the least painful approach would
 be
 to implement abstract predicate/procedure classes for each supported
 arity;
 these could implement {Arity}Function in terms of the abstract method e.g.
 
 public abstract class AbstractUnaryPredicateA implements
 UnaryPredicateA {
   public final Boolean evaluate(A argument) {
 return Boolean.valueOf(test(argument));
   }
 
   public abstract boolean test(A argument);
 
 }
 
 Do we want to do this?
 
 Matt
 
 
 On Fri, Feb 15, 2013 at 4:11 AM, Bruno P. Kinoshita ki...@apache.org
 wrote:
 
  Hi all,
 
  This thread started after I received feedback about [functor] from a FP
  programmer with knowledge in Haskell. Among his observations, was that
  Functors in Haskell have a different meaning  and using Functors as
  function objects can mislead programmers from Haskell, scalaz and other
  functional programming languages.
 
  However, in C++ a Functor has a meaning similar to [functor] Functor
 (pun
  inteded :-).
 
  In the beginning I liked the idea to replace it by the Arity interface,
  but after Benedikt's comments, and thinking from a FP programmer coming
  from Haskell, or even from other non pure FP languages like Python or
 Perl,
  I think it may cause some confusion too. So between Functor and Arity I
  would now prefer Functor.
 
  But there's a third option, that I want to experiment in my GitHub repo
  too. Use the Function interface as the superinterface in [functor]. This
  was suggested to me by the same guy that noticed the use of Functors
 with
  different meaning. I invited him to join us here in the mailing list, so
  hopefully he will chime in later.
 
  Basically, we would have:
 
  public interface FunctionA, B
 
  public interface PredicateA extends FunctionA, Boolean
 
  public interface ProcedureA extends FunctionA, Void
 
  I have the feeling this could be useful with function currying and
  function folding. I'll experiment with while playing with the adapter
 and
  composite packages. But I think maybe the Function interface could be
  indeed used as the superinterface, replacing the Functor concept in
  [functor].
 
  What do you guys think?
 
  Thank you in advance!
 
  ps: in Java 8, the @FunctionalInterface does not guarantee the arity of
  classes, but raises compile time errors if you define an invalid
 functional
  interface (like one interface with two abstract public methods). This
  applies to [functor] interfaces, any subclasses of Functor can be
 annotated
  with @FunctionalInterface and used with lambdas :)
 
  Bruno P. Kinoshita
  http://kinoshita.eti.br
  http://tupilabs.com
 
 
  
   From: Benedikt Ritter benerit...@gmail.com
  To: Commons Developers List dev@commons.apache.org
  Sent: Friday, February 15, 2013 6:54 AM
  Subject: Re: [functor] Change default arity

Re: [functor] Change default arity of Function, Predicate and Procedure

[Bruno P. Kinoshita]

 Wouldn't that technically have to be:
 
 public Boolean evaluate(Integer obj) { ...
 
 ?
 
You're right indeed. 


 Then the user has to either rely on autoboxing or use the object.  While it
 might be nice to have the *option* to use our functors interchangeably, it
 feel nice to me that the specialized functor interfaces use 
 primitive or
 void return types.

You're right again. Java 8 Predicate interface has a boolean test(T t) method, 
with no autoboxing needed, but it shares only the @FunctionalInterface 
annotation with Function or Consumer.

I think we just have to find a good name to the superinterface then, or stick 
with Functor.
 

Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com


- Original Message -
 From: Matt Benson gudnabr...@gmail.com
 To: Bruno P. Kinoshita ki...@apache.org
 Cc: Commons Developers List dev@commons.apache.org
 Sent: Friday, February 15, 2013 3:16 PM
 Subject: Re: [functor] Change default arity of Function, Predicate and 
 Procedure
 
 On Fri, Feb 15, 2013 at 11:12 AM, Bruno P. Kinoshita 
 ki...@apache.orgwrote:
 
  Hi Matt,
 
  Thanks for the pointer, I forgot it had already been asked here.
 
  Do we want to do this?
 
 
  Indeed that wouldn't be very pleasant for the users of [functor] API.
 
 
  But my idea was to have the interfaces in the api module extending
  Function, and let users write their own implementation, without the need
  for abstract classes... but maybe I'm missing something.
 
  I was thinking in:
 
  // Unary predicate
  public interface PredicateT extends FunctionT, Boolean {
 
  }
 
  PredicateInteger isLessThanTwo = new PredicateInteger() {
 
    public boolean evaluate(Integer obj) {
      return obj != null  obj  2;
    }
  };
 
 
 Wouldn't that technically have to be:
 
 public Boolean evaluate(Integer obj) { ...
 
 ?
 
 Then the user has to either rely on autoboxing or use the object.  While it
 might be nice to have the *option* to use our functors interchangeably, it
 feel nice to me that the specialized functor interfaces use 
 primitive or
 void return types.
 
 Matt
 
 
  Instead of test(), we would have to change to evaluate() :-/
 
  It's hard to find a good compromise for this. And Guava, FunctionalJava
  and Java 8 have no super interface for Function/Procedure/Predicate (names
  differ in each API). And our original super interface has different
  meanings accross functional programming languages :)
 
  Bruno P. Kinoshita
  http://kinoshita.eti.br
  http://tupilabs.com
 
 
  
   From: Matt Benson gudnabr...@gmail.com
  To: Commons Developers List dev@commons.apache.org; Bruno P. 
 Kinoshita
  ki...@apache.org
  Sent: Friday, February 15, 2013 2:25 PM
  Subject: Re: [functor] Change default arity of Function, Predicate and
  Procedure
  
  Hi Bruno,
    This idea was talked about some time ago; Emmanuel Bourg had asked:
  
  why Predicate isn't an extension of FunctionBoolean ?
  
  My answer is at
  http://wiki.apache.org/commons/Sanity%20Check%20of%20APIs%2C%20etc. .
  
  Now, thinking about it more, I feel more amenable to the idea of
  everything
  inheriting from a single interface, but the fact remains that something
  has
  to be sacrificed to do this.  I suppose the least painful approach 
 would
  be
  to implement abstract predicate/procedure classes for each supported
  arity;
  these could implement {Arity}Function in terms of the abstract method 
 e.g.
  
  public abstract class AbstractUnaryPredicateA implements
  UnaryPredicateA {
    public final Boolean evaluate(A argument) {
      return Boolean.valueOf(test(argument));
    }
  
    public abstract boolean test(A argument);
  
  }
  
  Do we want to do this?
  
  Matt
  
  
  On Fri, Feb 15, 2013 at 4:11 AM, Bruno P. Kinoshita 
 ki...@apache.org
  wrote:
  
   Hi all,
  
   This thread started after I received feedback about [functor] from 
 a FP
   programmer with knowledge in Haskell. Among his observations, was 
 that
   Functors in Haskell have a different meaning  and using Functors 
 as
   function objects can mislead programmers from Haskell, scalaz and 
 other
   functional programming languages.
  
   However, in C++ a Functor has a meaning similar to [functor] 
 Functor
  (pun
   inteded :-).
  
   In the beginning I liked the idea to replace it by the Arity 
 interface,
   but after Benedikt's comments, and thinking from a FP 
 programmer coming
   from Haskell, or even from other non pure FP languages like Python 
 or
  Perl,
   I think it may cause some confusion too. So between Functor and 
 Arity I
   would now prefer Functor.
  
   But there's a third option, that I want to experiment in my 
 GitHub repo
   too. Use the Function interface as the superinterface in 
 [functor]. This
   was suggested to me by the same guy that noticed the use of 
 Functors
  with
   different meaning. I invited him to join us here in the mailing 
 list, so
   hopefully he will chime in later.
  
   Basically, we

Re: [functor] Change default arity of Function, Predicate and Procedure

[Benedikt Ritter]

Hi Matt,


2013/2/13 Matt Benson gudnabr...@gmail.com

 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 ArgumentedA extends Arity {
 }

 interface UnaryA extends Arity {
 }

 interface UnaryFunctionA, T extends ArgumentedUnaryA {
 }


This is more complicated then having the functors extend Arity, but it
makes better use of inheritance from an OO POV I think.

Just to make sure I understand correctly: If I had an UnaryFunction that
take a Boolean argument and return an Integer I would model this as:
class MyFunction implements UnaryFunctionBoolean, Integer, right?

May this is obviouse and I just don't get it, but why do you need to define
*ary Interfaces? Wouldn't it be easier to just define:

interface Argumented {
  int getArity()
}

You would lose the information which types can be passed to the functor.
OTOH you don't have to define a new interface for every possible arity.


 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 brit...@apache.org
 wrote:

  Hi Bruno,
 
 
  2013/2/12 Bruno P. Kinoshita ki...@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 brit...@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 gudnabr...@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

Re: [functor] Change default arity of Function, Predicate and Procedure

[Benedikt Ritter]

Hi Jörg,

I like the simplicity annotations can provide.
As Matt has pointed out Annotations do not define types, which makes it
hard to let the compiler do the validation of the code.
We could implement a custom annotation post processor. But that would
require additional setup for users.

Benedikt


2013/2/13 Matt Benson gudnabr...@gmail.com

 Hi Jorg,
   We had at some point talked about whether these could be done with a
 simple annotation.  I had hoped for something that could be expressed in
 terms enforceable by the compiler.

 Matt


 On Wed, Feb 13, 2013 at 10:22 AM, Jörg Schaible 
 joerg.schai...@scalaris.com
  wrote:

  Hi,
 
  Matt Benson wrote:
 
   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 ArgumentedA extends Arity {
   }
  
   interface UnaryA extends Arity {
   }
  
   interface UnaryFunctionA, T extends ArgumentedUnaryA {
   }
  
   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?
 
  @Arity(0)
  interface NullaryFunctor {
  }
 
  @Arity(1)
  interface UnaryFunctor {
  }
 
  @Arity(2)
  interface BinaryFunctor {
  }
 
  Crazy enough? ;-)
 
  Do those interfaces need an ancestor?
 
  - Jörg
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 




-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [functor] Change default arity of Function, Predicate and Procedure

[Jörg Schaible]

Benedikt Ritter wrote:

 Hi Matt,
 
 
 2013/2/13 Matt Benson gudnabr...@gmail.com
 
 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 ArgumentedA extends Arity {
 }

 interface UnaryA extends Arity {
 }

 interface UnaryFunctionA, T extends ArgumentedUnaryA {
 }


 This is more complicated then having the functors extend Arity, but it
 makes better use of inheritance from an OO POV I think.
 
 Just to make sure I understand correctly: If I had an UnaryFunction that
 take a Boolean argument and return an Integer I would model this as:
 class MyFunction implements UnaryFunctionBoolean, Integer, right?
 
 May this is obviouse and I just don't get it, but why do you need to
 define *ary Interfaces? Wouldn't it be easier to just define:
 
 interface Argumented {
   int getArity()
 }
 
 You would lose the information which types can be passed to the functor.
 OTOH you don't have to define a new interface for every possible arity.

You also lose the implicit compile-time check for the arity itself:

class MyFunctionBoolean,Integer extends Argumented {
   int getArity() { return 5; } // blunt lie
...
}

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Change default arity of Function, Predicate and Procedure

[sebb]

On 14 February 2013 09:13, Jörg Schaible joerg.schai...@scalaris.com wrote:
 Benedikt Ritter wrote:

 Hi Matt,


 2013/2/13 Matt Benson gudnabr...@gmail.com

 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 ArgumentedA extends Arity {
 }

 interface UnaryA extends Arity {
 }

 interface UnaryFunctionA, T extends ArgumentedUnaryA {
 }


 This is more complicated then having the functors extend Arity, but it
 makes better use of inheritance from an OO POV I think.

 Just to make sure I understand correctly: If I had an UnaryFunction that
 take a Boolean argument and return an Integer I would model this as:
 class MyFunction implements UnaryFunctionBoolean, Integer, right?

 May this is obviouse and I just don't get it, but why do you need to
 define *ary Interfaces? Wouldn't it be easier to just define:

 interface Argumented {
   int getArity()
 }

 You would lose the information which types can be passed to the functor.
 OTOH you don't have to define a new interface for every possible arity.

 You also lose the implicit compile-time check for the arity itself:

 class MyFunctionBoolean,Integer extends Argumented {
int getArity() { return 5; } // blunt lie
 ...
 }

Would an enum help here?

 - Jörg


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Change default arity of Function, Predicate and Procedure

[Matt Benson]

Once again, an enum wouldn't readily be able to contribute to your
functor's being able to participate in some method by type signature; i.e.,
I want to support the use case of:

add(ArgumentedBinary somethingThatTakesTwoArguments);

Maybe this isn't a worthwhile goal, but so far I don't see anything else
that accomplishes this.

Matt


On Thu, Feb 14, 2013 at 5:15 AM, sebb seb...@gmail.com wrote:

 On 14 February 2013 09:13, Jörg Schaible joerg.schai...@scalaris.com
 wrote:
  Benedikt Ritter wrote:
 
  Hi Matt,
 
 
  2013/2/13 Matt Benson gudnabr...@gmail.com
 
  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 ArgumentedA extends Arity {
  }
 
  interface UnaryA extends Arity {
  }
 
  interface UnaryFunctionA, T extends ArgumentedUnaryA {
  }
 
 
  This is more complicated then having the functors extend Arity, but it
  makes better use of inheritance from an OO POV I think.
 
  Just to make sure I understand correctly: If I had an UnaryFunction that
  take a Boolean argument and return an Integer I would model this as:
  class MyFunction implements UnaryFunctionBoolean, Integer, right?
 
  May this is obviouse and I just don't get it, but why do you need to
  define *ary Interfaces? Wouldn't it be easier to just define:
 
  interface Argumented {
int getArity()
  }
 
  You would lose the information which types can be passed to the functor.
  OTOH you don't have to define a new interface for every possible arity.
 
  You also lose the implicit compile-time check for the arity itself:
 
  class MyFunctionBoolean,Integer extends Argumented {
 int getArity() { return 5; } // blunt lie
  ...
  }

 Would an enum help here?

  - Jörg
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Change default arity of Function, Predicate and Procedure

[Jörg Schaible]

Hi Matt,

Matt Benson wrote:

 Once again, an enum wouldn't readily be able to contribute to your
 functor's being able to participate in some method by type signature;
 i.e., I want to support the use case of:
 
 add(ArgumentedBinary somethingThatTakesTwoArguments);
 
 Maybe this isn't a worthwhile goal, but so far I don't see anything else
 that accomplishes this.

In any case, I wonder if we really want to support type safety for the 
argument *types* themselves.

[snip]

 
  interface Arity {
  }
 
  interface ArgumentedA extends Arity {
  }
 
  interface UnaryA extends Arity {
  }
 
  interface UnaryFunctionA, T extends ArgumentedUnaryA {
  }
 
 
  This is more complicated then having the functors extend Arity, but it
  makes better use of inheritance from an OO POV I think.
 
  Just to make sure I understand correctly: If I had an UnaryFunction
  that take a Boolean argument and return an Integer I would model this
  as: class MyFunction implements UnaryFunctionBoolean, Integer,
  right?

 class Foo {
 static CharSequence add(UnaryFunction? extends CharSequence, ? extends 
CharSequence f);
 }

 Foo.add(new UnaryFunctionString, String(){});
 Foo.add(new UnaryFunctionStringBuilder, String(){});
 Foo.add(new UnaryFunctionStringBuilder, StringBuilder(){});


This could get really nasty to use.

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Change default arity of Function, Predicate and Procedure

[Matt Benson]

I would say that certainly one would often want to create an API like
you've described.  What I am reluctant not to support is:

class Foo {
  static void add(ArgumentedBinary? extends CharSequence, ? extends
CharSequence functor);
}

Foo.add(new BinaryFunctionString, String, String() {});
Foo.add(new BinaryProcedureString, StringBuffer() {});
Foo.add(new BinaryPredicateString, StringBuilder() {});

The arguments are alike in their argumentedness while having different
functional interfaces.  Convince me this can never be useful, and we can
drop the whole thing ;P

Matt


On Thu, Feb 14, 2013 at 8:55 AM, Jörg Schaible
joerg.schai...@scalaris.comwrote:

 Hi Matt,

 Matt Benson wrote:

  Once again, an enum wouldn't readily be able to contribute to your
  functor's being able to participate in some method by type signature;
  i.e., I want to support the use case of:
 
  add(ArgumentedBinary somethingThatTakesTwoArguments);
 
  Maybe this isn't a worthwhile goal, but so far I don't see anything else
  that accomplishes this.

 In any case, I wonder if we really want to support type safety for the
 argument *types* themselves.

 [snip]

  
   interface Arity {
   }
  
   interface ArgumentedA extends Arity {
   }
  
   interface UnaryA extends Arity {
   }
  
   interface UnaryFunctionA, T extends ArgumentedUnaryA {
   }
  
  
   This is more complicated then having the functors extend Arity, but
 it
   makes better use of inheritance from an OO POV I think.
  
   Just to make sure I understand correctly: If I had an UnaryFunction
   that take a Boolean argument and return an Integer I would model this
   as: class MyFunction implements UnaryFunctionBoolean, Integer,
   right?

  class Foo {
  static CharSequence add(UnaryFunction? extends CharSequence, ? extends
 CharSequence f);
  }

  Foo.add(new UnaryFunctionString, String(){});
  Foo.add(new UnaryFunctionStringBuilder, String(){});
  Foo.add(new UnaryFunctionStringBuilder, StringBuilder(){});


 This could get really nasty to use.

 - Jörg


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Change default arity of Function, Predicate and Procedure

[Oliver Heger]

Am 14.02.2013 16:51, schrieb Matt Benson:

I would say that certainly one would often want to create an API like
you've described.  What I am reluctant not to support is:

class Foo {
   static void add(ArgumentedBinary? extends CharSequence, ? extends
CharSequence functor);
}

Foo.add(new BinaryFunctionString, String, String() {});
Foo.add(new BinaryProcedureString, StringBuffer() {});
Foo.add(new BinaryPredicateString, StringBuilder() {});

The arguments are alike in their argumentedness while having different
functional interfaces.  Convince me this can never be useful, and we can
drop the whole thing ;P

Matt


Scala seems to use a similar approach: There are traits (a trait is 
something like a more advanced interface in Java) like Function1, 
Function2, ... with type parameters for the argument types and the 
result type.


The nice thing in Scala is that its syntax allows you to write function 
literals in a pretty comprehensive form. The compiler maps this 
automatically to the corresponding FunctionX trait.


Oliver




On Thu, Feb 14, 2013 at 8:55 AM, Jörg Schaible
joerg.schai...@scalaris.comwrote:


Hi Matt,

Matt Benson wrote:


Once again, an enum wouldn't readily be able to contribute to your
functor's being able to participate in some method by type signature;
i.e., I want to support the use case of:

add(ArgumentedBinary somethingThatTakesTwoArguments);

Maybe this isn't a worthwhile goal, but so far I don't see anything else
that accomplishes this.


In any case, I wonder if we really want to support type safety for the
argument *types* themselves.

[snip]



interface Arity {
}

interface ArgumentedA extends Arity {
}

interface UnaryA extends Arity {
}

interface UnaryFunctionA, T extends ArgumentedUnaryA {
}



This is more complicated then having the functors extend Arity, but

it

makes better use of inheritance from an OO POV I think.

Just to make sure I understand correctly: If I had an UnaryFunction
that take a Boolean argument and return an Integer I would model this
as: class MyFunction implements UnaryFunctionBoolean, Integer,
right?


  class Foo {
  static CharSequence add(UnaryFunction? extends CharSequence, ? extends
CharSequence f);
  }

  Foo.add(new UnaryFunctionString, String(){});
  Foo.add(new UnaryFunctionStringBuilder, String(){});
  Foo.add(new UnaryFunctionStringBuilder, StringBuilder(){});


This could get really nasty to use.

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org







-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Change default arity of Function, Predicate and Procedure

[Benedikt Ritter]

Hi Bruno,


2013/2/12 Bruno P. Kinoshita ki...@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 brit...@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 gudnabr...@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 brit...@apache.org
   wrote:
 
Hi Guys,
   
I've had a look at the github repo and let me say at first that
  I'm

Re: [functor] Change default arity of Function, Predicate and Procedure

[Matt Benson]

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 ArgumentedA extends Arity {
}

interface UnaryA extends Arity {
}

interface UnaryFunctionA, T extends ArgumentedUnaryA {
}

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 brit...@apache.org wrote:

 Hi Bruno,


 2013/2/12 Bruno P. Kinoshita ki...@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 brit...@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 gudnabr...@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

Re: [functor] Change default arity of Function, Predicate and Procedure

[Jörg Schaible]

Hi,

Matt Benson wrote:

 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 ArgumentedA extends Arity {
 }
 
 interface UnaryA extends Arity {
 }
 
 interface UnaryFunctionA, T extends ArgumentedUnaryA {
 }
 
 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?

@Arity(0)
interface NullaryFunctor {
}

@Arity(1)
interface UnaryFunctor {
}

@Arity(2)
interface BinaryFunctor {
}

Crazy enough? ;-)

Do those interfaces need an ancestor?

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Change default arity of Function, Predicate and Procedure

[Matt Benson]

Hi Jorg,
  We had at some point talked about whether these could be done with a
simple annotation.  I had hoped for something that could be expressed in
terms enforceable by the compiler.

Matt


On Wed, Feb 13, 2013 at 10:22 AM, Jörg Schaible joerg.schai...@scalaris.com
 wrote:

 Hi,

 Matt Benson wrote:

  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 ArgumentedA extends Arity {
  }
 
  interface UnaryA extends Arity {
  }
 
  interface UnaryFunctionA, T extends ArgumentedUnaryA {
  }
 
  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?

 @Arity(0)
 interface NullaryFunctor {
 }

 @Arity(1)
 interface UnaryFunctor {
 }

 @Arity(2)
 interface BinaryFunctor {
 }

 Crazy enough? ;-)

 Do those interfaces need an ancestor?

 - Jörg


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Change default arity of Function, Predicate and Procedure

[Benedikt Ritter]

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 ki...@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 gudnabr...@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 
  brunodepau...@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 ki...@apache.org
   To: Commons Developers List dev@commons.apache.org; 
   gudnabr...@gmail.com gudnabr...@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 gudnabr...@gmail.com
To: Bruno P. Kinoshita brunodepau...@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
|_UnaryA extends Arity
|_BinaryL, R extends Arity
   
?
   
Matt
   
   
On Tue, Jan 29, 2013 at 6:09 PM, Bruno P. Kinoshita 
brunodepau...@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 gudnabr...@gmail.com
  To: Commons Developers List
  dev@commons.apache.org; Bruno P.
 Kinoshita brunodepau...@yahoo.com.br
  Cc

Re: [functor] Change default arity of Function, Predicate and Procedure

[Matt Benson]

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.  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.

Does that make sense?

Matt


On Tue, Feb 12, 2013 at 7:29 AM, Benedikt Ritter brit...@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 ki...@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 gudnabr...@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 
   brunodepau...@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 ki...@apache.org
To: Commons Developers List dev@commons.apache.org; 
gudnabr...@gmail.com gudnabr...@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 gudnabr...@gmail.com
 To: Bruno P. Kinoshita brunodepau...@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
 |_UnaryA extends Arity
 |_BinaryL, R extends Arity

 ?

 Matt


 On Tue, Jan 29, 2013 at 6:09 PM, Bruno P. Kinoshita 
 brunodepau...@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

Re: [functor] Change default arity of Function, Predicate and Procedure

[Benedikt Ritter]

Hi Matt,

2013/2/12 Matt Benson gudnabr...@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 brit...@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 ki...@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 gudnabr...@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 
brunodepau...@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

Re: [functor] Change default arity of Function, Predicate and Procedure

[Bruno P. Kinoshita]

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]).

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).

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.

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 brit...@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 gudnabr...@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 brit...@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

Re: [functor] Change default arity of Function, Predicate and Procedure

[Bruno P. Kinoshita]

Hi Matt!

I changed the default arity with Eclipse help. After a quick glimpse everything 
looked fine in the api module. But in core module,  the packages oacf.adapter 
and oacf.composite  have classes like And and UnaryAnd, that could be updated 
to NullaryAnd and And, or NullaryAnd and UnaryAnd.

The {@link } in javadoc helped a lot too. 

But this change would affect a lot of other classes in core module (I think 
over 100 classes and test-classes). I think it would be easier to merge the 
generators branches without this change, so perhaps we could postpone it for 
now until we resolve FUNCTOR-14 [1] and merge the branches with the trunk. 

What do you think?

I've created FUNCTOR-24 [2] for this issue.

Thank you in advance,

[1] https://issues.apache.org/jira/browse/FUNCTOR-14
[2] https://issues.apache.org/jira/browse/FUNCTOR-24
 
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com


- Original Message -
 From: Matt Benson gudnabr...@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 
 brunodepau...@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 ki...@apache.org
  To: Commons Developers List dev@commons.apache.org; 
  gudnabr...@gmail.com gudnabr...@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 gudnabr...@gmail.com
   To: Bruno P. Kinoshita brunodepau...@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
   |_UnaryA extends Arity
   |_BinaryL, R extends Arity
  
   ?
  
   Matt
  
  
   On Tue, Jan 29, 2013 at 6:09 PM, Bruno P. Kinoshita 
   brunodepau...@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 gudnabr...@gmail.com
     To: Commons Developers List 
 dev@commons.apache.org; Bruno P.
    Kinoshita brunodepau...@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 
     brunodepau...@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

Re: [functor] Change default arity of Function, Predicate and Procedure

[Matt Benson]

Sounds reasonable, I agree.

Matt


On Tue, Feb 12, 2013 at 3:49 PM, Bruno P. Kinoshita ki...@apache.orgwrote:

 Hi Matt!

 I changed the default arity with Eclipse help. After a quick glimpse
 everything looked fine in the api module. But in core module,  the packages
 oacf.adapter and oacf.composite  have classes like And and UnaryAnd, that
 could be updated to NullaryAnd and And, or NullaryAnd and UnaryAnd.

 The {@link } in javadoc helped a lot too.

 But this change would affect a lot of other classes in core module (I
 think over 100 classes and test-classes). I think it would be easier to
 merge the generators branches without this change, so perhaps we could
 postpone it for now until we resolve FUNCTOR-14 [1] and merge the branches
 with the trunk.

 What do you think?

 I've created FUNCTOR-24 [2] for this issue.

 Thank you in advance,

 [1] https://issues.apache.org/jira/browse/FUNCTOR-14
 [2] https://issues.apache.org/jira/browse/FUNCTOR-24

 Bruno P. Kinoshita
 http://kinoshita.eti.br
 http://tupilabs.com


 - Original Message -
  From: Matt Benson gudnabr...@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 
  brunodepau...@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 ki...@apache.org
   To: Commons Developers List dev@commons.apache.org; 
   gudnabr...@gmail.com gudnabr...@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 gudnabr...@gmail.com
To: Bruno P. Kinoshita brunodepau...@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
|_UnaryA extends Arity
|_BinaryL, R extends Arity
   
?
   
Matt
   
   
On Tue, Jan 29, 2013 at 6:09 PM, Bruno P. Kinoshita 
brunodepau...@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 gudnabr...@gmail.com
  To: Commons Developers List
  dev@commons.apache.org; Bruno P.
 Kinoshita brunodepau...@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 
  brunodepau...@yahoo.com.br wrote

Re: [functor] Change default arity of Function, Predicate and Procedure

[Bruno P. Kinoshita]

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 ki...@apache.org
To: Commons Developers List dev@commons.apache.org; gudnabr...@gmail.com 
gudnabr...@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 gudnabr...@gmail.com
 To: Bruno P. Kinoshita brunodepau...@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
 |_UnaryA extends Arity
 |_BinaryL, R extends Arity
 
 ?
 
 Matt
 
 
 On Tue, Jan 29, 2013 at 6:09 PM, Bruno P. Kinoshita 
 brunodepau...@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 gudnabr...@gmail.com
   To: Commons Developers List dev@commons.apache.org; Bruno P.
  Kinoshita brunodepau...@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 
   brunodepau...@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-unsubscr...@commons.apache.org
    For additional commands, e-mail: dev-h...@commons.apache.org
  
  
  
 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Change default arity of Function, Predicate and Procedure

[Matt Benson]

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 
brunodepau...@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 ki...@apache.org
 To: Commons Developers List dev@commons.apache.org; 
 gudnabr...@gmail.com gudnabr...@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 gudnabr...@gmail.com
  To: Bruno P. Kinoshita brunodepau...@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
  |_UnaryA extends Arity
  |_BinaryL, R extends Arity
 
  ?
 
  Matt
 
 
  On Tue, Jan 29, 2013 at 6:09 PM, Bruno P. Kinoshita 
  brunodepau...@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 gudnabr...@gmail.com
To: Commons Developers List dev@commons.apache.org; Bruno P.
   Kinoshita brunodepau...@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 
brunodepau...@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-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
   
   
   
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 
 

Re: [functor] Change default arity of Function, Predicate and Procedure

[Bruno P. Kinoshita]

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 gudnabr...@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 
 brunodepau...@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 ki...@apache.org
  To: Commons Developers List dev@commons.apache.org; 
  gudnabr...@gmail.com gudnabr...@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 gudnabr...@gmail.com
   To: Bruno P. Kinoshita brunodepau...@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
   |_UnaryA extends Arity
   |_BinaryL, R extends Arity
  
   ?
  
   Matt
  
  
   On Tue, Jan 29, 2013 at 6:09 PM, Bruno P. Kinoshita 
   brunodepau...@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 gudnabr...@gmail.com
     To: Commons Developers List 
 dev@commons.apache.org; Bruno P.
    Kinoshita brunodepau...@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 
     brunodepau...@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-unsubscr...@commons.apache.org
      For additional commands, e-mail: 
 dev-h...@commons.apache.org
    
    
    
  
  
  
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Change default arity of Function, Predicate and Procedure

[Matt Benson]

What about:

Arity (Marker)
|_Nullary extends Arity
|_UnaryA extends Arity
|_BinaryL, R extends Arity

?

Matt


On Tue, Jan 29, 2013 at 6:09 PM, Bruno P. Kinoshita 
brunodepau...@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 gudnabr...@gmail.com
  To: Commons Developers List dev@commons.apache.org; Bruno P.
 Kinoshita brunodepau...@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 
  brunodepau...@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-unsubscr...@commons.apache.org
   For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 

Re: [functor] Change default arity of Function, Predicate and Procedure

[Bruno P. Kinoshita]

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 gudnabr...@gmail.com
 To: Bruno P. Kinoshita brunodepau...@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
 |_UnaryA extends Arity
 |_BinaryL, R extends Arity
 
 ?
 
 Matt
 
 
 On Tue, Jan 29, 2013 at 6:09 PM, Bruno P. Kinoshita 
 brunodepau...@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 gudnabr...@gmail.com
   To: Commons Developers List dev@commons.apache.org; Bruno P.
  Kinoshita brunodepau...@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 
   brunodepau...@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-unsubscr...@commons.apache.org
    For additional commands, e-mail: dev-h...@commons.apache.org
  
  
  
 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Change default arity of Function, Predicate and Procedure

[Matt Benson]

What about in pure functional languages e.g. Haskell?

Matt


On Tue, Jan 29, 2013 at 4:55 PM, Bruno P. Kinoshita 
brunodepau...@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-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Change default arity of Function, Predicate and Procedure

[Bruno P. Kinoshita]

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 gudnabr...@gmail.com
 To: Commons Developers List dev@commons.apache.org; Bruno P. Kinoshita 
 brunodepau...@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 
 brunodepau...@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-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org