You're right, that was cut off.  It should be fixed now.

On 04/11/2014 02:43 PM, dwightguth wrote:
> In src/javasources/KTool/src/org/kframework/parser/concrete2/Parser.java:
>
>> +        /**
>> +         * A Function stores this mapping from a context to an AST as it's
>> +         * {@link #mapping} field.  Their are two sorts of mappings: {@link Nil} and {@link One}.
>> +         * A {@link Nil} mapping does not depend on the context in any way.
>> +         * In effect, it represents a constant Function that ignores its argument.
>> +         * A {@link One} mapping, on the other hand, depends on one layer of context.
>> +         * It does this by storing input/output pairs.  These pairs are populated
>> +         * dynamically based on what input contexts actually occur, so this
>> +         * mapping may grow when new contexts are added to a {@link NonTerminalCall}.
>> +         * The reason we have both {@link Nil} and {@link One} is that several operations
>> +         * on {@link Nil} can be done much more efficiently than on a {@link One}.
>> +         *
>> +         * For example, a {@link Nil} containing the set {+(), -()} maps every context to those two values.
>> +         * On the other hand, a {@link One} containing the map {*() |-> {+(), -()}}
>> +         * maps the context *() to the two values +() and -(), but does not have a mapping
>> +         * for other contexts.  In this example, the context *() represents what we expect
>
> Did you mean to continue this sentence? I am assuming this means that
> you have to see * at a specific point in relation to the + or - you are
> parsing in order for it to count, but it reads like the explanation just
> stopped mid-flow.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/kframework/k/pull/361/files#r11548774>.
>