Hi, I started on something similar to replacing Hyperdoc a while ago - in the context of an unfinished Aldor/Fricas IDE. The main idea is that Spad types held in daase files should be representable as Aldor objects, and from those one can do all the querying needed to generate HTML. Overall, it worked reasonably well. The next hard part would be integrating with a web service..
Code is here: https://github.com/pbroadbery/fricas-aldor-types - It won't work in Fricas at the moment (due to non-essential java dependencies), but might contain some ideas. I will see if it can be tweaked into something that additionally works with the Fricas runtime. Peter On Wed, 11 Jun 2025 at 19:59, 'Ralf Hemmecke' via FriCAS - computer algebra system <fricas-devel@googlegroups.com> wrote: > > Hi Waldek, > > as you know, I would like to let HyperDoc die. > But, maybe that sound too extreme for what I actually mean. > And I agree to some extend to your plan for a new hyperdoc. > > Let me explain my wishes. > > FriCAS should have an interface (in LISP or SPAD) that let's > SPAD or external programs get information about > categories/domains/packages/documentation. > From such an interface it should be easy to generate any output format > be it html, rst or pdf. > > I think this can be started without changing any code for hyperdoc. > Such an interface should already contain code to compute a datastructure > representing the data for a page (not actually rendered in any format), > in particular, conditional exports should be computed and the > datastructure should have enough information to produce links to other data. > > Yes, that is good for a getting a "static" view of a constructor similar > to what is presented at fricas.io/api, but computable on-the-fly. > > You also want such a view in a "dynamic" form, i.e. (similar to what > current hyperdoc provides) getting information about > - usage of domains > - fuction implementation (in which package/domain) > - etc. > > Shouldn't it be possible to create an API that let's query such > information by just sending strings to specify the arguments? > > Why would that need Boot code if there is a function that translates the > string "Polynomial Integer" into the respective domain and uses that in > querying the various places where the wanted information is stored in > FriCAS? > > Whether you then program in interface to present such information, is > another business. I wouldn't do that but rather rely on ordinary > webbrowsers to display such information. One can probably extent jfricas > to start queries and have examples executed in a notebook interface. > > Yes, I like to be able to get more information out of FriCAS than just a > static API page (although I think that having them static on the web is > still a good idea). What I am not in favour of is the current HyperDoc > window. That looks old and not very attractive. That should die. Not the > information it shows, of course. > > At the same time, I would like to put the HyperTeX format to sleep. > This format was interesting 30 years ago, but now there are better > formats like rst of markdown or ... Why should we keep our specific > HyperTeX-Format that nobody outside FriCAS cares about? > > I do not know whether my code is good to be adapted, because initially, > I only had the presentation into an .rst page in my mind. I think one > should carefully separate code that "provides" information from code > that translates that into a certain format. > > Can we create a new branch and work (as a first step) at an interface > that provides all the necessary information in form of SExpression? > > > 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)) > > That is seemingly taylored for a hyperdoc page. Why should one have > radio_buttons in an information record? I would rather have several data > structures like > > FUN ==> Record( > name: Symbol, > source: SEX, > target: SEX, > doc: String, > condition: SEX) > > CAT ==> Record( > name: Symbol, > args: List SEX, > cats: List Record(cat: CAT, condition: SEX) > funs: List FUN) > > etc. (Don't take that too serious. It's just a draft.) > > Anyhow, we should come up with a good datastructure that provide > easy access to the information. > > If you want a datastructure that is just representing the current > hyperdoc structure, I am not interested. That is too much presentation > oriented already. > > > 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. > > There is nothing specific about XHashTable. Any hash structure will do. > Use an association list, if you like. > > > Extra remarks: my goal is to allow dynamic interface either using > > current C code or a web browser (depending on user choice). > > As I said, I would rather like a generic interface to all the > information, separated from code that does the presentation. > > Just my two cents... > Ralf > > -- > 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/1483f2d5-22a4-45a9-8f08-d9e182b8cf5c%40hemmecke.org. -- 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/CAK%3DmBN-rHcRg4jeoazbSovwKkD0eP4OtDbiz9C3xsRcbbovmZQ%40mail.gmail.com.
