David Barbour <[email protected]> writes: > Regarding the language under-the-hood: If we want to automate software > development, we would gain a great deal of efficiency and robustness by > focusing on languages whose programs are easy to evaluate, and that will > (a) be meaningful/executable by construction, and (b) avoid redundant > meanings (aka full abstraction, or near enough). Even better if the > languages are good for exploration by genetic programming - i.e. easily > sliced, spliced, rearranged, mutated. I imagine a developer who favors such > languages would have an advantage over one who sticks with C.
My interest in Programming Language Theory sprang from my interest in AI and code generation (things like the Goedel Machine which Simon mentioned), specifically what makes a language easy/hard to use by a machine. Regarding 'syntaxless' languages, I agree that this is a desirable property for the IR of a program-generator. Due to the combinatorial nature of the problem, we need all the efficiency we can get. Removing syntax can improve this by dramatically reducing the search space without sacrificing potential solutions. However, there can often be a semantic cost in trying to assign meaning to arbitrary combinations of tokens. This can complicate the runtime (eg. using different stacks for different datatypes) and require arbitrary/ad-hoc rules and special-cases (eg. empty stacks). These can make the landscape smoother, but lead to larger solutions (in bits), which is the dominant factor on scaling. It can also make learning/reasoning about the language and problem domain harder for meta-level algorithms, eg. Estimation of Distribution. I think this semantic cost is often not appreciated, since it's hidden in the running time rather than being immediately apparent like malformed programs are. At the end of the day, it doesn't matter if we hit millions of syntax errors if we get good quality solutions in an acceptable amount of time. It may be the case that telling our algorithms when they're making no sense will give them the information they need to find better solutions faster. Cheers, Chris _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
