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

[Peter Schachte]

[Moving this to mercury developers...]

On Thu, Jul 05, 2001 at 08:02:47PM +1000, Tyson Dowd wrote:
> 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 

You still can't if individuals can't agree on what's field-like.  That's why
I keep asking, without getting an answer I can use:  what does "field-like"
mean?  Telling me not to use ^ notation for things that aren't field-like
isn't going to help much if we can't agree on exactly what is field-like.
You're still not going to be able to read my code and form the mental models
you are looking for, because I don't share them.  The information you want
simply isn't there.  It would be better for neither of us to try to draw a
distinction than for us to make the distinction and understand it
differently.

So let me ask you to clarify a few examples:

If I have a 2-space position type with x and y fields, are r and theta
"field-like"?  And what if my application uses r and theta so often I decide
to switch to a polar representation?

Is the length of a string "field-like"?  It may or may not be explicitly
stored.  Is an individual character in the string "field-like?"  How about a
substring?  Finding a substring may or may not require copying part of the
string, so efficiency cannot enter into your decision process.  I could even
store as all upper-case characters, and store the case bits separately, so
to_upper could be a field access.

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

I'm afraid that doesn't help me.  What does "has-a" mean?  Does a number
"have a" square root?  Is square root field-like?

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

I suspect it's just because it's easier to read.

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

My point is that it's information I never had.  I question its existence.

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

Do you mean field selection or field-like selection.  If the former, I would
argue strongly against that because it would mean field accessors couldn't
be part of the interface of an ADT, because that would restrict my ability
to change representation.  If you mean the latter, then it wouldn't make
much of a difference at all, because I don't understand what "field-like"
means.  Mostly it would just cause me angst at having to choose when I don't
see a 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.

That doesn't help, because not using field syntax also conveys the
information that something is not field like.  And what if I'm certain it's
field like, but you don't think it is?

I think Simon's right:  this is inevitably a coding standards issue.  If the
Mercury group wants to adopt some definition of "field-like" or some
committee process for deciding which things are field like and which aren't,
and insist that ^ only be used for field-like functions, it can.  In fact,
unless you can give an algorithm for deciding what's field-like, the compiler
can't check it, so it must be handled as a coding standards issue (with the
attendent arguments over whether or not the length of a string is
"field-like").

But I don't believe it's the language designers' place to try to make such
decisions for everyone.  If a group of people who don't see this distinction
want to set standards that permit or even encourage using ^ as merely
reverse order function application, and they're all happy with that
decision, why should the language designers make this less convenient for
them?


-- 
Peter Schachte <schachte at cs.mu.OZ.AU>  The secret of being miserable is to
http://www.cs.mu.oz.au/~schachte/      have the leisure to bother about
Phone:  +61 3 8344 9166                whether you are happy or not. The
Fax:    +61 3 9348 1184                cure is occupation. -- George Bernard
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------