A little progress report: I arrived at one milestone, that is
searches are mostly working without comdb.text and libdb.text.
More precisely, currently in my working version "Detailed search"
is not working and there are some broken things in other searches.
But all that works works without comdb.text and libdb.text.
There are 4324 lines of new Spad code. Spad code makes a lot of
calls to Boot code, but part of Boot code is removed. br-*.boot
files in my working version total 2357 lines. So approximately
55% of br-*boot files is replaced by Spad code. Note: currently
Boot code contains all comdb.text and libdb.text support,
partially to allow comparisons with new code, partially to
support IndexCard. If comdb.text and libdb.text support is
removed few hundreds lines more of Boot code will be gone.
Currently for operation info I use type like:
SE ==> SExpression
SY ==> Symbol
Sig_doc ==> Record(signature : SE, condition : SE, origin : SE,
documentation : String)
Op_rec ==> Record(name : SY, sdl : List(Sig_doc))
Op_lst ==> List(Op_rec)
Err_ind ==> SE
Op_res ==> Union(Op_lst, Err_ind)
Signature is like in Boot code, it is a list of types, target type
first followed by argument types. Err_ind encodes error message
in cases which may fail. I have functions like:
search_operations : String -> Op_res
operations : (Con_form, Boolean) -> Op_lst
where Con_form is just S-expression representing constructor,
boolean when true is supposed to mean that argument to constructor
are real (not just formal symbols), but ATM there is something wrong
here.
Some operation views group operations by some criteria. To
represent such grouping I have
Grp_rec ==> Record(grp_tag : SE, ops : Op_lst)
Grp_lst ==> List(Grp_rec)
where tag represets criteria, like condition, implementation or
origin. There are functions like:
group_by_origin : Op_lst -> Grp_lst
group_by_condition : Op_lst -> Grp_lst
group_by_implementation : (List(SE), Con_form, Op_lst) -> Grp_lst
There is similar set of functions for constructior, but I represent
constructors just by name (symbol) or possibly as form plus condition,
so I have
Cond_rec ==> Record(form : SE, condition : SE)
Cond_con_lst ==> List(Cond_rec)
There is a bit more, I think that types that I have are enough to
cover what in needed by HyperDoc. And I think that types and
functions are enough to provide innformation to generate API
pages.
The rest is mostly me thinking loudly.
Sig_doc above is similar to documentation in database. But
documentation does not have condition part and origin is
implicit (constructor that contains documentation is the
origin). Also, documentation misses undocumented signatures.
So to create Sig_doc-s for a constructor I merge info from
exports (derived from CONSTRUCTORCATEGORY) and documentation.
Documentation contains extra info, namely few docstings for
categores that formerly were attributes and docstings for
operations appearing in constructior signature. Docstings
for _uses_ of categores are redundant (docsting is in
definition of category), so we should probably remove
them. To explain the second issue consider:
DiscreteLogarithmPackage(M) : public == private where
M : Join(Monoid, Finite) with
"^": (%,Integer) -> %
++ x ^ n returns x raised to the integer power n
public ==> with
...
Type of M contains anonymous category and operations from this
category may have docstrings. Trouble is that those docstrings
are mixed with docstrings for normal operations. It seems that
we should either do not store them at all or store them
separately from other docstring. Also, several such
docstrings just say "undocumented", so add no info.
Currently docstring for constructor is provided as
documentation for fictional operation called 'constructor'.
More sensible probably would be record like:
Record(con_doc : String, extra_docs : List(Sig_doc),
op_docs : List(Sig_doc))
and having empty string for cases where there is no documentation.
Currently creating operation list from database info takes about
0.5 second on a slow machine, most of which is reading database
info. Once operation list is created it can be used for many
searches. Also, once database info is in core creating operation
list is much faster. For comparison, creating operation list
in the same format from comdb.text and libdb.text takes about
3 seconds on the same machine. Significant part of this goes
into parsing various expressions using interpreter parser
(which is slower than Lisp parser used to read database info).
Old code avoided this cost for most searches keeping database
info in string form and converting only search results (which
usually are much smaller than whole list of operations).
For searching I currently use 'superMatch?' from match.boot,
it seem to work correctly and speed seem to be OK for most
searches. But documentation searches seem to be slow,
so we probably need faster search engine.
Currently the only user of comdb.text and libdb.tex is
IndexCard and related database in 'alql.spad'. I am
not sure what to do with this. In principle we could
create strings on the fly form other info, but that
means keeping code which is not needed for other purpose.
We could modify IndexCard to internally use representaion
like used for searches. But exposing S-expression in
user interface is not exactly nice, an having convertion
to strings means keeping extra code. We could entirely
remove IndexCard. I am not sure if anybody uses it,
but it is mentioned in FriCAS book, so removal of
IndexCard would mean removing or rewritning corresponding
part.
Another thing is size of code. Spad code is clearly bigger
than Boot code which is replaced. Part of it is due to
type declarations which take some space. Part is because
Boot uses pattern matching and I work with SExpression,
so I use lower level operations nad need more code.
Part is forced near duplication of code: Boot takes
advantage of lack ot type checking and uses the same
routine for various kinds of data. New routines are
typed and type discipline forces using different functions
for different types, even if work to do is quite similar.
Currently I work on browser functionality, that is replacement
for most of br-*.boot files. There are also "demo" files:
bc-matrix.boot, bc-misc.boot, bc-solve.boot; and interface
to view and set system variables, which is in htsetvar.boot.
I would like to preserve demos, OTOH code there in large
part is content of pages encoded as S-expression. This
encoding have some advantages, but currentlty do not
translate in reasonable way to Spad. To a smaller
degree similar issue affects htsetvar.boot.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/aJD0_bIbwSCI9hPz%40fricas.org.
