-
Notifications
You must be signed in to change notification settings - Fork 21
Ideas
Parsers should be non-destructive unless there is an explicit instruction to change something, for example 1+1 should not be replaced by the number 2, but rather should be converted to an Expression object representing the expression "1+1".
Certain objects should implement a Bindable interface, which looks like this:
public interface Bindable<Against extends Bindable> {
public Map<Variable, Against> bind(Against against);
}
Anything that is bindable might be substituted by a variable.
A+B = B+A C*(A+B) = CA + CB
Still need parsed entities, representing an unambiguous typed hypothesis as to what a set of tokens means, upon which we can do pattern binding. This is like LastCalc's "bytecode".
Borrow Java's typesystem and reflection or concoct our own?
Use Java's but also build on top of it with maps and lists - but how do we treat these as strongly typed objects, and to what extent do we need to?
What about "go"'s typesystem? Types conform to interfaces automatically based on what methods they support.
Problem: {}'s can't both be objects, and a collection if strongly typed. BUT, they exist in the pre-parsed phase, their exact nature could be determined after parsing.
usecase:
(A+B)C = AC+B*C Both sides reduced to bindable patterns based on mathbiop parsers
Real purpose is hierarchy and bindable, not strongly typed! map and list can be that.
Tokens get scores (Scorer takes care of classes we dont write). Functions are justified by average score several steps afterwards relative to score before transform, aka lookahead.
Internal documentation for LastCalc.com