(missing)
(missing)
(missing)
Re: Proposal to add HTML class attributes to SRFIs to aid machine-parsing Marc Nieper-Wißkirchen (06 Mar 2019 10:12 UTC)
Re: Proposal to add HTML class attributes to SRFIs to aid machine-parsing Lassi Kortela (11 Mar 2019 14:18 UTC)

Re: Proposal to add HTML class attributes to SRFIs to aid machine-parsing Lassi Kortela 11 Mar 2019 14:17 UTC

>> Yes, I meant it mostly as a poor man's type signature search :) E.g.
>> search for "filename" to find procedures that deal with files. Obviously
>> a better type search can be done with a big manual effort. I wouldn't
>> extract type names only to do this, but we'll get this search for free
>> if the index has them.
>
>
> Again, shameless self-promotion, but this is exactly what I managed to
> do with my proposed S-expression...  :)
>
> Again all this would be impossible without thorough type information...  :)

This would obviously be better when the type annotation work is done. In
the best case we'd end up with something similar to Haskell's Hoogle
(<https://www.haskell.org/hoogle/>). But the arg name stuff is something
we could have immediately as a free side product of the other work (if
we do any HTML conversion) whereas this would take years to finish.

I think we should have both. The arg name search would be subsumed into
the comprehensive type signature search when the latter is finished.

> Well here is something where a `dyalizer` type of tool would help:  if
> a variable is "deduced" to contain perhaps a circular list, then the
> "checker" could issue a warning that such a "possible circular" list
> is given to a function that is clearly marked not to accept one.
If people can pull that off automatically I am truly impressed :)

Common Lisp has a (declare) form so the programmer can say, "I know that
variable X is going to have type T." Perhaps something like this would
help. But getting a bit off topic here :D