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

[Tyson Dowd]

On 05-Jul-2001, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> On Wed, Jul 04, 2001 at 07:51:57PM +1000, Fergus Henderson wrote:
> > On 04-Jul-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > > 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.
> > 
> > I thought about it a bit more earlier today, and I think I can now better
> > explain my objections to the current design.
> > 
> > Basically want I want is to have a clear mental model of what is going on.
> 
> Sorry, but you can't have one.
> 
> I think we've all agreed it's a good thing to be able to change the
> representation of a data structure without changing its interface.  That
> means that the designer of the data structure reserves the right to lie to
> you about the structure, so you can't have a clear (and accurate) mental
> model.

You certainly can if people simply code according to a standard that
says if the function is '= field_name' then it should have a field like 

It's just a matter of software engineering to get this right.
But it's very nice having the language support a special syntax to get this
right, rather than just telling the user "you are screwed, we introduced
some new syntax, but it doesn't have any way to distinguish it from the
old syntax, so the "new feature" is really just so much syntactic
baggage".

> 
> And anyway, what's the difference?  Asside from representation, how is a
> unary function different than a data member?  If a value is completely
> determined by some term, you can think of it as a property of that term.  It
> *could* always be stored in the term, if there were some reason to.

To me, a field represents a has-a relationship.
I typically assume that the value is the sum of its parts in some way,
and the fields represent the parts.

This is a special case of functions.  A function doesn't necessarily 
represent a part of a value.

> That argument only covers unary functions, but it can kind of be applied to
> higher arity functions, too.  Some properties are parametric.  You have to
> consider an array's elements to be properties of the array, and they need
> parameters.  Which n-ary functions can be seen as yeilding a property of one
> of their arguments and which cannot is not even vaguely clear to me.  It's
> certainly not a crisp, clear distinction.  Is the mapping of an key in a map
> a property of the map once you've specified the key, or a property of the
> key, once you've specified the map?
> 
> To me this is a distinction that doesn't make a difference.  I just look at
> the ^ operator as reverse order function application.  Kind of like the unix
> pipe operator.

I guess it depends how you engineer your programs.  If I read your
programs I suspect I will not be able to maintain them, because I
consider the use of field syntax as somthing that enhances the
documentation value of the program by emphasizing the *has-a*
relationship.

People use ^ in the compiler all over the place, but they could often
use the field_name function instead.  I believe the reason why this is
so is that it conveys more information -- "this is a field, I am getting
it".

But in time, I guess I could learn that for you, there is no has-a
relationship distinction, and the syntax provided in the compiler that I
assumed people would use to emphasize such a distinction has no meaning.
It would take me longer to read all you code (as I cannot use the syntax
to derive additional meaning) but I could still get it.

You are just throwing away information that I would rather keep.

I guess this is your point -- you may write programs that are harder for
me to maintain, but that's just my tough luck.  I shouldn't assume so much,
no warranties are implied, there is no Santa Claus, yada yada.

But the important point for me is that with the current scheme of field
getter syntax, I don't get much of a choice -- the compiler does very
little to encourage the distinction of field selection from reverse
order function application.  

I believe it would make very little difference to your
coding style if ^ was reserved for field selection, '= field_name' was
the field getter function, and there was some other reverse order
function application operator you could use to your hearts content.
But I would be able to look at such code and understand it much more
quickly. 

> > 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.
> 
> What's the difference?  Can you give us an algorithm for deciding whether a
> unary function is "field-like" or not?  If not, then you are creating a
> distinction that different people will use different ways, and you are going
> to draw wrong conclusions (the wrong mental model) from others' decisions.

This is where programming language deisgn meets the cold harsh light of
reality.  Programs are designed, written, maintained by humans.

If you cannot be sure whether something is field-like, then don't worry
about it and don't use it.

I suspect groups of humans will come up with suitable definitions and
standards, and will appreciate some builtin support that helps them keep
what they consider field-like syntactically distinct from what they
consider not-field-like.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------