Map of symbolic -> textual name conversions.
Map of symbolic -> textual name conversions.
If this map is empty, the macros will not do any special rewriting and all names will be passed through.
Symbolic names should be written as Scala would represent them
internally. For example, +
should be written as $plus
.
Given context and an expression, this method rewrites the tree to call the "desired" method with the lhs and rhs parameters.
Given context and an expression, this method rewrites the tree to call the "desired" method with the lhs and rhs parameters. We find the symbol which is applying the macro and use its name to determine what method to call.
If we see code like:
lhs + rhs
After typing and implicit resolution, we get trees like:
conversion(lhs)(ev).$plus(rhs: A): R
The macro should produce trees like:
ev.method(lhs: A, rhs: A): R
Like binop, but with ev provided to the method instead of to the implicit constructor.
Like binop, but with ev provided to the method instead of to the implicit constructor.
If we see code like:
lhs % rhs
After typing and implicit resolution, we get trees like:
conversion(lhs).$percent(rhs)(ev)
The macro should produce trees like:
ev.mod(lhs, rhs)
Combine an implicit enrichment with a lifting method.
Combine an implicit enrichment with a lifting method.
If we see code like:
lhs + 1
After typing and implicit resolution, we get trees like:
conversion(lhs)(ev0).$plus(1)(ev1): R
The macro should produce trees like:
ev0.plus(lhs, ev1.fromInt(1))
In Spire, this lets us use Ring
's fromInt method and
ConvertableTo
's fromDouble
(etc.) before applying an
op. Eventually, we should generalize the way we choose the
lifting method.
Like binop, but where the implementation comes from a child member
Like binop, but where the implementation comes from a child member
If we see code like:
lhs * rhs
After typing and implicit resolution, we get trees like:
conversion(lhs)(ev).$times(rhs)
The macro should produce trees like:
ev.scalar.times(lhs, rhs)
This is like binopWithLift, but we use the same evidence parameter to make the method call and do the lifting.
This is like binopWithLift, but we use the same evidence parameter to make the method call and do the lifting.
If we see code like:
lhs * 2
After typing and implicit resolution, we get trees like:
conversion(lhs)(ev).$times(2): R
The macro should produce trees like:
ev.times(lhs, ev.fromInt(2))
Provide a canonical mapping between "operator names" used in Ops
classes and the actual method names used for type classes.
Provide a canonical mapping between "operator names" used in Ops
classes and the actual method names used for type classes.
It's worth noting that a particular instance of Ops
must always
map a given symbol a single method name. If you want to be able
to map the same symbol to different names in different contexts,
you'll need to create multiple Ops
instances and configure them
appropriately.
In general "textual" method names should just pass through to the typeclass--it is probably not wise to provide mappings for them here.
Similar to binop, but for situations where there is no evidence parameter, and we just want to call a method on the rhs.
Similar to binop, but for situations where there is no evidence parameter, and we just want to call a method on the rhs.
After typing and implicit resolution, we get trees like:
conversion(lhs).foo(rhs)
and we want to get out:
rhs.foo(lhs)
Provided to make defining things like binopWithScalar easier.
Like binop, but for right-associative operators (eg.
Like binop, but for right-associative operators (eg. +:
).
If we see code like:
lhs *: rhs
After typing and implicit resolution, we get trees like:
conversion(rhs)(ev).$times$colon(lhs)
The macro should produce trees like:
ev.timesl(lhs, rhs)
Like rbinop, but with ev provided to the method instead of to the implicit constructor.
Like rbinop, but with ev provided to the method instead of to the implicit constructor.
If we see code like:
lhs *: rhs
After typing and implicit resolution, we get trees like:
conversion(rhs).$times$colon(lhs)(ev)
The macro should produce trees like:
ev.timesl(lhs, rhs)
Given context, this method rewrites the tree to call the desired method with the lhs parameter.
Given context, this method rewrites the tree to call the desired method with the lhs parameter. We find the symbol which is applying the macro and use its name to determine what method to call.
If we see code like:
-lhs
After typing and implicit resolution, we get trees like:
conversion(lhs)(ev).unary_-(): R
The macro should produce trees like:
ev.negate(lhs): R
A variant of unop which doesn't take an empty parameter list.
Like unop, but with ev provided to the method instead of to the implicit constructor.
Like unop, but with ev provided to the method instead of to the implicit constructor.
If we see code like:
lhs.abs
After typing and implicit resolution, we get trees like:
conversion(lhs).abs(ev: Ev): R
The macro should produce trees like:
ev.abs(lhs): R
Like unop and unopWithEv, but there is ev provided by the implicit constructor, and ev1 provided by the method.
Like unop and unopWithEv, but there is ev provided by the implicit constructor, and ev1 provided by the method.
If we see code like:
lhs.isId
After typing and implicit resolution, we get trees like:
conversion(lhs)(ev: Ev).isId(ev1: Ev1): R
The macro should produce trees like:
ev.isId(lhs)(ev1): R
Given context, this method pulls the 'ev' and 'lhs' values out of
instantiations of implicit -Ops
classes.
Given context, this method pulls the 'ev' and 'lhs' values out of
instantiations of implicit -Ops
classes.
For instance, given a tree like:
new FooOps(x)(ev)
This method would return (ev, x)
.
Given context, this method pulls the 'lhs' value out of
instantiations of implicit -Ops
classes.
Given context, this method pulls the 'lhs' value out of
instantiations of implicit -Ops
classes.
For instance, given a tree like:
new FooOps(x)
This method would return x
.
Macro transformations for operators
This trait has some nice methods for working with implicit
Ops
classes. It is used to rewrite implicit conversions which "enrich" a type with operators into code that does not allocate an implicit instance.