mulesoft-labs / data-weave-rfc

RFC for the data weave language
13 stars 5 forks source link

Update syntax question #8

Open menduz opened 5 years ago

menduz commented 5 years ago

For the sake of consistency, writing the paths as regular selectors may be a good alternative for the parser, and to understand the changes easier since it recalls the JSONPath expressions.

payload update {
-  case at  .foo.bar -> 'foo'
+  case at $.foo.bar -> 'foo'
}
payload update {
-  case v at  .foo.bar -> v + 1
+  case v at $.foo.bar -> v + 1
}
machaval commented 5 years ago

But isn't this the same as in pattern matching

foo match {
 case is String -> $
}

If we changed to your way this would not be consistent with this no?

It should have been

foo match {
 case $ is String -> $
}

Thanks for your feedback we are glad and missing it a lot ❤️

menduz commented 5 years ago

Adding the NameIdentifier to the case is matcher may not be a breaking change if optional.

- 'case'                   'is' <TypeExpression> '->' <Expr>
+ 'case' <NameIdentifier>? 'is' <TypeExpression> '->' <Expr>

and as usual $ is implicit, so it may not be required to be used later on.

https://github.com/lys-lang/lys/blob/master/test/fixtures/semantics/patternMatching.lys#L17-L18

machaval commented 5 years ago

To me this

payload update {
-  case v at  .foo.bar -> v + 1
+  case v at $.foo.bar -> v + 1
}

looks to much overhead to me. I hate syntax discussions but I do prefer

payload update {
   case v at  .foo.bar -> v + 1
}

But here I'm not sure what to do

payload update {
   case at  .foo.bar -> v + 1
}

vs

payload update {
   case  .foo.bar -> v + 1
}

@leansh liked this one