Function Lazy eval - Currying or address of a function with args?

[Fred Janon]

I have been using function addresses for a long time in different
languages but I miss an *easy* way of getting the address of a
function with its arguments and then call it later on (lazy eval).
Right now, storing the arguments and the address of the function in a
data structure and then calling the function with the arguments stored
is the only easy way to do it that I know of or currying with the
extra code required.

I think that something like

pf := &somefunc("a str", 1)

and then

pf()

would be useful.

I know that with closure we can curry functions but it's a bit
convoluted, there might be a simpler way or syntax to do it.

Maybe something like that in Go 2.0?

Fred

[chris dollin]

pf := func () { somefunc("a str", 1) }

doesn't seem to be particulary heavy to me. Certainly not
heavy enough /on its own/ to need new syntax.

Chris

--
Chris "allusive" Dollin

[Michael Jones]

Notable difference:

somefunc signature:

func name(args) (T2,T3,...) 

f := &somefunc("a str", 1)

:

pf()

compiler knows T2, T3, etc., and can simply do the right thing.

pf := func () { somefunc("a str", 1) }

is a perfect example for the asked-for case, but when T2, T3, ... exist then the function wrapper must be:

pf := func () (T2,T3,...) { return somefunc("a str", 1) }

and the programmer needs to know T2,T3,... and express them perfectly as somefunc changes. In the spirit of the C-world's typeof(x), Go could have TypeOf(x) and then one could write:

pf := func () TypeOf(somefunc) { return somefunc("a str", 1) }

:

v1, v2, ...vn := pf()

was would be the case in an expanded version of the original proposal:

f := &somefunc("a str", 1)

:

v1,v2,...vn := pf()

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[SteveD]

On Monday, August 13, 2012 5:00:56 PM UTC+2, Michael Jones wrote:

>pf := func () (T2,T3,...) { return somefunc("a str", 1) }

>and the programmer needs to know T2,T3,... and express them perfectly as somefunc changes. In the spirit of the C-world's typeof(x), Go could have >TypeOf(x) ..

Here's another way of approaching the same thing.  It would be convenient if Go used type inference more freely.  Say I am passing a function that operates on floats and returns floats, then one could say:

MyFunc(func(x) { return x*x })

where the compiler knows perfectly well that MyFunc expects func(float64) float64 and can insert this information.

So we could get by the same analysis:

F := func(x) { return somefunc("a str",x); }

Might be awkward for the compiler; the question is whether the convenience is worth that awkwardness.

steve d.

[Rémy Oudompheng]

On 2012/8/15 SteveD <steve.j...@gmail.com> wrote:
> Here's another way of approaching the same thing. It would be convenient if
> Go used type inference more freely. Say I am passing a function that
> operates on floats and returns floats, then one could say:
>
> MyFunc(func(x) { return x*x })
>
> where the compiler knows perfectly well that MyFunc expects func(float64)
> float64 and can insert this information.

I think it would go a bit too far compared to the usual Go rules. One
thing I would to be able to do in a future version of the language is:

type WalkFunc func(path string, info.os.FileInfo, err error) error
...
F := WalkFunc(path, info, err) {
// do things
return nil
}

just like we can use named types in struct/map/slice literals. Such a
syntax addition would not modify the typing rules.

> So we could get by the same analysis:
>
> F := func(x) { return somefunc("a str",x); }

This is not the same analysis, since in the previous example, the
function type was inferred from the context. Here you have to choose a
default type, like when writing "x := 1" the language says "x will
have type int".

Suppose I write

mustRead := func(r, s) {
n, err := r.Read(s)
if err != nil { panic(err) }
return n
}

what is its type ? is it func(io.Reader, []byte) int ? is it
func(*bufio.Reader, []byte) int ? what about

func(n) { fmt.Println(n) }

In functional programming languages like Haskell, types or similar
expressions can be inferred from how are they are used later, the
compiler is totally different. Haskell is also different in that
variables may be polymorphic functions:

let f x y = x ++ y in show (f [1] [1]) ++ show (f "hello" "world")

where f is used to concatenate both lists of integers and strings.

In Go where each variable must have only one type, it is difficult to
choose what type to give, and also difficult to write the rules for
that choice.

Rémy.

[minux]

On Wed, Aug 15, 2012 at 7:15 PM, Rémy Oudompheng <remyoud...@gmail.com> wrote:

On 2012/8/15 SteveD <steve.j...@gmail.com> wrote:
> Here's another way of approaching the same thing.  It would be convenient if
> Go used type inference more freely.  Say I am passing a function that
> operates on floats and returns floats, then one could say:
>
> MyFunc(func(x) { return x*x })
>
> where the compiler knows perfectly well that MyFunc expects func(float64)
> float64 and can insert this information.

I think it would go a bit too far compared to the usual Go rules. One
thing I would to be able to do in a future version of the language is:

type WalkFunc func(path string, info.os.FileInfo, err error) error
...
F := WalkFunc(path, info, err) {
  // do things
  return nil
}

yeah, i miss this feature too, especially for something like net/http.HandlerFunc.

[Dan Kortschak]

I was surprised the first time I realised I couldn't do this.