BrwserInformation

[Waldek Hebisch]

I just commited an update to BrowserInformation. After last commit
')show' for constructors with parameters uses BrowserInformation.

Now BrowserInformation is computing more things. It calls Boot
code for several important things, but more things than
previously are done at Spad level. In particular, computing
operations for a constructor is re-done. It now merges
information from 3 sources: exports computed from constructor
category (stored in constructor "database"), documentation
from "database" and list of operations from "database".
Old Boot code used documentation and list of operations, but
that has trouble with undocumented operations (they would be
missed or assigned wrong origin). Exports allow correct
calculation of origin (IIUC Ralf API code also calculates
origin from exports). Documentation part is needed because
it is the only place storing documentation strings.
In principle all other information could be computed from
exports. However, handling of conditions requires some care
and needed work was already done to compute list of operations.
So I take conditions from list of operations. To summarize:
signature is present in all sources, origin is computed
based on exports, condition is taken from list of operations,
documentation is from documentation part.

There are some changes how the code works. First, there are
various transformations which change signatures. To correctly
much signatures from various sources we need common representation.
I decided to use symbols with names 0 and 1 to represent
corresponding operations (this is recent change, old code used
"Zero" and "One" as names). Unfortunately, we can not be 100%
consistent there, as 0 and 1 are also used as values and
need to be passed to Lisp EVAL. Such cases either need
function call notation like Lisp '(|0|) or numeric value.
Function call notation presumably would produce correct values,
but type checking in interpreter currently seem to depend
on numeric values. So "database" uses numeric values which
need to be converted to symbols. Since our types have
parameters also signatures need parameters. So signature
may have special markers (symbols like #1, #1, etc or in some
cases symbols like t#1, t#2, etc). For presentation we need
to replace those symbols by appropriate values. In "database"
we store parameter names appearing in constructor definition,
together with constructor name this give "constructor form".
Constructor form is passed to several functions and names
of parameters are substutued into signatures (and types).
But we may also give value to parameters. For this old
code used extra argument, that Lisp S-expression with
constructor name in place of function and with actual
values in place of arguments). This was called domain name
or domain form. ATM I use the same approach, so several
functions take two arguments, one with formal parameters, one
with actial values. Usually, the second argument can be
null or identical to the first (for cases when constructor
arguments remain unspecified). This is different than
earlier version when I tried to use Boolean argument to
specify if constructor argument are provided. It is
still not clear to me which variant is really better so
this may change.

In previous version I tried to simplify signatures for display
purpose. Unfortunatly, this caused trouble with matching
signatures coming from different sources, so I am no
longer doing this. So, now user/consumer of data need to
handle fact that internally symbol 'T' is represented as
'T$' and if desired omit parentheses around constructors
with no parameters.

New code is skipping operations with false conditions and
duplicate signatures. Old code when looking for implementations
could indicate "unexported" which meant that condition was
false, new code simply skips such operations.

--
Waldek Hebisch