Expressions #9439

anandthakker · 2017-07-06T21:03:34Z

GL Native portion of mapbox/mapbox-gl-js#4777

Tasks:

anandthakker · 2017-07-07T21:25:20Z

@jfirebaugh @kkaefer this is still very preliminary, but I'd love to get your early 👀 just on the basic class structure here. Definitely no need for line-by-line review -- my question at this point is just: does this overall strategy look reasonable, such that it makes sense to start adding implementations of each specific expression? (You can see +, -, /, * there, which I did just to exercise the setup.)

jfirebaugh · 2017-07-07T22:58:03Z

include/mbgl/style/function/type.hpp

+class Typename;
+class Lambda;
+
+using ValueType = variant<


This encoding of types looks odd to me.

Why do we need both ValueType and Type?

Is it necessary to divide types into "primitives" and other types? That seems like an unnecessary division.

Here's my sketch for how I'd do this. First, the types of values:

class Null {}; class Number {}; class String {}; class Color {}; class Object {}; class Array { Type itemType; optional<std::size_t> length; }; class Value {}; using Type = variant< Null, Number, String, Color, Object, Array, Value>;

Then, you have special stuff for typing lambdas:

class Typename { std::string name; }; class NArgs { std::vector<variant<Type, Typename>> types; }; class Variant { std::vector<variant<Type, Typename>> choices; }; using ResultType = variant< Type, Typename>; using ArgumentType = variant< Type, Typename, NArgs, Variant>; class LambdaExpression { ResultType resultType; std::vector<ArgumentType> argumentTypes; }

Expression::type should be the type of the expression's result, not its lambda type. (When we talk about the "type of an expression" in any language, we're almost always referring to the type of its result value, not the type of the method if it's a method call.)

These suggestions apply to the JS implementation as well.

👍 on organizing things into types-of-values / stuff-for-lambdas.

Is it necessary to divide types into "primitives" and other types? That seems like an unnecessary division

The reason for this was that from the point of view of our code (as opposed to the the pov from 'within' the expression language), all these types are values, not classes.
I.e., there need only ever be a single object representing NumberType, StringType, etc. (So Primitive is just there to be the type of said objects.)

@jfirebaugh what about something like this instead for that first section ("types of values"):

class Type { static Type Null; static Type Number; static Type String; static Type Color; static Type Object; static Type Value; } class Array : Type { Type itemType; optional<size_t> length; }

(It's at least a bit simpler than what's there now by avoiding an unnecessary Primitive class...)

Ah, another thought: i think we should allow Typenames to be considered a valid expression type, so that an Expression can represent an un-typechecked AST. (E.g. before we do type inference, the type of [==, 1, 2] would be T.)

(Alternatively, we could have Expression and TypedExpression, with only the former allowing type to be Typename.)

I'm also on the fence about whether to consider Variant a value type (and also whether to use it to represent Value, as we're currently doing in JS). As of now, Value is the only variant type that an expression can take, but it's conceivable that that could change. I suppose can can cross that bridge later.

jfirebaugh · 2017-07-07T23:06:26Z

include/mbgl/style/expression/expression.hpp

+    Expression(std::string key_, type::Type type_) : key(key_), type(type_) {}
+    virtual ~Expression() {}
+
+    virtual optional<OutputValue> evaluate(float, const GeometryTileFeature&, EvaluationError& e) const = 0;


Suggest packaging the arguments to evaluate in a struct, so if we need to change types or add new parameters it doesn't require touching the definition of every subexpression.

jfirebaugh · 2017-07-07T23:08:19Z

include/mbgl/style/expression/expression.hpp

+    }
+
+    template <class V>
+    static ParseResult parse(const V& value, const ParsingContext& ctx) {


All these parses follow the same form, with only the expression type varying. That suggests it should be defined once as a template on the expression type.

anandthakker · 2017-07-14T01:39:22Z

include/mbgl/style/expression/expression.hpp

+        return isZC;
+    }
+
+    virtual std::unique_ptr<Expression> applyInferredType(const type::Type& type, Args args) const = 0;


This is a broken design: e.applyInferredType wants to return a transformed copy of e, but because it transfers ownership of child expressions, it's destructive of e in the process. Either expressions should be made copyable or this should be replaced with just a setType() that the type inference process can use to refine expression types in place.

Still not super familiar with the typing algorithm, but my gut is that applyInferredType should be combined with typecheck, and return a new AST -- i.e. it transforms itself and recursively transforms child expressions, and all transforms are immutable and return new objects.

anandthakker · 2017-07-14T02:29:01Z

src/mbgl/style/expression/type_check.cpp

+
+using namespace mbgl::style::expression::type;
+
+TypecheckResult typecheck(const Type& expected, const std::unique_ptr<Expression>& e) {


Should this just be a (virtual) method of Expression?

👍 And I still think Typename should be eliminated as a type; a virtual typecheck method could be part of accomplishing that. The other part, I think, is replacing as many uses of Typename as possible with a set of overload signatures. The overload signature should include the return type, and expressions like ==, <, at should have a set of overloads, one for each supported type. Not only will this reduce the need for Typename, it will force us to be more specific about which types these operators support and the definition for each supported type. For example, in the JS implementation I can see that == doesn't work correctly for Color, and < likely should not be defined for Object.

Then for the expression types that are still using Typename, define a custom typecheck method instead.

Sketch of possible definition syntax in JS:

RegisterCompoundExpression('==', [ [BooleanType, NullType, NullType], () => `true`, [BooleanType, NumberType, NumberType], (lhs, rhs) => `${lhs} === ${rhs}`, [BooleanType, StringType, StringType], (lhs, rhs) => `${lhs} === ${rhs}`, [BooleanType, BooleanType, BooleanType], (lhs, rhs) => `${lhs} === ${rhs}`, [BooleanType, ColorType, ColorType], (lhs, rhs) => `${lhs}.equal(${rhs})` ]),

In C++, you could just provide the evaluation methods, and the signatures could be deduced from those.

In C++, you could just provide the evaluation methods, and the signatures could be deduced from those.

Hm, I don't see how this would work... I think we need the list of signatures to be modeled as a value (e.g. std::vector<std::vector<type::Type>>) in order to do type checking. That wouldn't be possible just from the existence of certain evaluation methods, right?

You can translate from compile time C++ types to runtime expression types via templates. You're already doing this for values with valueTypeToExpressionType, and it's also possible to write functionTypeToSignature:

template <class Result, class... Inputs> type::Signature functionTypeToSignature(Result (*fn) (Inputs...) = nullptr) { return Signature(valueTypeToExpressionType<Result>(), valueTypeToExpressionType<Inputs>()...); } // Can be used with deduced template parameters: // functionTypeToSignature([] (bool, float) -> float { return 0.0; }); // or explicitly specified: // functionTypeToSignature<float, bool, float>();

(Again, just a sketch. Haven't tried to compile this.)

anandthakker · 2017-07-19T21:21:21Z

include/mbgl/style/expression/compound_expression.hpp

+// (const EvaluationParameters&, T1, T2, ...) => Result<U>,
+// where T1, T2, etc. are the types of successfully-evaluated subexpressions.
+template <class R, class... Params>
+struct Signature<R (const EvaluationParameters&, Params...)> : SignatureBase {


Signature is probably a misnomer, since this object holds not just the types, but also a pointer to an expression's evaluate implementation.

anandthakker · 2017-07-28T21:23:05Z

@jfirebaugh Got a decent draft implementation of using expressions to drive {Identity,Source,Camera}Function<T>. Still plenty left to do (added to top of ticket), but could you give this another round of 👀 ? mbgl/style/function/convert.hpp and mbgl/style/expression/value.xpp are new & possibly good places to start.

jfirebaugh

(I only reviewed match.hpp/cpp so far.)

jfirebaugh · 2017-07-31T21:06:07Z

include/mbgl/style/expression/match.hpp

+namespace expression {
+
+using InputType = variant<int64_t, std::string>;
+using MatchKey = variant<InputType, std::vector<InputType>>;


I suggest we reduce singletons to one-element vectors as early as possible.

jfirebaugh · 2017-07-31T21:06:44Z

include/mbgl/style/expression/match.hpp

+using InputType = variant<int64_t, std::string>;
+using MatchKey = variant<InputType, std::vector<InputType>>;
+
+template <typename T>


Seems like we need to make a decision. We definitely want to support:

["match", input: T, (label: T | Array<T>, expression: R)..., otherwise: R] (labels must be literals)

for T ∈ {number, string, boolean}. Do we want to support:

["match", input: Value, (label: number | string | boolean | Array<number | string | boolean>, expression: R)..., otherwise: R] (labels must be literals)

My feeling is no on the latter, because I would think that any realistic use case for that could be handled by simply coercing the input to a string and then matching on string keys.

If users really want to distinguish between 0 and "0" or true and "true", they could do things like the following (though I think this would be quite rare):

[ "let", "input", input, [ "match", ["concat", ["typeof", ["var", "input"]], "-", ["to_string", ["var", "input"]]], "string-0", e_a: R, "number-0", e_b: R, ... ] ]

jfirebaugh · 2017-07-31T21:07:44Z

include/mbgl/style/expression/match.hpp

+    }
+
+    EvaluationResult evaluate(const EvaluationParameters& params) const override {
+        const auto& inputValue = evaluateInput(params);


For readability, name the type instead of using auto (unless the type name already appears elsewhere on the line).

jfirebaugh · 2017-07-31T21:08:30Z

include/mbgl/style/expression/match.hpp

+        if (cases.find(*inputValue) == cases.end()) {
+            return otherwise->evaluate(params);
+        }
+        return cases.at(*inputValue)->evaluate(params);


Use an iterator variable rather than finding *inputValue twice (once with find and once with at).

jfirebaugh · 2017-07-31T21:09:15Z

include/mbgl/style/expression/match.hpp

+        assert(isArray(value));
+        auto length = arrayLength(value);
+        if (length < 3) {
+            return CompileError {


JS throws exceptions rather than using a Result type. Should be consistent one way or the other.

jfirebaugh · 2017-07-31T21:13:17Z

src/mbgl/style/expression/match.cpp

+    if (*inputValue == rounded) {
+        return rounded;
+    } else {
+        return EvaluationError {


Do we really want an evaluation error in this case? I'd expect it to use the otherwise value.

Yeah, you're right; since we don't distinguish among numeric types, this shouldn't be treated as a type error

jfirebaugh · 2017-07-31T21:15:54Z

include/mbgl/style/expression/match.hpp

+private:
+    static bool isIntegerValue(const mbgl::Value& v) {
+        return v.match(
+            [] (uint64_t) { return true; },


Need to handle overflowing of int64_t for this case. Also, what about overflowing Number.MAX_SAFE_INTEGER in JS? Should we enforce a range that's compatible with JS?

Hm. Yeah, I suppose we might as well enforce a range compatible with JS.

jfirebaugh · 2017-07-31T21:18:04Z

include/mbgl/style/expression/match.hpp

+            return parsedInput;
+        }
+
+        auto otherwise = parseExpression(arrayMember(value, length - 1), ParsingContext(ctx, {length - 1}, {"match"}));


JS parses the non otherwise branches first. Should be consistent one way or the other.

jfirebaugh · 2017-07-31T21:38:38Z

include/mbgl/style/expression/match.hpp

+        // Expect odd-length array: ["match", input, 2 * (n pairs)..., otherwise]
+        if (length % 2 != 1) {
+            return CompileError {
+                "Missing final output value for \"match\" expression.",


JS error is "Expected an even number of arguments."

jfirebaugh · 2017-07-31T21:46:45Z

include/mbgl/style/expression/match.hpp

+            checkedCases.emplace_back(pair.first, std::move(*checkedOutput));
+        }
+
+        error = matchType(*outputType, (*checkedOtherwise)->getType());


outputType can still be empty here.

anandthakker · 2017-08-13T02:46:01Z

@jfirebaugh stumbled on a dependency issue as I was working on wiring up expression parsing into the mbgl::style::conversion system. Currently, I have a template <typename V> static parse(const V&, ParsingContext) method on each Expression subclass.

The symptom I'm seeing is that, when I try to include expression parsing in the data-driven property value converter (598c7a1), references to conversion methods like isUndefined(rapidjson object) from the expression parse() methods are coming up undefined.

I think the problem is that, due to the following dependency chain...

parser.hpp -> light.hpp -> property_value.hpp -> camera_function.hpp -> mbgl/style/function/convert.hpp -> various Expression subtypes.

... the expressions are included too early -- namely, before rapidjson_conversion.hpp, which is private and only comes in via parser.cpp.

Do you see a way to fix this without moving each expression subclass's parse() to a separate file?

jfirebaugh · 2017-08-14T17:48:17Z

I think you want to split up your conversions into two groups:

Templated conversion from V representing some JSON-like type -- requires rapidjson_conversion.hpp or similar to have been included
Conversion from Stops -- this shouldn't require isUndefined, etc. to be declared

anandthakker · 2017-11-04T01:13:46Z

Reran the function benchmarks, and they're pretty much indistinguishable from #9439 (comment)

anandthakker · 2017-11-04T02:22:39Z

@jfirebaugh okay, I think I've addressed everything from your latest review. Benchmarks are looking okay, and if we're okay with the +300K for now, then I think the only thing outstanding is to add Expression::operator==() (so that *Function::operator==() can do a value == rather than pointer ==). That's WIP in 21172a9.

jfirebaugh · 2017-11-06T19:45:15Z

include/mbgl/style/expression/expression.hpp

+    virtual ~Expression() = default;
+
+    virtual EvaluationResult evaluate(const EvaluationContext& params) const = 0;
+    virtual void eachChild(const std::function<void(const Expression*)>&) const = 0;


Is there a reason the function argument is a pointer rather than a reference?

jfirebaugh · 2017-11-06T19:46:58Z

include/mbgl/style/conversion/property_value.hpp

+                return {};
+            }
+            if (isFeatureConstant(expression->get())) {
+                return { CameraFunction<T>(std::move(*expression)) };


Isn't the findZoomCurve check needed here too?

jfirebaugh · 2017-11-06T20:20:11Z

src/mbgl/style/expression/step.cpp

+
+    // consume the first output value, which doesn't have a corresponding input value,
+    // before proceeding into the "stops" loop below.
+    auto first_output = ctx.parse(arrayMember(value, 2), 2, outputType);


firstOutput

jfirebaugh · 2017-11-06T20:23:30Z

src/mbgl/style/expression/step.cpp

+            return ParseResult();
+        }
+
+        if (*label < previous) {


jfirebaugh · 2017-11-06T20:23:42Z

src/mbgl/style/expression/step.cpp

+    for (std::size_t i = 3; i + 1 < length; i += 2) {
+        const optional<mbgl::Value> labelValue = toValue(arrayMember(value, i));
+        optional<double> label;
+        optional<std::string> labelError;


jfirebaugh · 2017-11-06T20:28:34Z

src/mbgl/style/expression/value.cpp

+
+            if (!itemType) { itemType = {type::Value}; }
+
+            return type::Array(*itemType, arr.size());


Could use itemType.value_or(type::Value) here.

jfirebaugh · 2017-11-06T20:35:01Z

src/mbgl/style/expression/value.cpp

+                const std::string tname = type::toString(t);
+                if (!itemType) {
+                    itemType = {t};
+                } else if (type::toString(*itemType) == tname) {


It looks like we can use a direct == here now rather than stringifying.

jfirebaugh · 2017-11-06T20:44:42Z

src/mbgl/style/expression/value.cpp

+        [&] (const std::unordered_map<std::string, Value>& obj) {
+            writer.StartObject();
+            for(const auto& entry : obj) {
+                writer.String(entry.first);


writer.String → writer.Key

jfirebaugh · 2017-11-06T21:37:11Z

src/mbgl/style/expression/at.cpp

+    }
+
+    const auto i = *fromExpressionValue<double>(*evaluatedIndex);
+    const auto inputArray = *fromExpressionValue<std::vector<Value>>(*evaluatedInput);


Is it possible to convert just the indexed value, rather than the whole array?

fromExpressionValue(v), where T is member of expression::Value, is a no-op conversion, equivalent to v->get(). I'll rewrite using the latter, since it's clearer.

- Disallow duplicate stops - Ignore the no-token-replacement-for-expressions test

Refs mapbox/mapbox-gl-js#5611

anandthakker mentioned this pull request Jul 6, 2017

Project Arbex (Arbitrary Expressions) mapbox/mapbox-gl-js#4777

Merged

15 tasks

anandthakker added Core The cross-platform C++ core, aka mbgl feature ⚠️ DO NOT MERGE Work in progress, proof of concept, or on hold labels Jul 6, 2017

anandthakker force-pushed the expressions branch 2 times, most recently from 5525b38 to a6d0cf8 Compare July 7, 2017 21:17

jfirebaugh reviewed Jul 7, 2017

View reviewed changes

anandthakker force-pushed the expressions branch from 61bf639 to 456a1f6 Compare July 13, 2017 20:33

1ec5 mentioned this pull request Jul 13, 2017

Reimplement MGLStyleValue atop NSExpression #8074

Closed

anandthakker commented Jul 14, 2017

View reviewed changes

anandthakker force-pushed the expressions branch 2 times, most recently from 636e250 to a5b2f6a Compare July 19, 2017 21:14

anandthakker commented Jul 19, 2017

View reviewed changes

anandthakker force-pushed the expressions branch 2 times, most recently from e470b06 to ca091ab Compare July 21, 2017 20:57

jfirebaugh reviewed Jul 31, 2017

View reviewed changes

anandthakker force-pushed the expressions branch 3 times, most recently from 62049c6 to 2746c28 Compare August 13, 2017 02:44

anandthakker force-pushed the expressions branch from 2746c28 to e40b24b Compare August 13, 2017 02:53

anandthakker force-pushed the expressions branch 3 times, most recently from 80508d0 to ce48199 Compare August 17, 2017 19:07

anandthakker force-pushed the expressions branch from 1abafec to aa0d71a Compare November 2, 2017 12:26

Split "curve" into "step" and "interpolate" expressions

ac86e41

anandthakker force-pushed the expressions branch from aa0d71a to ac86e41 Compare November 2, 2017 12:44

Anand Thakker added 2 commits November 3, 2017 16:05

Fix == check for {Source,Camera,Composite}Function

9f198bd

Ignore query test that will be fixed by viewport-collision

2706da3

wip - add Expression::operator==()

21172a9

anandthakker force-pushed the expressions branch from 1d2600a to 21172a9 Compare November 4, 2017 02:24

Anand Thakker added 2 commits November 4, 2017 16:15

Clean up operator==() implementation

59319f2

Add unit test for Expression::operator==()

c67aa8f

anandthakker force-pushed the expressions branch from b9b3438 to c67aa8f Compare November 6, 2017 18:29

jfirebaugh reviewed Nov 6, 2017

View reviewed changes

Anand Thakker added 2 commits November 6, 2017 17:03

Address more review notes

9d5def1

Take reference rather than pointer in eachChild callback

1147387

anandthakker mentioned this pull request Nov 7, 2017

Port: Expressions for "enum"-typed properties need a post-evaluation validation step #10396

Closed

Catch up with gl-js

77405b2

- Disallow duplicate stops - Ignore the no-token-replacement-for-expressions test

anandthakker force-pushed the expressions branch from e7ddf31 to 77405b2 Compare November 7, 2017 12:43

Anand Thakker added 2 commits November 7, 2017 16:22

Extract InterpolateBase to de-templatize findZoomCurve

d2d1e61

Port stricter zoom expression validation

d0666c9

Refs mapbox/mapbox-gl-js#5611

anandthakker force-pushed the expressions branch from 424bfbe to d0666c9 Compare November 8, 2017 03:02

Couple more cleanups

46c2e34

jfirebaugh approved these changes Nov 8, 2017

View reviewed changes

anandthakker changed the title ~~[core] WIP - Expressions~~ Expressions Nov 8, 2017

anandthakker merged commit f648cfe into master Nov 8, 2017

anandthakker deleted the expressions branch November 8, 2017 17:34

tobrun removed the ⚠️ DO NOT MERGE Work in progress, proof of concept, or on hold label Nov 27, 2017

tobrun mentioned this pull request Dec 7, 2017

Expressions #10654

Merged

24 tasks

This was referenced Dec 18, 2017

Reimplement style values atop NSExpression #10726

Merged

Show the contour-label symbol in meters or feet #5018

Closed


		using namespace mbgl::style::expression::type;

		TypecheckResult typecheck(const Type& expected, const std::unique_ptr<Expression>& e) {


		if (!itemType) { itemType = {type::Value}; }

		return type::Array(*itemType, arr.size());

Expressions #9439

Expressions #9439

Conversation

anandthakker commented Jul 6, 2017 • edited Loading

anandthakker commented Jul 7, 2017 • edited Loading

jfirebaugh Jul 7, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

anandthakker Jul 8, 2017 • edited Loading

Choose a reason for hiding this comment

anandthakker Jul 8, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

anandthakker Jul 14, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jfirebaugh Jul 14, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

anandthakker commented Jul 28, 2017

jfirebaugh left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

anandthakker commented Aug 13, 2017

jfirebaugh commented Aug 14, 2017

anandthakker commented Nov 4, 2017

anandthakker commented Nov 4, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

anandthakker commented Jul 6, 2017 •

edited

Loading

anandthakker commented Jul 7, 2017 •

edited

Loading

jfirebaugh Jul 7, 2017 •

edited

Loading

anandthakker Jul 8, 2017 •

edited

Loading

anandthakker Jul 8, 2017 •

edited

Loading

anandthakker Jul 14, 2017 •

edited

Loading

jfirebaugh Jul 14, 2017 •

edited

Loading

anandthakker commented Nov 4, 2017 •

edited

Loading