[m-rev.] field syntax (was: smart recompilation)

[Ralph Becket]

My thoughts go like this:

Say I have a value of some type.
I (or the compiler) implement various functions on that type.
Some of these functions can be viewed as projecting/updating fields 
of that value.
Some `fields' may be read-only.
Some `fields' may be virtual in the sense that reading/updating them
requires more processing than simple field projection/substitution.
Some `fields' are indexed or parametric (e.g. map__elem).

The classical view of a field is probably best described as an aspect
of a value that can be accessed in constant time by projection and
updated by substitution.  Many languages have special syntax for these 
kinds of operations.

In the presence of user-definable access functions (q.v. C# properties
etc.) I can no longer assume the classical point of view when looking
at a piece of field update syntax.

But it doesn't bother me.  Given that to_upper is a function, 
I can view `"Hello, World" ^ to_upper' as accessing a read-only field,
invoking a function method on a string object, or as (a possible abuse 
of) a kind of reverse function application.

So...

> From: Fergus Henderson [mailto:fjh at cs.mu.OZ.AU]
> Sent: 04 July 2001 10:52
> 
> In my mental models, I distinguish between field-like things
> (a.k.a. "attributes" in Eiffel/Sather or "properties" in C#)
> and arbitrary functions (such as `to_upper').  This is an
> important distinction in the way I think about things.

I don't really understand what the distinction is, except perhaps
that (^) can be used with functions that were not explicitly
defined with the particular value in mind, e.g.

	"Hello, World" ^ univ

But as I've said, this doesn't look too bad to me - it's just a
bit odd.

Could you give an example where not having the distinction you
mention would cause confusion?

- Ralph
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------