[mercury-users] Records

[Juergen Stuber]

Fergus Henderson <fjh at cs.mu.OZ.AU> writes:
> On 03-Nov-1999, Juergen Stuber <juergen at mpi-sb.mpg.de> wrote:
> > Robert Ernst Johann JESCHOFNIK <rejj at cat.cs.mu.OZ.AU> writes:
> > > 
> > > Dang.
> > > It is just that `^' irks me.. I instantly associate it with things like
> > > bitwise operations, pointers in Pascal, etc. 
> > 
> > Not to forget the existential quantification in Prolog.
> 
> Existential quantification isn't used often enough
> in Prolog to make that an important consideration, IMHO.
> 
> Mercury already has a fine syntax for existential quantification
> (`some [Vars] ...').  I don't think we are likely to ever
> support `^' as existential quantification.

No, I didn't want to imply that, actually I dislike that notation.
It was just the first thing that came to my mind when I saw it.

> > > I just get the feeling that it is rather `ugly' syntax;
> > > 
> > > 	Field1 = X ^ field1,
> > > 
> > > doesn't look all that nice, and doesn't look like `field1' is a member of
> > > `X', 
> > 
> > I second that.  How about @?
> 
> As someone already said, `^' is nice because it is a relatively small
> symbol, so you can write it with no whitespace without impairing
> readability.  `@' is too dark.  `F = X^field1^field2' is easier to read
> than `F = X at field1@field2', IMHO.

You are right, without spaces around `@' it is not readable,
I didn't think about that.
How about `..'? Light, but could be confused with an interval.
Maybe `^' is not too bad after all.

> `@' is also used in the `@<', `@>', etc. term comparison operators.
> The Mercury standard library module library/prolog.m, which contains
> Prolog-like definitions of various operators, defines these.

I agree that this could be confusing.

> > Even better would be a dot.  I know that it is planned to make
> > `.' the module qualifier eventually, but I think it would be
> > a better idea to junk that proposal, keep `:' as a module qualifier,
> > use `::' for types, modes etc. and depreciate `__':

I forgot to mention that the dot is also used as the list constructor.

> That is a reasonable proposal.
> But I think the main trouble with that proposal is that
> using `::' for both types qualifiers and mode qualifiers
> may lead to some abiguities in the future.
> 
> We definitely want to allow explicit type qualifiers in clauses.
> Currently the plan is for that to use the syntax `Expression : Type'.
> (There's already code in the compiler to handle this, but it's not yet
> enabled because `:' is currently used as module qualifier.)
> 
> We probably also want to allow different clauses for different modes of
> a predicate (perhaps with such predicates defaulting to `impure',
> requiring an explicit `pragma promise_pure' if the different modes have
> the same semantics); currently this is possible using the C interface,
> but it would be nice to have a more direct syntax for that.

That would be nice.  Often you have to use different
algorithms for different modes to be reasonably efficient,
e.g. some clever search for the backward direction.

On a similar note, it would also be nice to get access to
the dictionaries for typeclasses by some kind of low-lewel
Mercury.  Then I could put values such as for example the N
for the type of integers modulo N there and access them
efficiently (there is already a rather inefficient way to do
it with existential types).  This allows to use the standard
infix notation as the N gets passed around in the type, and
the typechecker makes sure I only add two numbers with the
same modulus.

> Now, if we combine both of those extensions, then you could write
> 
> 	foo(X : t) :- ...
> 
> and
> 
> 	foo(X :: m) :- ...
> 
> and they would mean quite different things.
> You could even use them both in the same clause:
> 
> 	foo(X : t :: m) :- ...
> 
> If `::' is to be used for both type and mode qualifiers,
> then that wouldn't work.

That depends on whether you can distinguish types from modes
or not.  Currently you cannot, because they have their own
namespaces and there is a fair amount of overloading.

BTW, will you also support such declarations in goals, or
only in heads as your example suggests?

> > - I still have to use `:' as a module qualifier for infix ops,
> >   `.' is not implemented.
> 
> Generally I wouldn't recommend using any module qualifier
> at all for infix ops like `+'.

So would I, but sometimes it is not easy to avoid.  I have a
module for the typeclass `ring' and bunch of modules that
implement various rings.  I call the addition operation `+'
everywhere, for clarity.  Then in a module for one of the
concrete rings, say polynomials over some base ring, I
import the typeclass to avoid qualifiers for the base ring.
Then I have to use module qualifiers in the instance
declaration, and when refering to the type I just define,
because there is an ambiguity between the names in the
typeclass and in the module.  Actually it is not really an
ambiguity, but the compiler is not clever enough to figure
out that both names are aliases for the same operation.
 
> But in recent development versions, we allow
> 
> 	Foo `qualifier__infix_op` Bar
> 
> and hence
> 
> 	Foo `'int__+'` Bar
> 
> Or of course you can use prefix:
> 
> 	'int__+'(Foo, Bar)

That will do nicely, thanks.
I tried it with rotd-1999-09-17 where it didn't yet work.

> > - The change would eventually break existing software.
> 
> You mean software using `__'?

Actually I meant code using `:', but later `__' will of
course also be affected.

> That's true, but we can probably provide automated tools
> to convert existing software.

BTW, how about requiring a language/library version
declaration in every file?  This would make automatic
conversion really easy.  For the (serious) programmer this
would involve no extra work as he could just add it to his
template of boilerplate.

> Still, I'm interested in hearing alternative proposals,
> so if you can come up with a good solution to the issue
> of type and mode qualifiers (see above), then I'd be
> very interested to hear about it.

I'd like to have a general way to attach meta information
such as types and modes, and possibly more general
properties like for instance being nonzero.  So my proposal
would be to use `::' for everything, and make sure that
types, modes, other logical formulae, etc. can be
distinguished.

Jürgen

-- 
Jürgen Stuber <juergen at mpi-sb.mpg.de>
http://www.mpi-sb.mpg.de/~juergen/
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------