4 ms·

While I embrace this feature something about using "equal/assignment" bothers me, I prefer "as" binding in "with" statement style case Point as (0, y):

quietbritishjim 6y ago
That doesn't resolve (at least not obviously to me) the ambiguity where you want to match a Point where the first value is equal to the existing variable x, while the second value is anything and you want to capture it in a new variable y. I prefer the suggestion that appeared at one point where captured variables would have to be suffixed with ?, like this: case Point(x, y?): For those not aware, the solution today is that x must contain a . in its name by virtue of being a member of an object or an imported module: case Point(something.x, y):
- coldtea 6y ago
  >the solution today is that x must contain a . in its name A crappy solution, if I ever saw one...
- pkolaczk 6y ago
  case Point(x, y) if x == something Where's the problem?
  - quietbritishjim 6y ago
    Syntax cleanliness is ultimately subjective, so if you don't see a problem with that then I don't think I can persuade you. To me, it just seems obvious that it's more painful than what I wrote. But I'll mention a couple of specific reasons anyway: * The most concerning thing is knowing to write that in the first place. I think that if the ? syntax were the real one then you'd soon get used to writing a snippet like in my comment, but with the current syntax it's always going to take a bit of mental mind bending to come up with what you've written. * Even if you get it right when writing it, what you've written is vastly more verbose, and adding that redundant variable name (twice!) is just going to be distracting when reading it back. By the way, what you wrote is not equivalent to what I wrote (I wonder if that means your snippet is not as obvious as you're suggesting): you've matched against "something" rather than "x". Instead you'd need to do: case Point(also_x, y) if also_x == x:
    - pkolaczk 6y ago
      > The most concerning thing is knowing to write that in the first place This is something you learn from reading the docs / book on the feature. This applies to all language features. > Even if you get it right when writing it, what you've written is vastly more verbose Slightly more verbose, but also more consistent with the rest of Python syntax. Python syntax already has `if` clause that's well understood, while you're proposing a special-case syntax. I believe language consistency beats brevity, and explicit is better than implicit. BTW the ? syntax looks to me very similar to optional / null-aware / error-aware dereferencing operator used in some other languages (Kotlin, Groovy, Rust).
      - quietbritishjim 6y ago
        > This is something you learn from reading the docs / book on the feature. This applies to all language features. Surely you agree that, even having read and understood documentation for a language feature, there are differing levels of difficulty in using it? That depends on intrinsic complexity of the feature and also the incidental complexity from the design of the language feature. Your comment seems to imply that it doesn't matter what syntax the language feature uses because you'll have to learn about it in any case. I'm sure you don't really mean that! > I believe language consistency beats brevity, and explicit is better than implicit. I agree with both parts of this statement, I just disagree that the syntax they chose satisfies it. The syntax is not consistent with anything else, because nowhere else can you have (0, x, foo.y) mean "assign to x (but don't assign to 0 or foo.y)". That includes if statements, with statements, and left hand side of assignment statements. Choosing a new syntax for something that has different behaviour from existing syntax actually is being consistent. Similarly, using a character like ? (or some other distinctive syntax) to demark which parts are being used for pattern matching is being explicit. In Point(x, foo.y, 0), saying that only x is assigned to because it's not a literal or dotted seems like a great example of implicit behaviour to me. Again, like I said at the start, this is all subjective so I think we'll have to agree to disagree. I just wanted to object to those quoted sentences because it looked like you were saying that it is objectively true that ? syntax is implicit and inconsistent while the syntax they chose is explicit and consistent - and that isn't objectively true.
- breuleux 6y ago
  I tend to bind more often than matching the value of an existing variable, so personally I would have opted for something like this: case Point(== x, y):
prionassembly 6y ago
I've really taken to writing a lot of Hy [0] -- somewhat irresponsibly, since Hy is maintained by a ragtag band of brilliant mavericks; but `hy2py` works great if you `eval-when-compile` most of your macros. Anyway, Hy syntax is ``` (with [f open(file 'r)] (do stuff)) ``` rather than ``` with open(file,'r') as f: ``` I switch [1] to Python (often to write tests in a language the node.js crew will be able to skim) and the one thing that trips me always is the wrong ordering of the `with` statement in straight Python. You don't say `for range(10) as x`... I hope the Hy crew do the sensible thing about case statements. I don't even know what the sensible thing is, though. [0] http://hylang.org http://hylang.org [1] Yes, you can import Hy code from Python and vice-versa!
- przemub 6y ago
  Oh, another Hy user in the wild! I started using it and took liking to it, but it seems kind of dead. Are you using it in any public projects?

quietbritishjim 6y ago

That doesn't resolve (at least not obviously to me) the ambiguity where you want to match a Point where the first value is equal to the existing variable x, while the second value is anything and you want to capture it in a new variable y. I prefer the suggestion that appeared at one point where captured variables would have to be suffixed with ?, like this: case Point(x, y?): For those not aware, the solution today is that x must contain a . in its name by virtue of being a member of an object or an imported module: case Point(something.x, y):

coldtea 6y ago
>the solution today is that x must contain a . in its name A crappy solution, if I ever saw one...
pkolaczk 6y ago
case Point(x, y) if x == something Where's the problem?
- quietbritishjim 6y ago
  Syntax cleanliness is ultimately subjective, so if you don't see a problem with that then I don't think I can persuade you. To me, it just seems obvious that it's more painful than what I wrote. But I'll mention a couple of specific reasons anyway: * The most concerning thing is knowing to write that in the first place. I think that if the ? syntax were the real one then you'd soon get used to writing a snippet like in my comment, but with the current syntax it's always going to take a bit of mental mind bending to come up with what you've written. * Even if you get it right when writing it, what you've written is vastly more verbose, and adding that redundant variable name (twice!) is just going to be distracting when reading it back. By the way, what you wrote is not equivalent to what I wrote (I wonder if that means your snippet is not as obvious as you're suggesting): you've matched against "something" rather than "x". Instead you'd need to do: case Point(also_x, y) if also_x == x:
  - pkolaczk 6y ago
    > The most concerning thing is knowing to write that in the first place This is something you learn from reading the docs / book on the feature. This applies to all language features. > Even if you get it right when writing it, what you've written is vastly more verbose Slightly more verbose, but also more consistent with the rest of Python syntax. Python syntax already has `if` clause that's well understood, while you're proposing a special-case syntax. I believe language consistency beats brevity, and explicit is better than implicit. BTW the ? syntax looks to me very similar to optional / null-aware / error-aware dereferencing operator used in some other languages (Kotlin, Groovy, Rust).
    - quietbritishjim 6y ago
      > This is something you learn from reading the docs / book on the feature. This applies to all language features. Surely you agree that, even having read and understood documentation for a language feature, there are differing levels of difficulty in using it? That depends on intrinsic complexity of the feature and also the incidental complexity from the design of the language feature. Your comment seems to imply that it doesn't matter what syntax the language feature uses because you'll have to learn about it in any case. I'm sure you don't really mean that! > I believe language consistency beats brevity, and explicit is better than implicit. I agree with both parts of this statement, I just disagree that the syntax they chose satisfies it. The syntax is not consistent with anything else, because nowhere else can you have (0, x, foo.y) mean "assign to x (but don't assign to 0 or foo.y)". That includes if statements, with statements, and left hand side of assignment statements. Choosing a new syntax for something that has different behaviour from existing syntax actually is being consistent. Similarly, using a character like ? (or some other distinctive syntax) to demark which parts are being used for pattern matching is being explicit. In Point(x, foo.y, 0), saying that only x is assigned to because it's not a literal or dotted seems like a great example of implicit behaviour to me. Again, like I said at the start, this is all subjective so I think we'll have to agree to disagree. I just wanted to object to those quoted sentences because it looked like you were saying that it is objectively true that ? syntax is implicit and inconsistent while the syntax they chose is explicit and consistent - and that isn't objectively true.
breuleux 6y ago
I tend to bind more often than matching the value of an existing variable, so personally I would have opted for something like this: case Point(== x, y):

prionassembly 6y ago

I've really taken to writing a lot of Hy [0] -- somewhat irresponsibly, since Hy is maintained by a ragtag band of brilliant mavericks; but `hy2py` works great if you `eval-when-compile` most of your macros. Anyway, Hy syntax is ``` (with [f open(file 'r)] (do stuff)) ``` rather than ``` with open(file,'r') as f: ``` I switch [1] to Python (often to write tests in a language the node.js crew will be able to skim) and the one thing that trips me always is the wrong ordering of the `with` statement in straight Python. You don't say `for range(10) as x`... I hope the Hy crew do the sensible thing about case statements. I don't even know what the sensible thing is, though. [0] http://hylang.org http://hylang.org [1] Yes, you can import Hy code from Python and vice-versa!

przemub 6y ago
Oh, another Hy user in the wild! I started using it and took liking to it, but it seems kind of dead. Are you using it in any public projects?