stephen-zhao / cascas Goto Github PK

Description:

The following entries should be added to the built-in context:

1. List : OperatorType(T: Type)(Type)
2. List(Number) : TypedObject(Type, List(Number))

Item (2) should be added as a temporary measure until #3 can be completed. Then it must be removed (future story).

Split up Expr.scala into numerous files, one for each Expr subclass

• Create the tasks that break down and envelope the following:
• Create translator from parser output (ParseNodes) to the final CaSCAS Lang Internal Language elements (Object, Expr, etc)

e.g.
let y := x + 8;
should not throw a "not in context" error. The x should be implicitly declared.

Moreover, e.g.
let z := x + 3;
should refer to the same x as the previous "let y..." expression, so the x should be implicitly declared in the surrounding scope.

Currently the following are allowed as type labels:

1. Identifier, as in Identifier("x") : Identifier("Number") where Identifier("Number") : Identifier("Type")
2. OperatorType, as in Identifier("f") : OperatorType(Identifier("x"), Identifier("Number"))(Identifier("Number"))

Allowing ApplyExpr gives us the ability to use operators as type identifiers.
This will facilitate what most languages call Type Generics.

e.g.
if
List : OperatorType(T: Type)(Type)
then we can define a list of numbers like this
myListOfNumbers : List(Number)

• analogous to PlusOperator

Right now all function applications look the same. It'd be nice if BuiltIns can define their own toRepr function that is used when the BuiltIn is applied.

It might be worth considering making a set of standardized "looks" for a toRepr.

e.g. A set of toReprs { appearanceBinaryInfixOperator, appearanceStandard, appearanceUnaryPostfixOperator, appearanceUnaryPrefixOperator } and have the developer who creates the Builtin choose among these options as to how their function should look on default when being displayed in a function application.

This probably shouldn't just be an enumeration like above though. It should be smarter (deal with number of operands maybe). The developer should also be able to override with a custom "look".

• Each developer gets his/her own branch + any sub-branching
• Create pull requests to deliver work to branch Master

Remove old files:
*/lang/EvaluatedType.scala
*/lang/Obj.scala
*/lang/Collection.scala
*/lang/Number.scala
.. among others

... or at least place the ParseNodes file in a new package since it is shared between several other components

• IntegerToken needs to extract a value of type BigInt
• DecimalToken needs to extract whole number part and fractional part

Code does not provide the proper behaviour when signs are involved in the numerators / denominators.

Implicit type parameters are needed for operators that cannot infer the types of their parameters, so need general types. The following functionality is needed for this:

1. Object::inferThatType (on a formal parameter) upon returning None will make the decision to prepend the current formal parameter with a type parameter
2. Unique type parameter name generation
3. In an ApplyExpr a type parameter has to be automatically/implicitly passed in before the actual parameter

i.e. def Object::inferThatType (that: Object, ctx: Context): Option[TypeIdentifier]

This method will try to figure out the type of that within the object this given the context ctx.

This should make it easier to implement built-in operators and eliminate repeated boilerplate code.

But we need to "create" the framework first. I think most what currently exists already works. It just needs some revision/polishing and the addition of a generic parameter processor.

As described in the "Ideas to Jot" page on the wiki.