Struct Eval 

pub struct Eval {}

Trait Implementations

impl Clone for Eval

fn clone(&self) -> Eval

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Eval

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'t> Reifiable for Eval

fn ty() -> Ast

The Unseemly type that corresponds to to the Reifiable type. This leaves abstract the type parameters of Self; invoke like Self::<Irr,Irr>::ty(). e.g. ∀ A. Pair<A int> TODO: rename to generic_ty

fn ty_name() -> Name

A name for that type, so that recursive types are okay. Ignore the type parameters of Self; invoke like Self::<Irr,Irr>::ty_name(). e.g. WithInteger

fn concrete_arguments() -> Option<Vec<Ast>>

fn reify(&self) -> Value

The Unseemly value that corresponds to a value.

fn reflect(v: &Value) -> Self

Get a value from an Unseemly value

fn ty_invocation() -> Ast

How to refer to this type, given an environment in which ty_name() is defined to be ty(). Parameters will be concrete. e.g. WithInteger<Float> (Types using this type will use this, rather than ty) Don’t override this.

impl WalkMode for Eval

type Elt = Value

The object type for the environment to walk in.

type Negated = Destructure

The negated version of this walk

type AsPositive = Eval

If this walk is positive, Self; otherwise Self::Negated

type AsNegative = Destructure

If this walk is positive, Self::Negated; otherwise Self

type Err = ()

type D = Positive<Eval>

type ExtraInfo = ()

Any extra information the walk needs

fn name() -> &'static str

fn get_walk_rule(f: &Form) -> WalkRule<Eval>

fn automatically_extend_env() -> bool

Should the walker extend the environment based on imports? Only QQ and Expand have this as false; it’s not 100% clear what’s special about them. (This evolved over time; it used to be false for Eval, because of lambda). It seems like the thing about those modes is (a) they don’t look at variables, so their environments are irrelevant, (b) SameAs switching to the negated mode and doing get_res doesn’t work. But what unites those two factors?

fn walk_var(n: Name, cnc: &LazyWalkReses<Eval>) -> Result<Value, ()>

fn underspecified(_: Name) -> Value

Make up a special Elt that is currently “underspecified”, but which can be “unified” with some other Elt. If that happens, all copies of this Elt will act like that other one.

fn needs__splice_healing() -> bool

Do we ever need to treat certain forms as though they were repetitions?

fn perform_splice_positive( _: &Form, _: &LazyWalkReses<Self>, ) -> Result<Option<(Vec<Assoc<Name, Self::Elt>>, Ast)>, Self::Err>

A little like get_walk_rule always returning Custom for positive splicing

fn perform_splice_negative( _: &Form, _: &LazyWalkReses<Self>, _context_elts: &dyn Fn() -> Vec<Ast>, ) -> Result<Option<(Vec<Assoc<Name, Self::Elt>>, Ast)>, Self::Err>

A little like get_walk_rule always returning Custom for negative splicing

fn walk_quasi_literally( expected: Ast, cnc: &LazyWalkReses<Self>, ) -> Result<<<Self as WalkMode>::D as Dir>::Out, <Self as WalkMode>::Err>

Walk over the structure of a node, not its meaning. This could be because we’re inside a syntax-quote, or it could be that we are a form (like written-out types or a literal) that acts like a literal. Children are not necessarily walked quasiliterally – maybe they’re an interpolation of some kind – instead, the mode (=quotation depth) and form together decide what to do. If the walk is negative, the result might be MatchFailure

fn out_as_elt(o: <Self::D as Dir>::Out) -> Self::Elt

fn out_as_env(o: <Self::D as Dir>::Out) -> Assoc<Name, Self::Elt>

fn env_as_out(e: Assoc<Name, Self::Elt>) -> <Self::D as Dir>::Out

fn walk_atom( n: Name, cnc: &LazyWalkReses<Self>, ) -> Result<<<Self as WalkMode>::D as Dir>::Out, <Self as WalkMode>::Err>

impl Copy for Eval