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 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
