fn create_proof<E>(...)
where
    E: Engine
{
    let blahblah = multiexp::<E>(...);
}

// Engine trait is something like this, it doesn't provide any information more
// than types of the G1 and G2 curves and their underlying primefields.
// Putting the `multiexp()` and `fft()` functions inside the Engine trait would
// require big changes.
pub trait Engine {
    type G1: CurveProjective;
    type G2: CurveProjective;
    type Fr: PrimeField;

    fn miller_loop(...);
    fn final_exponentiation(...);
    fn pairing(...);
}

// Original multiexp is a generic implementation that works for any pairs of types
// that implement CurveProjective and PrimeField traits.
fn multiexp<E>(bases: [E::G1], exps: [E::Fr])
where
    E: Engine
{
    let mut acc = E::G1::zero();
    for b,e bases.zip(exps) {
        acc.add_assign(b.mul(e));
        /* add_assign() and mul() are very different for different Engines and Curves
           So we should probably detect the type of E::G1 and E::Fr somehow and
           generate the OpenCL source codes accordingly.

           There are several ways we can generate the OpenCL codes, which one is better?

           1- Put OpenCL source codes of E::G1 and E::F1 operations inside them,
              get them through a function like: E::Fr::opencl_add_assign_code()
              and concat them later for generating final multiexp kernel, like:
              E::Fr::opencl_add_assign_code() + "\n" + E::G1::opencl_mul_code() + "\n" + "void multiexp(...) {};"

           2- Put entire OpenCL kernel code inside of E, like E::opencl_multiexp_code()

           3- Define a function like get_opencl_code<E>(e: E) where E::Engine { }
              which detects the Engine and generates the code, without changing
              E::G1 and E::Fr types.*/

    }
    return acc;
}