To expand a little more on the content language (as opposed to the framework language which might as well be C++): the requirement is for a language in which humans can write code that can then be used as a basis for further development by learning algorithms. This implies several requirements:
Managed language - not just in the obvious sense of no pointer arithmetic or undefined behavior, but in the sense of resource management, e.g. an infinite loop must time out after a certain number of operations. Purely functional so that e.g. pieces of a computation may be updated with new results without having to rerun the entire computation. Compact. Not so much in terms of the text representation - which should be concise by normal standards, but should also be accessible to nonspecialists so probably don't want to go quite as far as the APL family - but in the sense that typical pieces of code should be represented with very few syntax tree nodes. This is a critical issue because the time taken for automatic discovery of code is in general exponential in the size of the generated syntax tree, so this requirement will strongly influence the actual design. It seems to me that the ML family of functional languages with automatic currying represents pretty much the ultimate in compact syntax trees (if we leave aside postfix languages which aren't usable for most human programmers), so that seems to be the way to go (not an off-the-shelf ML/Haskell/F# implementation, which would be ruled out by resource management considerations, but that kind of language design). Do we want static typing? It does have uses for error detection in human-written code and to constrain the search space in automatically generated code. On the other hand, static types and meta-programming make for a slightly awkward combination (what's the type of 'eval'?); it's probably not a coincidence that attempts at meta-programming in ML-family languages have never really worked the way they do in Lisp. But the deciding factor in my opinion is that the resulting system will need to deal with other languages (C, LLVM, SMT-LIB, TPTP etc) which have their own type systems, at least some of which will inevitably be incompatible with any fixed type system we invent; whatever notion of types we have therefore needs to be programmable, so that a type is a predicate that can be checked at run time whenever it wasn't checked at compile time. I think the above are the requirements set by the nature of the problem. Concrete syntax, the fun part of language design, still has plenty of degrees of freedom. ------------------------------------------- AGI Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-c97d2393 Modify Your Subscription: https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-2484a968 Powered by Listbox: http://www.listbox.com
