[mercury-users] Another indexing proposal (was mercury websit e (was Suggestion: new operator))

[Peter Schachte]

On Fri, Oct 20, 2000 at 03:49:12AM -0700, Ralph Becket wrote:
> From schachte at cs.mu.OZ.AU on 20/10/2000 10:24:03
> > 
> > An alternative which is in some ways preferable is parentheses:
> > 
> >     1.  It makes good sense to think of at least maps and arrays, and
> >         maybe strings as well, as functions which can be applied to an
> >         index.
> > 
> >     2.  Mercury already understands Variable(Arguments) syntax.
> > 
> >     3.  FORTRAN uses parentheses for array indexing.  We do want to be
> >         compatible with FORTRAN, don't we? :-)
> > 
> > The only catch is that, of course, you can't apply a data value to some
> > arguments.  It currently doesn't make sense, but that could be changed.
> > The syntax for declaring a type could be extended to allow the user to
> > somehow define what expression should be evaluated when a variable of
> > that type is applied to arguments.
> 
> This isn't quite right.  You *can* apply a value to arguments provided that
> value is a function (the higher order syntax was changed a few months ago).

By "data value" I meant first order data value.


> While it's appealing to think of mapping types as functions from keys to
> values, there are many other operations one can perform on them,
> so this functional view is somewhat misleading.

You can, at least in principle, apply other operations to functions, too
(eg, composition).  I don't see how this is misleading.  If I need to pass a
function from string to int to some predicate, why shouldn't I be able to
pass a map(string,int)?  Even the name "map" suggests that it is essentially
a function.

> Also, it's arguable
> whether, say, strings should be viewed as mapping types at all.

I agree completely.  The question is one of infrastructure; how and where
that infrastructure should be used is another question.

> I really don't like your suggestion for the reason that it (a) requires
> the programmer to be much more careful when parsing higher order code ("is
> it an application or some sort of lookup operation?")

I don't think that's the issue at all.  I think the question is:  is this
variable bound to something I can apply to these arguments?  Why should I
care whether that variable is bound to a function implemented as code or as
a data structure?

> (b) by the same
> token it makes the compiler more complex, (c) requires a non-trivial 
> change to the language and compiler

I'm not sure how much change it requires to the compiler, but it does seem
like it could be a fairly simple front-end thing that could be done right
after type checking.

, and (d) all this for what amounts to
> a little syntactic sugar that - in a different albeit no less concise form -
> can be achieved with no change to the language or compiler by introducing
> the
> `@' convention.

Why does it always seem to be syntax issues that are the most divisive?

But I think it's really more than syntax.  To me the main point is that it
would let me treat a data structure that implements a function as a real
function.  The fact Array(I) looks better than Array at I (at least to me)
stems from the fact that an array is just a finite function.  (John Reynolds
has been suggesting that arrays be thought of as functions for decades.)

-- 
Peter Schachte <schachte at cs.mu.OZ.AU>  Remember, "Euphemisms are for the
http://www.cs.mu.oz.au/~schachte/      differently brained."
Phone:  +61 3 8344 9166                -- jamie at cdevil.unx.sas.com (James
Fax:    +61 3 9348 1184                Cooper) 
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------