The only primary embeddings are stored on the domain is for lifetime implications. If we can detangle these two (which I've always wanted to do) then we could always store them on the codomain. It is, however, useful to be able to query a parent for embeddings (e.g. AA -> RR for any particular precision). Maybe this can always be handled with an intermediate field that all the codomains know about.
As long as the coercion graph is constructed lazily, I don't know that it's possible to respect the digraph model. For example, if we have X -> Y -> Z, the mere creation of Y induces a coercion from X to Z that might not have existed (or be easily detected) previously, and it's hard to disallow this (though perhaps we can, I can't think of a valid usecase right now). On Tue, Oct 15, 2013 at 1:00 AM, Nils Bruin <nbr...@sfu.ca> wrote: > On Tuesday, October 15, 2013 12:10:15 AM UTC-7, Simon King wrote: >> >> Ultimately, the coercion system is asking the involved parents which >> coercions they know of. There is no other location that would store >> coercions. > > > That's how we implement it. If that's insufficient then we fail to properly > implement the digraph model. We'll have to change at least one of our > implementation or our model. > > For the purpose of path discovery, it is just a complication to have to > consider both "embedding" and "coerce_from". We'd be better off with only > one. Then it's just a single backtrack process rather than a mixed > > Of course there are other reasons why we have both. After #14711, there are > lifetime implications: A coercion registered as "embedding" ensures that > domain keeps codomain alive, whereas one registered on "coerce_from_list" > ensures that codomain keeps domain alive. > > I'd think it's better to not blur the two functions: Simply make the path > discovery system have as little lifetime implications as possible (i.e., > store coercions weakened [this means: having only a weak reference to the > domain if possible] on the codomain, a la coerce_from_hash) and in addition > store separately, references "domains_to_keep_alive" and > "codomains_to_keep_alive" to impose the correct lifetime implications. > > To a large extent, this could be done in the current model if the current > coerce_from_list gets turned into a MonoDict, just as coerce_from_hash. The > routine "register_embedding" would simply have to put the embedding in > there, and perhaps keep putting it in other places too. Both > `register_coercion` and `register_embedding` should probably adjust > "domains_to_keep_alive" resp. "codomains_to_keep_alive". > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
