Himanshu Neema writes:
> Hello All:
>
> We use Dictionaries for some of our routines. This rendered our solvers
> non-deterministic as the methods on 'Dictionary' like
> {Dictionary.items}, {Dictionary.entries}, etc. do not return the list in
> the order in which they were inserted. Rather, the order seems to
> non-deterministic, is that right?
> Dictionaries (and records) use a hash tree internally to map from the key to the item. The order returned by the items and keys routines is the order of the entries in this hash tree. > I have tried to extend the 'Dictionary' functor by wrapping it inside of > OrderedDictionary.oz functor. However, it doesn't seem to work. Please > see the attached OrderedDictionary-NotWorking.oz and > OrderedDictionaryTest.oz. What exactly is the error in the way I am > trying to extend 'Dictionary'? > A functor such as Dictionary specifies a record which maps the externally visible literals (atoms) to their value. In OrderedDictionary-NotWorking.oz you are exporting orderedDictionary, which maps to another record that contains the actual overridden procedures. That is, you have a level of indirection too many. > The not-so-elegant, as one might say, way of extending, i.e. defining > the functor OrderedDictionary.oz by redefining every 'Dictionary' method > and delegating calls to actual 'Dictionary' functor, seems to work fine. > Please see the attached OrderedDictionary.oz and > OrderedDictionaryTest.oz. Is there is anything wrong with this way of > extension, except that it is not as elegant as it would be if I could > make the not-working versions as working? > We can simplify this version a little, see my attached version. It is sufficient for the Test program but doesn't rewrite all the interface. Also notice that your version is not safe in a concurrent setting because you don't update the counter atomically. That is fixed in my version. There is also the problem that the OrderedDictionary routines don't check that the passed in dictionary is really an OrderedDictionary. There are a number of ways to fix that. For example you could use the Object Oriented interface to Dictionaries from the standard library. Or you could 'brand' the OrderedDictionary when you create it (e.g. generate an Oz Name for OrderedDictionaries) and store them as DictionaryBrand#OrderedDictionary, etc, but that won't work in a distributed setting without some work. > While defining these functors I have noticed that importing 'Dictionary' > is not allowed in these functors because when I had the import > 'Dictionary' in the code, the error occurred at runtime and it was > really hard to figure out that it was because of the "import Dictionary" > statement. Therefore, I would also like to get an understanding on where > to import Dictionary and where not to and why? > Dictionary is part of the Mozart Base environment so it is always available. don't import it unless you are overriding it by another dictionary.ozf functor. > I will appreciate any help. > > Thanks, > Hope that is clear. k
OrderedDictionary-Simple.oz
Description: Binary data
_________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
