Comment On Alex Winston's Blog
It looks like java.net doesn't like me any more. I'm not allowed to post a comment to Alex Winston's blog:
Alex Winston's BlogComment Submission Error
Your comment submission failed for the following reasons:
You are not allowed to post comments.Posting as: weiqigao
Allowable html: a href,br/,p,b,strong,em,i,ol,ul,li,blockquote,pre
So I'll post what would have been a comment on that blog here. This is in response to a Cay Horstmann comment that reads:
Cay Horstmann: I think int plus2(int) is a non-starter. Don't entangle the declared variable within fragments of the type. That approach has been thoroughly discredited after it made a disastrous appearance in C/C++. Try writing a function that yields an int=>int function using your syntax...
@Cay, it is actually quiet simple to write such a function:
int makeAdder(int n)(int x) = int (int n)(int x) {
return int(int x) { x + n };
}
Given the above, we can have
int add7(int x) = makeAdder(7);
and
int result = add7(8); // yields 15
Re: Comment On Alex Winston's Blog
I too was not able to post on Alex Winston's blog, I sure hope it's not censorship of alternative opinions, that would be very un-Sun-like.
Here is something I considered in my admittedly limited world view of this topic:
One approach that might work:
int : int plus2 = (int x) { x + 2 };
The colon separates the argument type from the return type, e.g.,
int, int : int add = (int x, int y) { x + y };
If a function is being returned, some form of grouping is required to
denote this:
int, int :: int : int curry = (int x) { add.(x) };
Function that takes two ints and returns a function from int to an int.
The double colon serves to delimit the argument list when a function is
being returned.
int : int curried = curry.(2); int z = curried.(2); // z is now 4Passing higher order functions is similiar, except the argument function needs to be delimited with parenthesis in the type declaration:
int, (int : boolean) : boolean filter = (int x, int : boolean pred) {
if(pred.(x))
return x
};
This is a rough sketch of what I think might be a
reasonable approach. I haven't thought extensively through
all the potential ramifications, but from the initial cursory
look I think it may be worth glancing at.
Re: Comment On Alex Winston's Blog
As I had similar problems on commenting Alex' Blog: After you (Weiqi) wrote about the pointer syntax, in my private study room (well ...) I actually produced a sibling to Alex' syntax proposal.
I agree and disagree to both the statements by Thomas Hardin and Cay Horstmann on Alex' proposal: To me, neither of the arguments sound convincing. A declaration of a field/parameter/variable like
A function yielding a function that takes an int and returns an int wouldn't read better in BGGA:
I agree and disagree to both the statements by Thomas Hardin and Cay Horstmann on Alex' proposal: To me, neither of the arguments sound convincing. A declaration of a field/parameter/variable like
int convert(String);should be understood differently from a function type. IMHO, it's a parameterized variable (or method-variable) of type int that shares the namespace of methods rather than variables and can be assigned a method reference or closure matching the signature. One would not see it as a return (function) type of a method, which should rather be
int (String) getMethod();It will introduce a dualty, though, as one still has function types for return values, which is due to the nature of return types as defined in Java.
A function yielding a function that takes an int and returns an int wouldn't read better in BGGA:
{int => int} { => {int x => x} }
versus
int (int) () { return int (int x) { return x;}; }
where the BGGA style uses return type inference and last-expression-no-semicolon-return, which are both alien to Java. While the second is more verbose, I doubt reading the first makes things more clear.