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

[Peter Schachte]

On Fri, Mar 03, 2006 at 03:18:02PM +1100, Ralph Becket wrote:
> > 	@ syntax in pattern matching
> > 	named field declaration and accessor and setter syntax
> > 	state variables
> > 	DCGs
> 
> The rate at which these were added to a developing language was Very
> Slow.

Not really.  Look at the evolution of other languages.  I can't
remember the last time Java added a new bit of syntactic sugar.
New language features, sure, but not just syntax.  What language can
you name that adds syntactic conveniences as often as Mercury?

> The language would be more complicated because there would be new
> syntax introduced by every nth new module.  It'd be Babel.

It's already babel, with heaps of new semantics introduced by every
module.  The occasional module that also adds the odd operator to make
the code look pretty is really a very small incremental complication.
And since the whole *point* of introducing new operators is to make
code easier to read and understand, they usually don't make code
harder to read.

> the very rare additions we make
> benefit all Mercury users, not one single application.

They also hurt all users by making the Mercury reference manual
thicker and making the language more complex and the learning curve
steeper.  If the additions were in the library, then users wouldn't
have to understand them until they came across code that used them.


On Fri, Mar 03, 2006 at 03:28:44PM +1100, Mark Brown wrote:
> What you are talking about is making the operator table part of the
> *program*.  (In fact, that should be operator table_s_, since there can
> be more than one for any given program.)

Nah, just the *additions* to the operator table.  A very small thing
when taken in the context of the whole program.

> > My point is the Mercury language designers feel no compunction about
> > introducing new operators.
> 
> Yes we do... but not to the extent of sticking to ISO Prolog builtin
> operators, for example.

Certainly not.  I think Mercury's builtin operator table is about
twice the size of Prolog's.  Because to have an operator in any
Mercury code, it has to be part of the language.

> > Why deny the same flexibility to users?
> 
> Beside the point.  The debate is not about what should go in the builtin
> operator table, but whether there should be one fixed operator table that
> is part of the language, or multiple operator tables co-existing.

The debate really comes down to deep-seated philosophy.  Do you fear a
new technology will be abused, so reject it, or do you appreciate how
it can improve things, so embrace it?  It's also an issue of freedom.
Do you want the flexibility to change the language syntax, or can you
always be satisfied with only what's in the language?  The Mercury
team fits into the former category, but asks everyone else to fit into
the latter.

No one would suggest that the set of types or functions or predicates
available to the user should be limited to what is built in.  The
whole point of a programming language is to allow users to extend the
set of builtins.  Why not permit this for syntax as well?

-- 
Peter Schachte              Victory attained by violence is tantamount to a
schachte at cs.mu.OZ.AU        defeat, for it is momentary.
www.cs.mu.oz.au/~schachte/      -- Mahatma Gandhi 
Phone: +61 3 8344 1338      
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------