Re: Inferred function types in the *Help* buffer

[Andrea Corallo]

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