Hallo Waldek, thanks for your quick explanation, I add my comments directly to your comments
Am 20.12.16 um 22:35 schrieb Waldek Hebisch: > Prof. Dr. Johannes Grabmeier wrote" >> I observed the following behaviour. Perhaps someone can tell what is >> going on, a bug of philosophy which I do not understad? If necessary I >> can work out and provide a minimal example. >> >> 1. defined a category IML with several functions, all of them are >> implemented in the category, some of them use local pointer variables of >> the form >> pF1: Reference Boolean :=3D ref false >> in the add-part of the category >> >> 2. implemented domains (eg. DatabaseTable) which use this category via >> Join(IML, ...) with .. >> it works like designed: I can set from outside new values to the >> Reference values, and then on the Boolean values depending functions of >> the domain the set values >> (from outside) are used and change the behaviour of the functions. >> (mainly: information on intermediate values of variables) >> >> 3. implemented a package which use this category via IML with ... >> Different behaviour: alll function codes from IML are available as >> signatures of the package, there compiled code from IML- is available >> and can be executed. The internal >> variables - as in 2. - can be set from outside, the functions which >> return the actual values show the changed values. HOWEVER, the code of >> other functions in the package >> do not realize, that the derefenced values are changed -- CONTRARY >> to the identical settings in the domain case of 2. Then, the attempt to >> repeat the definitions as >> pF1: Reference Boolean :=3D ref false >> in the add-part of the package does NOT CHANGE this behaviour. >> However, in this package a domain(DatabaseTable) which also has the categor= >> y >> IML implemented, is imported. Executed code now uses THE internal >> values of pF1 of this domain for the execution of a function from the >> package. Can it be, that the compiler >> is confused and uses the wrong variable? This suspicion is confirmed >> when I finally did a package call to % explicitly. > Hmm, I do not know what you expect. First, the add part of category > is a special package. For each domain/package of the category you > get a separate copy of this package (normally you get a single copy > for each tuple of parameters, but add part of category has the > domain as a parameter). > > Second, variables in different domains/packages are completely > separate. In particular your domain/package does not directly > see variables from IML -- the whole effect of variables in > add part of IML is that they are visible to functions in > add part of IML. > > Your problem may be that the compiler calls different > function than the ones you expect: in case when multiple > functions share signature the compiler will just choose > one of them. my discovered problem comes down to the following: if I don't import another domain which also uses IML, then the compiler correctly sees the variables from IML in its own defined new functiogs. If, however, such an import is present, it uses the variables from the IML from the import. My feeling is, that directly used IML from the domain/package should have priority. Otherwise the uses can not know in setting the appropriate variables from the right domain, which package calling he should use. The behaviour of the code is unforeseeable! Of course, as soon I discovered the problem, the work around for the implemter is to use apprioriate package calling $% in the code. > > BTW: I do not understand why you use references. Normally > references are used when you want to modify values from > places were variables are not visible. That frequently > means hairy logic and I would first search for errors > in such logic. > I want to change the unseen local variables of a domain from outside, i.e. at interpreter level. Do you claim that in this case I can do this with normal local variables? at think I remember that this did not work. -- Mit freundlichen Grüßen Johannes Grabmeier Prof. Dr. Johannes Grabmeier Köckstraße 1, D-94469 Deggendorf Tel. +49-(0)-991-2979584, Tel. +49-(0)-151-681-70756 Tel. +49-(0)-991-3615-141 (d), Fax: +49-(0)-3224-192688 -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
