mention typeof functions in types docs

[tpapp]

• mention typeof functions in the types section of the manual, with an example
• explain that typeof(foo) is merely how it is printed
• also add examples for typeof anonymous functions, add an example which is not a singleton

[simeonschaub]

I think we need to be careful here not to conflate "function", "function defined at top-level", "closure" and "anonymous function". I think we typically use the term function to denote ones defined at top-level as well as closures. I also don't think anonymous functions are equivalent to closures, since we do have named closures and anonymous functions can also be used at top-level, where they won't close over any variables.

[tpapp]

@simeonschaub: good point, concrete suggestions to the PR would be appreciated.

[foldl]

Suggest to add another note on types of anonymous functions:

Types of two anonymous functions may even be the same:

julia> fs = [(x) -> i + x for i = 0:1]
...
julia> typeof(fs[1]) === typeof(fs[2])
true

A question: Is this documenting Julia itself or the implementation (compiler, runtime, etc) ?

[tpapp]

@foldl: yes, those types are the same, but this is not something I would encourage users to rely on, even if it is likely to remain so.

Types in Julia are mainly used for dispatch, so while it is idiomatic to rely on type of named toplevel functions, eg typeof(sin), one may not want to use these types in 99% of other cases. We should just document how anonymous function types print so that users are not surprised.

[simeonschaub]

Some suggestions

[simeonschaub]

Suggested change

	false
	false
	julia> addy(1).y
	1

[tpapp]

Isn't closures having fields an implementation detail, something we would not necessarily want to expose in the user manual?

[simeonschaub]

I wouldn't call that an implementation detail. It is a defining feature of closures.

[rfourquet]

It doesn't sound like a defining feature of closures, after all they were implemented differently in the past, and the field names could have been made unavailable through getproperty even with the current implementation. But I don't know whether that's now specified somewhere in the documentation.

[tpapp]

It's in the dev docs.

Incidentally, is it OK to link devdocs in the user manual?

[simeonschaub]

It doesn't sound like a defining feature of closures, after all they were implemented differently in the past, and the field names could have been made unavailable through getproperty even with the current implementation.

I actually didn't know that, thanks! I suspect that changing this now would be quite breaking, so we can probably document this somewhere, but we can leave it out of this PR for now.

[simeonschaub]

Incidentally, is it OK to link devdocs in the user manual?

I didn't notice that at first. We should probably have something on closures n the regular docs as well, but for now, maybe we can just have the link point to anonymous functions instead, since in most cases they are actually closures as well.

[rfourquet]

It's in the dev docs.

Thanks. As the "dev docs" document Julia internals, I wouldn't link to the them from the user manual. To show the point here, you might insert in the sessions addy(1) === addy(2) # false, and/or maybe show the output of addy(1) (i.e. var"#3#4"{Int64}(1), which hints at the implementation detail).

[tpapp]

Thanks, I added that example, and now only refer to closures in passing.

[foldl]

@tpapp, the added content is to emphasize the differences between the type of a top level function and the type of an anonymous one.

[tpapp]

@rfourquet, @simeonschaub: thanks for your constructive comments. I think this is now ready, a review would be appreciated.

[simeonschaub]

We can link to the anonymous function section, but I still believe we should use the word closure here.

[tpapp]

Ok, I made that change. The manual also uses "closure" liberally in other places so this should be OK.