Microsoft (is it .net?) also allows you to request the type of a variable by using the variable name in a function parameter. So I assume that their object reference to their type "Int32" holds the space for a 32 bit integer value and the variable type along with it. It may hold more than, I was just pointing that fact out.
Jim Bromer On Fri, Jan 2, 2015 at 5:48 PM, John Rose via AGI <[email protected]> wrote: > Not sure if this is what you are asking but in C# you store the type and > the method delegate then combine them both before invoking with > Delegate.CreateDelegate: > > > > > http://msdn.microsoft.com/en-us/library/system.delegate.createdelegate(v=vs.110).aspx > > > > John > > > > *From:* Piaget Modeler via AGI [mailto:[email protected]] > *Sent:* Friday, January 2, 2015 5:03 PM > *To:* AGI > > *Subject:* RE: [agi] Namespace search optimization > > > > Further constraints... > > > > *1. There is a global list of namespaces.* > > > > (namespaces) .: {System Premise Bar Baz} > > > > *2. Qualified functions will be unknown if their namespace is not defined > in the * > > *global list of namespaces.* > > > > (An.Unknown.Namespace.Hello) .: [Exception :Text 'function is not known'] > > > > *3. Each namespace defines zero or more functions and a zero or more > dependent namespaces.* > > > > (namespace Foo > > > > (requires Bar) > > (requires Baz) > > > > (function goodbye {} BYE) > > (function niceToKnowYou {} NTKY) > > > > ) .: Foo > > > > (using Foo) .: Foo ; sets the current namespace, akin to USE <DB> in SQL. > > > > (functions Foo) .: {goodbye niceToKnowYou} > > > > (dependencies Foo) .: {Bar Baz} > > > > > > (functions Bar) .: {wellWell ohISee} > > > > (dependencies Bar) .: { } > > > > > > (functions Baz) .: {thisOne thatOne} > > > > (dependencies Baz) .: { } > > > > > > *4. If an unqualified function is not defined in the current namespace > nor * > > *one of the required namespaces then it is unknown.* > > > > (Hello there) > > > > ~PM > > > > > ------------------------------ > > From: [email protected] > To: [email protected] > Subject: RE: [agi] Namespace search optimization > Date: Fri, 2 Jan 2015 13:37:18 -0800 > > That's a start. > > > > What kind and how could even that be improved? > > > > ~PM > ------------------------------ > > Date: Fri, 2 Jan 2015 15:16:00 -0500 > Subject: Re: [agi] Namespace search optimization > From: [email protected] > To: [email protected] > > 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. > > > > > > > > > > > > > > > > > > > > <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
