I am looking at replacing HyperDoc code in Boot by Spad code.
You can ask why bother? Do not Ralf API code cover all? Well,
HyperDoc provides _much_ more functionality. Namely,
HyperDoc provides several views, with possibility of filtering.
Basic view, that is constructors allows selecting categories,
domains or packages (or all). One gets list of operations
in one of several forms:
- names
- signatures
- descriptions
- parameters
- conditions
- origins
- implementations
One can look at exports, ancestors, etc.
Having API on the web is very good, but trying API it I must say
that for me it is much less usable than current HyperDoc.
Simply current API lacks many features. Any single feature
of HyperDoc may look not very important, but there are several
features and together they make a difference. So, we should
look at adding new features, not at removing them.
Technically, HyperDoc functionality requires code to compute
relevant info (signature lists, constructor lists) and presentation
code. Of course presentation code must take into accout medium.
So we need different presentation code for Html (API and potential
use via browser), current HyperDoc and text (system commands).
But most complicated part of work is computation of relevant
information. Currently system commands reuse part of HyperDoc
code but do part of work in their own way. HyperDoc computes
info in several different ways, it is not clear to me if all
this variation is needed. API has its own way to compute
constructor info. api2.spad that I did reuses computation
of info from API, but has different presentation layer.
As I wrote I have part of HyperDoc code in Spad. HyperDoc
page has the following representation:
Rep := Record(name : Symbol, domain_conditions : LSE,
variable_alist : ALS, pattern_vars : List(PSR),
radio_buttons : ALS, input_areas : ALS,
property_list : ALS, page_description : LSE,
work_area : List(String))
where ALS is List(Record(key : Symbol, entry : SExpression)),\
LSE is just list of S-expressions and PSR is list of
Record(var : Symbol, pvar : Symbol).
This representation actually is representation used by Boot code,
so that Spad code can cooperate reasonably well with Boot code.
Each HyperDoc page has an associated symbol, and content of the
page is stored in value slot of the symbol. When C code sends
request to FRICASsys, this request is in form of S-expression
that is evaluated by FRICASsys. One of arguments is name of
symbol associated to the page, so evaluation gets value of
the symbol and in this way HyperDoc functions know which page
to handle. The record above is in a way unbalenced, general
info is stored in property list and page description, while
other fields have more special use. But this way, that is
symbol per page and page data in a record is reasonable
(alternatively, we can store pages in a hash table, currently
use of symbols avoids use of hash table).
Currently page description is a mixture of higher level symbolic
data (which in principle could be presented in any sufficiently
expressive format) and literal HyperDoc data. Of course literal
data means that just now this is good only for HyperDoc.
My code handles just HyperDoc page data and communiation to C
code. Next stage is to generate content of pages, in particular
to generate needed info. I would like to reuse Ralf code for
this, but I am not sure if this will be possible: Ralf uses
data structures (in particular XHashTable) which are problematic
to access from Boot. I would like to do things in incremental
way, so just now I need data structures that allow easy cooperation
with Boot code.
Extra remarks: my goal is to allow dynamic interface either using
current C code or a web browser (depending on user choice).
Command line interface can not support hyperlinks, but I think
that most info should be also available via command line.
At logical level most HyperDoc constructs can be
represented in Html. HyperDoc uses just a handful of rendering
constructs, AFAICS this is small subset of what Html can do.
HyperDoc has allows control if new page replaces existing one,
or if it is open in a new window. I am not sure if this can
be represented in pure Html, but certainly can be done using
some extra Javascript. C side of HyperDoc sends explicit commands
to destroy pages, we can not expect web browser to do this,
but I do not think this is a big problem.
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/aEmf5puIj48wmfur%40fricas.org.
