I'm writing a "Swift Symbolics" package for fun, similar to how sympy, sagemath, MATLAB (MuPAD) or Wolfram's Mathematica work. With Swift it's the first time I'm experimenting with operator overloading and I'm loving having the ability to write something on the lines of
// calculus
let x = Variable("x")
lim(of: 1/x, for: x, to: 0+) // returns +infinity
lim(of: 1/x, for: x, to: 0-) // returns -infinity
or
// algebra
let ZZ = IntegerRing()
let P = ZZ["x"] // returns the polynomial ring in x over ZZ
let Z2 = ZZ / Ideal(2) // returns the ring of integers modulo 2
using almost 1-1 the mathematical standard notations.
In order to let the user type without thinking too much to specify and place the types every time, I wrote an Expression type to be used in the following way:
let expression: Expression = 1 + 3 / 4 - 9 ** 0.5
It's just a simple enum conforming to ExpressibleBy(Integer|Float)Literal
indirect enum Expression: CustomStringConvertible {
case integer(Int)
case real(Double)
case sum(Expression, Expression)
case difference(Expression, Expression)
case product(Expression, Expression)
case division(Expression, Expression)
var description: String {
switch self {
case let .integer(a): return "\(a)"
case let .real(a): return "\(a)"
case let .sum(a, b): return "(\(a) + \(b))"
case let .difference(a, b): return "(\(a) - \(b))"
case let .product(a, b): return "(\(a) * \(b))"
case let .division(a, b): return "(\(a) / \(b))"
}
}
}
// MARK: Literal initialization
extension Expression: ExpressibleByIntegerLiteral, ExpressibleByFloatLiteral {
init(integerLiteral value: IntegerLiteralType) {
self = .integer(value)
}
init(floatLiteral value: FloatLiteralType) {
self = .real(value)
}
}
// MARK: Operations
extension Expression {
static func + (lhs: Self, rhs: Self) -> Self { .sum(lhs, rhs) }
static func - (lhs: Self, rhs: Self) -> Self { .difference(lhs, rhs) }
static func * (lhs: Self, rhs: Self) -> Self { .product(lhs, rhs) }
static func / (lhs: Self, rhs: Self) -> Self { .division(lhs, rhs) }
}
// MARK: - Testing
let e: Expression = 3 + 4.1 / 65 * 2 - 12
dump(e)
that allows me to easily get the operations tree. The user just needs to place ": Expression" after every expression declaration and he'll get more or less the same behavior of sympy.
Unfortunately, with just a couple more operations
let expression: Expression = 3 + 4.1 / 65 * 2 - 12 + 4.1 / 65
the compiler already starts failing to infer the type of every operand
The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions
even though the only valid combination is the one in which every operand is of type Expression.
The only way to make the compiler's life easier is to explicitly write that the first integer literal is an Expression
let expression = 3 as Expression + 4.1 / 65 * 2 - 12 + 4.1 / 65
and it won't raise errors even with a thousand of operations involved. Honestly, I don't like how it looks, so my question is: does Swift's type checker always run from left to right?
If a variable has an explicit "resulting" type, shouldn't this information be used to infer the types of the operands in a top-down way instead of a bottom-up one?
I'm actually reading in lib/Sema and I'm currently using both
swiftc -dump-ast file.swift
and
swiftc -Xfrontend -debug-constraints file.swift
to understand what the type checker does under the hood. Unfortunately with the second command I can only get an output if the type checker completes its job. Is there a way to stop the execution and get the partial output?