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

[Ralph Becket]

Peter,

are you trolling ? :-)

Peter Schachte, Friday,  3 March 2006:
> 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?

I really don't accept your notion that we're crazily throwing new syntax
into the language at every opportunity.

By the way, each new version of Java has added more syntax.  It might
not have added more operators (I don't know), but so what?

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

?!?!?

Are you seriously equating adding new functionality with changing the
language?

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

We've been over this one.  You say it's good in your experience (based
on writing code), I say it's bad in mine (based on reading code).

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

No, then we'd just have to shift the documentation to the library
modules.

At least with the current scheme you won't find the compiler reporting
strange new syntax errors in a previously working module just because
you added an import_module directive.

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

You're talking about implementation, which we agree is not hard (until
you consider separate compilation...)

The discussion is about the desirability of a feature.

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

We've just stripped out a whole load of aditi related operators and, if
a new change happens, all the various purity and equivalent solutions
promises will (eventually) be replaced under just one: `promise'.

There is a boat load of other operators we could happily get rid of,
including =.., =:=, =\=, @<, @=<, @>, @>=, \==, ~=, ~, &, ==>, and ?-.

But even if we didn't get rid of them, I don't see that you can argue a
rule of language design that runs "if a language has more than N
operators, it should also allow users to define any number of new
operators".

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

This starts to sound like the plot line for a Mel Gibson film :-)

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

We are interested in language improvements that serve everybody, not
improvements for your specific application.

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

For the reasons we have already given.  
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------