(reset-thing ...) doesn't work with new typed things

[jarcane]

The implementation of reset-thing is incorrect. It works by extending the old thing and trying to rewrite the fields that way.

But this doesn't work anymore with the new (soon to be released) typed thing implementation. I'm not sure if this counts as a bug in things themselves, or in just the weird way reset-thing gets around the lack of a by-name field assignment syntax (see #46) by using thing extends.

Either way warrants investigation.

[jarcane]

For reference, the error is trivially reproducible:

> (describe Foo (bar 1))
> (describe Baz extends Foo (bar 1))
. . >: contract violation
  expected: real?
  given: #<procedure:this>
  argument position: 1st
  other arguments...:

It happens any time you attempt to create a child of a thing with a field of the same name as one of the parent thing's fields.

[jarcane]

On further investigation, this is actually the result of much deeper problems than I realize, which is that a parent thing's types are not properly passed down to the child, so everything goes all squibbly. Time to deal with that can of worms I guess.

[jarcane]

This is fixed. I'm not sure philosophically if it should be, but ... it's fixed, for the sake of not breaking backwards compatibility. But I think the by-name copy syntax in #46 is a better solution, and should be pursued as a better implementation (and maybe some error-checking added to things to prevent this case)

[jarcane]

This is now fixed further in #57 by no longer relying on inheritance to update the thing and instead use the copy syntax.