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

[Tyson Dowd]

On 03-Jul-2001, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> On Tue, Jul 03, 2001 at 03:58:29PM +1000, Simon Taylor wrote:
> > On 03-Jul-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > > On 23-Jun-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > > > `Object ^ Field' is just a synonym for `Field(Object)'. I think the
> > > > only argument was that the `Object ^ Field' syntax was a bit redundant.
> > > 
> > > Can I add the note that the redundancy also makes it very explicit.
> > > 
> > > Field(Object) is pretty difficult to tell apart from NotField(Object),
> > > but Object ^ Field is impossible to confuse with NotField(Object).
> 
> Ah, but part of the design is to allow you to create pseudo-fields by
> writing a function or two.  This means that you can use field access
> functions (and field access syntax) outside the defining module without
> forcing yourself to always have that field (as long as you can extract and
> maybe set equivalent information somehow).  So Object ^ field may or may not
> be a real field.

That is fine, this is part of the design that is nice.

But it doesn't have to have the syntax Field(Object).

> > > That is a round-about way of saying -- it would be nice to get rid of
> > > Field(Object) and just use Object ^ Field.  This way you always know
> > > whether a function is intended to be used as a field accessor or not.
> > 
> > I don't understand how you're going to "get rid of" `Field(Object)'.
> > It's useful as a convention to use `Object ^ Field' for field references,
> > but I don't see how the compiler is going to enforce that.
> 
> It could be done, if you're a masochist.  With some declaration that a
> function is a field access or setter function, you could prevent people from
> using ordinary function application syntax.  But why would you want to?

The proposal Fergus talks about (or the one Pete gives) handles this
just fine.

All I want to do is make it clear when you define a field access or
setter function, that you intended it to be one.  Currently field setter
functions are clear, but field getters look like ordinary functions.

> > The lack of distinction between fields and functions was deliberate.
> > It's useful to be able to redefine a field as a pair of functions
> > without changing any of the code that uses the field.
> 
> Agreed.  It's also nice to think of field access as just function
> application.  This makes it seem quite natural to pass a field name where a
> closure is expected, eg mapping over a list of "structures" extracting their
> foo member by doing map(foo, List, Foolist).  (Or do I need a lambda there?)

You mean

	Foolist = map(foo, List)

I'd be happy if this was

	Foolist = map(foo =, List)

or 

	Foolist = map(^ foo, List)

or something like that.


> So Tyson, why do you want to make this distinction so strongly?

I just want to be able to draw the distinction.

For one thing, it makes the .NET mapping nicer, as we can generate a get
and set property for foo = and foo :=

I also think it's a bit of a wart in the current design that you can
write a 
	X = "hello" ^ to_upper

but to_upper is not a field access function and was never intended to be
one.

Tyson.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------