Re: Inferred function types in the *Help* buffer

[Andrea Corallo <acorallo@gnu.org>]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 1 juni 2023 kl. 15.34 skrev Andrea Corallo <acorallo@gnu.org>:
>
>> Are you suggesting we need some kind of override method for this?
>
> Maybe. It depends on what the purpose of showing the type in the help test is in the first place.

It's just a very concise and effective way to express the input/output
value/types of the function.  I, for one, find it very useful.

>> Again, if you've found these to be incorrect that's a bug we already
>> have in the code in use.  They had to be reported/looked into since
>> probably the time we noticed this inchoerence for the first time.
>
> Sorry, I originally assumed that I had misunderstood what the types
> meant and how they were used by the native compiler. After all, I
> cannot take it for granted that internals of code found elsewhere
> should be neatly arranged for my own purposes.
>
>> Aren't the entries we have in agreement with the docstring?  If the
>> docstring is not in sync with the implementation we have either to fix
>> one o the other I think.
>
> It's a policy problem: either we trust handlers to be implemented to
> spec or we distrust them just to be on the safe side. Normally we
> assume that users follow documented rules or suffer the consequences,
> but in this case it may not be the same user who writes the handler
> and who calls the function, so it may be fairer to shield the caller
> by normalising the return value of all handlers in these and other
> cases.

If we distrust the handler either we should coerce the value to boolean
before returning it or either we should change the docstring.

>> -    (coordinates-in-window-p (function (cons window) boolean))
>> +    (coordinates-in-window-p (function (cons window) (or cons (member bottom-divider right-divider mode-line header-line tab-lineleft-fringeright-fringevertical-line left-margin right-margin))))
>
> Typos here (and null is missing).

Thanks

>> -    (framep (function (t) boolean))
>> +    (framep (function (t) (or boolean (member x w32 ns pc pgtk haiku))))
>
> This may be too fragile. Next port won't find this place to add its name.
>
> Of course, if we manage to put these type declarations near the function definitions then accuracy would likely be better and maintenance easier (and more likely to take place at all).

Yeah that's the general argument for that.  As metioned I guess this
should be a temporal solution anyway.

BTW I believe that most likely the next port value will be to added to
comp-known-type-specifiers only if we expose it into the help :)

Thanks

  Andrea