johnlcox / motif Goto Github PK

Let's consider the following naive example:

  static interface Map_<A, B> {
  }

  static class EmptyMap_<A, B> implements Map_<A, B> {
  }

  static class InsertAssoc_<A, B> implements Map_<A, B> {
    public final Pair<A, B> pair;
    public final Map_<A, B> map;

    public InsertAssoc_(Pair<A, B> pair, Map_<A, B> map) {
      this.pair = pair;
      this.map = map;
    }
  }

and now I'd like to define a method put with the following logic:

  public static <A, B> Map_<A, B> put_(final Map_<A, B> ms, final A k, final B v) {
    if (ms instanceof EmptyMap_ || ms == null) {
      return new InsertAssoc_(Pair(k, v), new EmptyMap_<>());
    }
    if (ms instanceof InsertAssoc_) {
      InsertAssoc_<A, B> is = (InsertAssoc_<A, B>) ms;
      if (k.equals(is.pair.getFirst())) {
        return new InsertAssoc_<>(Pair(k, v), is.map);
      } else {
        return new InsertAssoc_<>(Pair(k, v), put_(is.map, k, v));
      }
    }
    throw new IllegalArgumentException();
  }

Trying to do it with Motif as the following leads to compile errors:

  public static <A, B> Map_<A, B> put_motif(final Map_<A, B> ms, final A k, final B v) {
    match((Map_<A, B>) ms).when(caseThat(isA(EmptyMap_.class)))
        .get(x -> new InsertAssoc_<>(Pair(k, v), new EmptyMap_<>()))
        .when(caseThat(isA(InsertAssoc_.class)))
        .get((InsertAssoc_ x) -> k.equals(x.pair.getFirst()) ? new InsertAssoc_<>(Pair(k, v), x.map)
            : new InsertAssoc_<>(Pair(k, v), put_motif(x.map, k, v)));;
    return null;
  }

and the compilation error is basically type mismatch. In this example, I am trying to use Hamcrest matchers. Is there another way? What's the correct way to do this in Motif?

The code-generation branch is already beginning to add the ability to generate all of the case permutations for a given type (e.g. Tuple2 or List) so that they don't have to be handwritten. Currently this requires generating the code and then copying it into a class file.

It would be nice if there was an annotation that could be added to generator classes such that the Cases code gets generated automagically as part of the compile.

In some situations the Java compiler is unable to determine the correct overload to call when using lambdas. See my Stackovervlow question for one example of the ambiguity problem. The ambiguity problem occurs for Function/Consumer overloads, but it also occurs for generic parameter/ArgumentMatcher overloads.

For example a lambda calling getPattern with overloads getPattern(Function<String, String> function) andgetPattern(Consumer<String> consumer) will fail to compile due to ambiguity. The same is true for the following overloads: getPattern(A, Function<A, String> function) and getPattern(ArgumentMatcher, Function<A, String> function).

My initial solution to the Function/Consumer problem is to follow the convention of naming all Function methods as case* and all Consumer methods as caze*. I'm not super happy about this, but I haven't come up with a better alternative so far.

I'm at more of a loss as to what to do for the A/ArgumentMatcher issue. I could drop the exact match APIs entirely and require matchers always, but this adds verbosity even when it's not needed.

If anyone has any thoughts on either of these ambiguity issues I am open to input.