On 25 Jun 2022, at 13:41, Waldek Hebisch <[email protected]> wrote: > > On Wed, Jun 22, 2022 at 08:32:06PM +0100, Paul Onions wrote: >> >> My understanding is that a domain brings with it a collection of operations, >> each one implemented either in the domain itself or in a category referenced >> by the domain (directly or indirectly). > > Not exactly. At low level domain has operations that it implements > itself, in a sense it "brings with" those operations. But domain > also have set interfaces (categories). And there is so call 'add > chain': domain may inherit unimplemented operations from another > domain.
Ah yes, I forgot about the “add chain”. > Actual operation to use is determined at runtime, there > is complicated procedure that examines conditions and decides > which of implementations to use (it looks at operations implemented > in categories and at 'add chain'). Okay, this has prompted me to go back to the documentation and re-read chapter 13 again. There is a useful description of the mechanism used for operation lookup there, thanks. > The point is that this information is dynamic and distributed, most > is not in the domain. In particular, as long as interface parts > does not change the same binary domain could use implementation > from differnet place after other domains are modified. Yes, it’s much more complicated than I initially thought, so trying to come up with a simple way of visualising this is not easy :-( I can see why HyperDoc is the way it is! >> So for any given domain I was expecting it to be possible to list all the >> operations and to be able to indicate the source of each one explicitly, so >> we would know how each operation is implemented in that domain. >> >> I think you are saying that this can be done, but it requires all domain >> parameters to be explicitly specified, and that this is called >> “Implementation” in HyperDoc. > > Currently yes. Basically this simulates runtime call and tells you > which operation would be used. Actually, it reuses code used > by runtime calls. But before you can run code domain must be > "instantiated", that is parameters must be known. > > People want more info about implementation and in principle we > could provide more: naively search could look at about 15000 > implementations (this is rough estimate of number of different > implementation that we have). Actual search is smarter, but > must look at lot of data. We could simulate search, prune > all operations that can not apply and get decision tree > with hopefully small number of alternatives. I wrote > "decision tree" because availability of operations depends > on conditions and conditions depend on parameters. We > could try to simplify conditions, but without parameters > the best we can hope is decision tree. And "simplest form" > of conditions is undecidable, so we need to accept some > redundancy. > > However, even such moderate goal, that is getting reasonably > sized decision tree with possibly reduntant conditions > remain unimplemented. One aspect here is that to be > useful it should agree with what runtime search is doing, > so implementer has to be quite careful do exactly what > runtime search is doing, but in "generic way", that is > without evaluationg conditions. It needs to be shared code to ensure that the help system agrees with the runtime. Maybe two successive stages:- Stage 1: analyse source to derive a decision-tree. Does not evaluate constructor parameters. Code shared by compiler and help system. Stage 2: evaluate constructor parameters to allow traversing of decision-tree to find implementations. Code shared by runtime and help system. Probably need some kind of limitation on the conditional inclusion mechanism to make it all tractable. Sounds like an interesting research project! :-) > There is extra complication caused by Aldor interface: FriCAS > treats Aldor stuff as black box with small number of contact > points. And IIUC Aldor treats FriCAS stuff mostly as black > box. Difficulty here is that interface can do "find operation > with given signature from fully specified domain", but can not > "give decision tree for signature from generic domain". So > any such extra would break down if there is possiblity that > Aldor code is involved. Yes, I think to create a “disciplined” type-safe, statically analysable system it is not possible to have such “black box” entities in it. It is an “all or nothing” approach. >> That’s understandable I guess, but it also means that “Origins” is of >> limited value if it just picks arbitrarily one place where the operation is >> declared? > > Well, it depends on your goal. "Origins" correspond to static > point of view: you look at signature and who _declared_ it. > In principle that is all what you need to know if you want to > use operation or generalize existing code. > > Info about implementations is of different spirit: it tells you > what will happen at runtime. Which, to my mind, is the most important thing. You cannot write software without understanding what is likely to happen :-) Paul -- 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 on the web visit https://groups.google.com/d/msgid/fricas-devel/00AB75DE-3B9A-4596-BA7D-49CFED85EC72%40gmail.com.
