[m-dev.] 0.13 release: op/3 syntax

[Ralph Becket]

Peter Schachte, Monday,  6 March 2006:
> 
> Oh yeah, but Newbie code is always dreadful.  Let's agree that newbies
> should have to earn a license before adding op declarations.

Unfortunately, even most people who fancy themselves licensed Prolog
programmers are prone to get it wrong, IMHO.

Part of the problem is that syntax is very much a matter of aesthetics
and, judging by every syntax war I've ever read, there seems to be
little concensus on what constitute good aesthetics.

> But if we omitted every feature newbies could screw up, there wouldn't
> be much of Mercury left.

True, but we should nevertheless remain cautious about new language
features.

> > > 	3) On the rare occasions when there is a genuine ambiguity,
> > > 	   how hard is it really to look at a couple of op
> > > 	   declarations to figure it out?  
> > 
> > Well, yes - see Mark's signature-with-type-class-constraints example.
> 
> The problem with that example for me is that I don't understand what
> it means.

:- some [T] impure pred foo(S::in, T::out) is det => baz(T) <= bar(S)

For any type S that is an instance of bar/1,
there is some (unspecified) type T that is an instance of baz/1,
such that for all X:S, Y:T, foo(X, Y).

In other words, the caller of foo/2 gets to specify S, but foo/2 gets to
specify T.

> If I knew what the parse tree was supposed to be, it would
> be easy enough to achieve it.  The operators aren't the problem, the
> construct is.  And anyway, this is a problem for the writer, not the
> reader.  I thought we agreed the needs of the reader outweigh the
> needs of the writer?  But go ahead and rewrite Mark's example for us
> without using operators and see who would prefer to read it that way.

It's a horrible example of where Mercury syntax has gone wrong.  Hence
the desire to move to a BNF style grammar at some point.

> > > 	6) Some constructs are just too complex and messy to read (or
> > > 	   write) without operators.  Doug^H^H^H^HPeter's motivating
> > > 	   example is like that, though he can't divulge it.
> > 
> > Which, you must agree, is therefore less convincing!
> 
> OK, here's another example.  It'd be nice if Mercury had list
> comprehensions.  See if you can write a nice powerful list
> comprehension library without using operators.  How readable is the
> code that uses it?

Crikey, you want to start another syntax war? :-)

I might suggest something like

	X * Y where X`in`1..Y where Y`in`1..10, prime(X + Y)

But Mark and I rather like Sebastian's suggestion that we steal
Eclipse's more general iteration schemata (see the list archives).
But until we've got the semantics sorted out, we promise not to suggest
any syntax!

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