On 2/18/07, Mark Waser <[EMAIL PROTECTED]> wrote:
Chuck is also absolutely incorrect that the only way to generate code by code is to use Reflection.Emit. It is very easy to have your code write code in any language to a file (either real or virtual), compile it, and then load the resulting library (real or virtual) anytime you want/need it.
I'm not incorrect--because I never said that. Aki Iskandar brought that issue up. Then I pointed out that .NET code executes much faster than Python. I was not stating or implying that Reflection.Emit was the only means to produce .NET code. My Cobra compiler, for example, currently generates C# instead bytecode for numerous advantages: (a) faster bootstrapping (C# is higher level than bytecode) (b) leverage the excellent bytecode generation of the C# compiler (c) use C#'s error checking as an extra guard against deficiencies in my pre-1.0 compiler
There is absolutely no run-time cost to this method (if you're keeping the compiled code somewhere in your knowledge base) since you're dealing with compiled code (as long as you know how to manage spawning and killing threads and processes so that you don't keep nine million libraries loaded that you'll never use again).
Well "absolutely no run-time cost" is a bit strong. Code generation itself takes time, no matter what technique you use. And if you go the "generate source code route" then writing it to disk, invoking a compiler and linking it back in is a pretty slow process. I've looked for a way to do it all in memory, but haven't found one. (You can actually link in the C# compiler as a DLL so it's resident in your process, but it's API still wants a disk-based file.) But unless you're throwing away your generated code very quickly without using it much (seems unlikely), you'll make up the difference quite easily. And even dynamically loading DLLs and managing how you use them, unload them, etc. has *some* cost.
I also wouldn't sneer at using an established enterprise-class database to serve as one or more of your core knowledge stores. There is *a lot* of
... You are absolutely...correct. I think the utility of existing database servers is very underappreciated in academia and many AI researchers are from academia or working on academia style projects (gov't research grants or work to support research--not that there's anything wrong with that!). But it's too bad as databases have a lot to offer. Anyone, feel free to ask if you want me to expand.
The dumbest thing AGI researchers do is re-invent the wheel constantly when isn't necessary. I'm heartily with Richard Loosemoore and his call for building a research infrastructure instead of all the walled gardens (with long, low learning curves and horrible enhancement curves) that we have currently.
Some reuse is easy. Fairly generic components like languages and databases are easy to leverage on a project. After that, it gets very difficult. Normally, something has be documented, be stable, run fast, be on the same platform *and* be the right fit before it will be adopted on a serious project. Regarding platform, while you and I like .NET some people will reject it because Microsoft (and the former Borland engineers they hired to work on it), created it. I've talked to people who said they would use it if it were open source. So I point them to Novell Mono (the open source clone) at which point they claim they can't use it because Microsoft will eventually shut Novell down. After I point out that Microsoft submitted .NET as a published standard so that projects like Novell Mono could take place, well... then it's on to the next excuse. One legit excuse is that some people already have a huge investment in other platforms (Java) and cannot turn that around in terms of time and money. We're already fragmented. ...
dealing with a whole framework rather than just a language). And, of course, all of this ignore the ultimate trump that several flavors of LISP are available on the .NET framework.
Python also runs on .NET. In fact, Microsoft hired the guy that was implementing Python on .NET and the project (IronPython) is now hosted by Microsoft. So now you can have your cake, generate a new one at runtime, dynamically load it, and eat it, too! -Chuck ----- This list is sponsored by AGIRI: http://www.agiri.org/email To unsubscribe or change your options, please go to: http://v2.listbox.com/member/?list_id=303
