Previously, we had `Aggregate` and `ExprAggregate` as separate classes,
the latter of which representing aggregates that contain only an
expression.
This was a problem for the `rank` aggregate, as it inherited from
`Aggregate`, but _could_ also contain just an expression (even if this
is rather rare).
To fix this, I renamed `Aggregate` to `FullAggregate` (to make the
division clearer), and added a new type `Aggregate` that represents the
union of these two types. Now `Rank` can inherit from the new class
`Aggregate` and everything is dandy.
Previously, we had `Aggregate` and `ExprAggregate` as separate classes,
the latter of which representing aggregates that contain only an
expression.
This was a problem for the `rank` aggregate, as it inherited from
`Aggregate`, but _could_ also contain just an expression (even if this
is rather rare).
To fix this, I renamed `Aggregate` to `FullAggregate` (to make the
division clearer), and added a new type `Aggregate` that represents the
union of these two types. Now `Rank` can inherit from the new class
`Aggregate` and everything is dandy.
We were only including the `strict` variant of `count` and not any of
the other ones (spot the mistake!).
Also, `unique` was added as a recognised aggregate name.
We were only including the `strict` variant of `count` and not any of
the other ones (spot the mistake!).
Also, `unique` was added as a recognised aggregate name.
Mainly adds ones for primitive types.
One peculiarity: the language specification states that the type of
`super` is the same as the type of `this`, and _not_ the type of
the superclass on which the method is actually accessed. This seems a
bit strange to me, so I thought I would highlight it specifically.
Also, I'm not entirely sure that the rules around type coercion for
the various binary operators are 100% correct.
Mainly adds ones for primitive types.
One peculiarity: the language specification states that the type of
`super` is the same as the type of `this`, and _not_ the type of
the superclass on which the method is actually accessed. This seems a
bit strange to me, so I thought I would highlight it specifically.
Also, I'm not entirely sure that the rules around type coercion for
the various binary operators are 100% correct.
Going all the way to the AST layer seemed excessive to me, so I rewrote
it to do most of the logic at the data-flow layer. In principle this
_could_ result in more names being computed (due to splitting), but in
practice I don't expect this make a big difference.
