Re: __call metamethod, misleading doc or am I missing something?

[Francisco Olarte <folarte@...>]

On Tue, Feb 21, 2017 at 7:26 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
...
> The blanket requiremend is that _all_ metamethods should be
> functions.

Well, if it is I think a paragraph like ( not a native speaker, may be
incorrect ) like "All methamethods should be functions, except where
explictly noted."  should be added, may be with an additional "Even if
objects with __call MM can work in some versions".

I've been reading language manuals for several decades and I got
really confused with 2.4, and it's only about a page, and I've read it
several times.

> The two exceptions (__index and __newindex) are very clearly
> documented. In the first case, it says "Despite the name, the
> metamethod for this event can be either a function or a table."
> Since at the entry for __call does not say anything of the kind,
> the implication is that the metamethod cannot be a table.

The problem, IMO, is the requisite for being a function is stated a
bit sideways and referring to a particular one in a thing sounding
like an example.

> There are many, many places in the manual where something
> appears to be unspecified if you only read that sentence or two,
> but focuses into clarity when you take account information given
> elsewhere.

Rest assured I've read several versions of the manual top to bottom.
And I read the section twice before posting, and searched around quite
a bit before concocting the example.

It's just I'm used to languages where functions are just one of the
classes of callable objects and in nearly all of those they are used
interchangeably. I read the docs and started doing it with some ops
and it worked, and when I hit the __call peculiarity it surprised my.
I read some more docs and rechecked and it still surprises me. I knew
why before posting because I had already read the C code for tryfunctm
posted by rwen, but thought the omission from the docs should be
corrected.

Of course, having a loose documentation gives implementors leeway, so
I understand why it could be useful to leave it underspecified.
Anyway, it's not going to bite ME again.

Francisco Olarte.