Add by-name copy syntax to Things

[jarcane]

When I first started designing Things, I was largely reacting to the sheer amount of syntax involved in Racket structs, so I went in the opposite direction: the pattern syntax for Thing copying. By using quoted lists, you could copy things easily, provided you remembered which order the fields were in.

However, I've increasingly discovered that there are certain language concepts I would like to implement that require it to be possible to copy things by assigning their new field values by name. Any number of features and uses would be opened up by this, potentially even full-blown thing comprehensions.

In the past, I've worked around the lack of this feature by using thing extends, but with the new is-a implementation this can be problematic, as an extended thing does not have identity with the old thing, because it re-calls make-thing and thus generates a new '__ident. Implementing thing inheritance will help with this, and is on the roadmap, but it's still an odd way of doing it, and would create problems in the future if, say, we want to know if a thing is the exact same kind of thing, and not just a descendant of it.

So, some kind of by-field method would be most helpful, and could be as simple as being able to pass an a-list of fields->values, ideally allowing skipping fields.

The question is though, do we want safety checks here, to prevent accidentally writing new fields altogether to the thing? I can think of reasons to allow it, but they would also break the validity of is-a? checks and __ident.

I think at this point I find things coming to more and more of a crossroads between the JavaScript-inspired flexible objects they were, and a more rigid form of user-defined data type akin to Scala case classes or Racket structs.

[jarcane]

I've experimented with this a bit, and done some more thinking:

1. I think this is best implemented as a default method, say 'copy. I found that some odd syntactic ambiguities arise if one is not explicit otherwise.

2. I think that writing whole new fields to the object shouldn't be allowed, as it essentially introduces mutability to objects, and undermines the reliability of identity and inheritance checking.

3. On the other hand, now that object identities track inheritance, the thing extends ... method is now a more viable approach, since the extended thing will still pass is-a? against its parent. There is the question though if we want to do it in a way that preserves strict identity, ie. both '__ident's are eq?.

This will take consideration.

[jarcane]

This will be resolved in #57