A look up table? Jim Bromer
On Thu, Jan 1, 2015 at 9:45 PM, Piaget Modeler via AGI <[email protected]> wrote: > In the Premise language function rules are very simple. A function name > follows a left parenthesis. > However the name can be fully qualified *<namespace>.<function>* or > unqualified *<function>* . > > When the name is unqualified we have to resolve the name, qualifiy it in > order to select the appropriate > function to execute. Each namespace has a set of imported namespaces > which may contain the correct > function definition. We only need the first namespace that has the > correct function definition, we don't > care if it is multiply defined. > > Suppose we're in the namespace User and want to access the *sum* function > defined in the Math namespace. > We have a situation like this: > > (using User) > .: User > > (dependencies User) ; return the namespaces this namespace > requires > .: {Premise System} > > (namespace Math > (function sum ?args > (apply + ?args))) > .: Math > > (dependencies User) > .: {Premise System} > > (Math.sum 1 2 3) ; fully qualified function call > .: 6 > > (sum 1 2 3) ; unqualified function call Math > namespace is not known to User > .: [Exception :Text 'The function sum is unknown'] > > (require Math) ; make Math known to user > .: Math > > (dependencies User) > .: {Premise System Math} > > (sum 1 2 3) ; resolves *sum * to *Math.sum* > .: 6 > > The resolution takes time. Albeit a small fraction of time. But it is > cumulative. > > This is the specific problem. > > ~PM > > ------------------------------ > Date: Thu, 1 Jan 2015 20:39:02 -0500 > Subject: Re: [agi] Namespace search optimization > From: [email protected] > To: [email protected] > > > Are you referring to a problem which involves taking runtime data and > searches for an appropriate function given the dynamic value? The search > for the type of object that is defined in runtime is not part of the > problem is it? Because a simple call where the type of the variable is > given or directly implied (by uniqueness for example) should not take too > much time even during runtime. I can think of two search problems that > might occur in something like that. If the establishment of the appropriate > set function requires some trial and error data-fitting (or function > fitting) that could turn out to be inefficient. Or if the search involves a > proverbial tree search then that might take some time as well. I don't see > a straightforward run-time function call (to something that is like a > template) as being that time consuming. > > Jim Bromer > > On Thu, Jan 1, 2015 at 8:11 PM, Piaget Modeler via AGI <[email protected]> > wrote: > > It basically boils down to a basic speed versus extensibility tradeoff. > > > > ------------------------------ > From: [email protected] > To: [email protected] > Subject: RE: [agi] Namespace search optimization > Date: Thu, 1 Jan 2015 08:55:44 -0800 > > Given 200-250 base functions in 10 packages (namespaces), if the > functions are > defined as language intrinsics (like *if * or *for*) then there is no > need for pakckage > lookup, no need to resolve the name with the namespace, so no overheard > is > incurred. If the functions are defined as qualified identifiers (prefixed > by package > name) then we need to look up any unqualified identifiers first, thereby > resolving > the identifier with the package, before proceeding with the evaluation. > > For Example, the *set *function in the *System.KB* package (namespace) > sets a slot > in a prototype instance to a value. > > The programmer can fully qualify the function call > > (S*ystem.KB.set* ?identifier ?slot ?value) > > Or the programmer can reference the package and use an unqualified call > > (require *System.KB*) > (*set* ?identifier ?slot ?value) > > When *set* is encountered we need to search the required namespaces to > determine > which set function is implied, hence we find *System.KB.set* and replace *set > *with > the fully qualified name. We do this during form evaluation in the > REPL,whether > the REPL is just-in-time compiled or interpreted. > > If we defined *set* as an intrinsic then there would be no package issue, > but also > no modularity. We just encounter *set *and call the *set *intrinsic. So > there is no overhead > incurred by attempting to resolve the function name with a namespace. > > So, my question is, are there any known optimizations to this problem of > resolving > function names with packages? > > ~PM > > ------------------------------ > From: [email protected] > To: [email protected] > Subject: RE: [agi] Namespace search optimization > Date: Thu, 1 Jan 2015 09:03:05 +0000 > > Dictionary lookups (on the first part of the name if the full list is big > compared to RAM)? > ------------------------------ > *From:* Piaget Modeler via AGI [[email protected]] > *Sent:* 01 January 2015 05:53 > *To:* AGI > *Subject:* [agi] Namespace search optimization > > Are there any optimizations that can be done to look up identifiers in > namespaces > for either just in time compilers or interpreters ? > > I'm writing a REPL and namespace resolution of function identifiers > takes too much > time away from overall evaluation. > > Any ideas or thoughts? > > ~PM > > > *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/5404257-22a42d7f> | Modify > <https://www.listbox.com/member/?&;> Your Subscription > <http://www.listbox.com> > ------------------------------ > UNIVERSITY OF CAPE TOWN > > This e-mail is subject to the UCT ICT policies and e-mail disclaimer > published on our website at > http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 > 21 650 9111. This e-mail is intended only for the person(s) to whom it is > addressed. If the e-mail has reached you in error, please notify the > author. If you are not the intended recipient of the e-mail you may not > use, disclose, copy, redirect or print the content. If this e-mail is not > related to the business of UCT it is sent by the sender in the sender's > individual capacity. > *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/19999924-4a978ccc> | > Modify <https://www.listbox.com/member/?&;> Your Subscription > <http://www.listbox.com> > *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/19999924-4a978ccc> | > Modify <https://www.listbox.com/member/?&;> Your Subscription > <http://www.listbox.com> > *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/24379807-653794b5> | > Modify <https://www.listbox.com/member/?&;> Your Subscription > <http://www.listbox.com> > > > *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/19999924-4a978ccc> | > Modify <https://www.listbox.com/member/?&;> Your Subscription > <http://www.listbox.com> > *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/24379807-653794b5> | > Modify > <https://www.listbox.com/member/?&;> > Your Subscription <http://www.listbox.com> > ------------------------------------------- AGI Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-f452e424 Modify Your Subscription: https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-58d57657 Powered by Listbox: http://www.listbox.com
