David Barbour <[email protected]> writes: > On Thu, Sep 5, 2013 at 5:35 AM, Chris Warburton > <[email protected]>wrote: >> >> 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). >> > > The concatenative language I'm developing uses multiple stacks, but it's > about "different stacks for different tasks". I think this works well > conceptually, when dealing with concurrent dataflows or workflows.
The system I had in mind when I wrote this was the "Push 3" language, which is designed for genetic programming. Its types are integers, booleans, floats and code, and to prevent type errors like "true 5 +" it uses a different stack for each type, so in that example "true" will be pushed to the boolean stack, "5" will be pushed on to the integer stack and "+" will act on the integer stack (or float stack, depending whether we write "INTEGER.+" or "FLOAT.+"). Unfortunately this leads to a proliferation of stack-manipulation functions; by my reckoning there are 54 primitives (9 instructions * 6 stacks, including the NAME and EXEC stacks). It also makes polymorphism impossible (eg. a generic + for floats and ints). >> 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. > > > Eh, that isn't an issue, really. Creating strongly type-safe concatenative > languages (where types are fully inferred) isn't difficult. We can ensure > it is "immediately apparent" that programs are malformed without actually > running them. I agree that we can catch erroneous programs statically, if the language allows errors. However, many languages designed for genetic programming actually get rid of errors completely (eg. by skipping nonsensical instructions); I was pointing out how this can cause inefficiencies, despite it narrowing-down the search space. Push 3 pays by having longer encodings, which requires the search to correctly set more bits. Since this price is paid by every token in every candidate, it can impact scaling. Choosing concatenative and syntax-free languages is probably a good choice for generating programs since it removes the possibility of syntax errors, but removing the possibility of errors completely isn't always a good thing. We could even use multiple machine-readable error messages (eg. numbered errors) to give information to a meta-learning layer about what it's doing wrong. Cheers, Chris _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
