On 7 Apr 2008, at 21:15, Dan Weston wrote:

To answer your second question (which everyone else ignored):

Yes. A different keyword might have been more descriptive, such as "automatically_deriving_instances_for".

They are called instantiations, which Haskell can supply automatically in some cases. And there is already a keyword "instance" for that - in general, it is good to keep down the number of keywords. So data Bool = False | True instance (Eq, Ord, Enum, Read, Show, Bounded) might have been better. But here, one would have to think about how the compiler should be able to distinguish data Bool = False | True instance (Eq) from data Bool = False | True instance Eq Bool where x == y = ... One wants to be able to do that with as little lookahead as possible. Hans Aberg

On 7 Apr 2008, at 21:48, Brandon S. Allbery KF8NH wrote:

...

But here, one would have to think about how the compiler should be able to distinguish data Bool = False | True instance (Eq) from data Bool = False | True

instance Eq Bool where x == y = ...

Layout already does that, doesn't it? The former, being indented, is a continuation line.

At least Hugs complains if one does not indent "deriving ...", but I do not know what the standard says. If is required, then it can be changed. Hans

On 8 Apr 2008, at 00:30, Bulat Ziganshin wrote:

...

At least Hugs complains if one does not indent "deriving ...", but I do not know what the standard says. If is required, then it can be changed.

deriving is a part of data clause and indentation just allows us to continue clause from prev. line. if not indented, deriving will be parsed as separate clause (and btw such clause, "standalone deriving" was added to ghc 6.8)

So it seems that if one uses the word "instance" instead of "deriving", then the compiler can immediately tell when this word appears whether it is a part if the "data" clause, or the start of a new "instance" clause. So it can probably be changed, getting rid of "deriving" which I think is not used elsewhere. It will break a lot of code, but it is easy to change, and also easy to make a compatibility mode. Hans

On 8 Apr 2008, at 10:47, Bulat Ziganshin wrote:

...

"deriving" which I think is not used elsewhere. It will break a lot of code, but it is easy to change, and also easy to make a compatibility mode.

it's also easy to replace all the books, update all code repositories and reteach all the programmers if you ready to pay for it all :D

I guess it is only the code breaking part that is any concern of standard. It is really up to the companies to pay for courses retraining programmers for the word change. As for the books, it is a good selling opportunity. Hans

On 8 Apr 2008, at 15:26, PR Stanley wrote:

I'm sure you could introduce change gradually without too much pain.

So then you only have to get the compilers to gradually understand it :-).

I personally think "deriving" is a descriptive term, now that I understand its role better.

There are two processes here: deriving, i.e., inheriting an interface; and instantiating, i.e., producing running code. Haskell denotes derivation by "=>". And "data <a> deriving (b_1, ..., b_k)" is really a short for data <a> instance b_1 where <compiler implementation> ... instance b_k where <compiler implementation> So "instance" seems the word that should have been used. But discussions of a change seems is likely just a café thing - I must go finishing mine :-).

I suppose you could consider "specialize" or "instanciate" but both those terms are very closely associated with OO and deriving an instance of a class with a type isn't quite like instantiation or even specialisation.

So then you introduce a new keyword and screwing up all existing code.

We want a single word which is equivalent to "derives from". Deriving by itself can seem a bit ambiguous at first.

What about the already used "=>"? Hans

On 8 Apr 2008, at 16:32, Anton van Straaten wrote:

...

There are two processes here: deriving, i.e., inheriting an interface; and instantiating, i.e., producing running code. Haskell denotes derivation by "=>". And "data <a> deriving (b_1, ..., b_k)" is really a short for data <a> instance b_1 where <compiler implementation> ... instance b_k where <compiler implementation> So "instance" seems the word that should have been used.

How about making "deriving x" an expression which means:

instance x where <compiler implementation>

This innovative solution will minimize changes to the Haskell compiler, documentation, and programmer's brains.

So what is the difference from the current state? They way you have written it, one can say data A ... deriving Eq A Is that what you want?

Seriously, there's only so much connotational meaning you can pack into or extract from a keyword. Ultimately, programming language keywords follow the rule given by Humpty Dumpty:

"When _I_ use a word, it means just what I choose it to mean -- neither more nor less."

That is why computer languages are what they are. Think of C "static". Hans

On 8 Apr 2008, at 16:57, Anton van Straaten wrote:

...

So what is the difference from the current state?

None. See how efficient a solution it is? ;)

So for a change, you propose it should be the same. So you are one of those A-programmers :-).

Seriously, there's only so much connotational meaning you can pack into or extract from a keyword. Ultimately, programming language keywords follow the rule given by Humpty Dumpty:

"When _I_ use a word, it means just what I choose it to mean -- neither more nor less."

So your favorite language must be Humpty?! :-) Hans

On 8 Apr 2008, at 17:03, Christian Maeder wrote:

"deriving Eq" i.e. following "data List a = List a" creates an instance like:

instance Eq a => Eq (List a) where <compiler implementation>

The problem was discussed for Stand-alone deriving declarations:

http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html

There is a difference between data Foo a = Bar a | Baz String deriving instance Eq a => Eq (Foo a) and data Eq a => Foo a = Bar a | Baz String deriving (Eq) The second is more restrictive, as it requires Eq for the construction of Foo a, whereas the first could be construed to mean that Eq a is only required for the construction of Eq(Foo a). So the first could be used without Eq a if Eq(Foo a) is not needed. This is good when constructing libraries for general types. Hans

Richard A. O'Keefe wrote:

On 8 Apr 2008, at 7:15 am, Dan Weston wrote:

...

[1] Yes, I know that "conciseness" is the much more common and accepted word for this, but if we can say "precision", "decision", and "incision", then it seems foolish to not also use "concision". I will henceforth take on this quixotic quest to promote the use of "concision".

Please don't. There is already an English word "concision" that means something quite different. To quote the OED: "The action of cutting to pieces or cutting away; mutilation."

I thought that was called "circumcision". :)