search

brownplt / pyret-lang

The Pyret language.
Other
1.07k stars 110 forks source link

refactoring considered harmful (to brands) #188

Open shriram opened 10 years ago

shriram commented 10 years ago

I rewrote a program from constructing new instances of data to using functional update. At the back of my mind I said to myself, "Thank goodness I'm not using cases, because this will now break". I ran the program and of course it worked fine. Except I got test case failures:

Check block: check-block-3
  test (move-airplane-xy-on-tick(world(posn(10, 10), 10)) is world(posn(20, 13), 10)): failed, reason:
Values not equal:
world(posn(20, 13), 10)
world(posn(20, 13), 10)
Your test failed.
jpolitz commented 10 years ago

Equality is also part of what gets overriden on functional update.

I'm not sure how I gave you the impression that cases was the only thing that could break (ironically, until types are checked, it's one of the few things that will still work). It's not that you shouldn't use cases, it's that you can't use instances of data with functional update and expect anything but dot to work afterwords.

This is expected behavior, and you could have really weird things count as instances of your datatype if we allowed functional update on them while preserving their datatype-ness.

jpolitz commented 10 years ago

Also, the error message sucks. I wonder if we should just have functional update be an error on instances of data.