Overloaded record fields

[Malcolm Wallace]

> 
> Simon, Malcolm, here's a solution (at risk of more bikeshedding on syntax).
> 
>    e { foo }
> 
>  * The braces say 'here comes a record'.
>  * Also say 'expect funny business with names'.
>  * The absence of `=` says this is getFld, not update.
>  * This is not currently valid syntax [**], so we don't break code.
>  * It's postfix. (And only a couple more chars than infix dot.)
>  * So perhaps an IDE can see the opening brace and prompt for fields?
>    (Perhaps some IDE's do this already for record update?)

I like it.  It fits with the existing syntax.  Nested records are chained:

    foo{bar}{subbar}{zed}

> Possible future development:
> 
>    e { foo, bar, baz }  -- produces a tuple ( _, _, _ )
>                         -- with fields in order given
>                         -- _not_ 'canonical' order in the data type
> 
>  * By coincidence, that syntax is per one of the dialects for
>    relational algebra projection over a tuple.

Not quite so keen on this.  I would argue that in relational algebra (which I use a lot, although with a dynamically-type API, rather than strongly-typed), the ordering of columns and rows is never significant, and should never be exposed to the user directly.  I long for the day when we can offer a strong-typing to Relations, but it would be worse to pretend that something is kind-of relation-like, without the underlying properties that make it powerful.

Regards,
    Malcolm