Re: Lisp for the C21
- From: Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@xxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 18 May 2007 10:53:58 +0200
Markus E Leypold schrieb:
Well, my point, exactly. I can see slight benefits, but consider the
price to be paid (pecularities in the type system, trade offs
readability ("What is '+' here")) too high.
The type system need not suffer, provided that operators have a
uniform semantics. You just need to make the semantics general
enough.
I'm not so sure all that plays so well together (mind: I've also been
talking about automatic conversions -- be that between arithmetic
types or between class types and their sub classes).
As I said (elsewhere?): I'm not _convinced_ it is a good idea, I
_believe_ overloading is a lot of trouble and the payback not worth
the trouble, neither in language design nor in application. But
everyone's MMV. I've not got any hard proof of all that.
E.g. defining '+' as "addition in a commutative group" and then
specializing for integers, vectors etc. is OK; applying the same
operator to floats or string concatenation is not OK (float addition
is not associative, string concatenation is not commutative).
Agreed. But here the trouble already starts: Since when does '+' have
to be commutative? Well, I think U remmeber it is in mathematics by
convention, but since it is now some time ago that I last read group
theory text books I'm not sure wether that convention really exists or
not, which proves a point: You shouldn't have to remember mathematical
conventions like that to decide wether it's right to overload '+' for
a specific purpose. There is too much "cultural tradition" behind
'+'. Just calling it 'vector_add', 'group_add', 'polynomial_add' or
whatever should be good enough. And that doesn't prevent you, to
define, in a specific context:
let (+) = vector_add.
(This doesn't cover all 'nice' cases of applying operator syntax,
e.g. mixing matrix addition and vector_addition in one formula, but,
as I said, I don't deem it worth the trouble).
Unfortunately, this kind of lesson has been learned by language
designers, over and over again.
:-) There's a lot of repetition in language design. And then some
lessons are not learned, because people insist, that their language
either didn't really deserve to die ("All deciders in software
development projects are stupid. Our language would have been ideal
and saved them big money. But no, that had to go and take X. Such
idiots") or that their language is OK as it is (warts, poison and all)
because it _is_ successful which in turn "proves" it's well designed.
If one really has to introduce operator overloading, perhaps type
classes as in Haskell are the right way.
Add a way to specify laws, preferrably checkable ones, and it should
work like a charm. (Type signatures are a subset of the checkable
laws; i.e. they are a step in the right direction but not enough.)
Actually that idea is not such a bad one :-).
Regards -- Markus
.
- Follow-Ups:
- Re: Lisp for the C21
- From: Joachim Durchholz
- Re: Lisp for the C21
- From: Jon Harrop
- Re: Lisp for the C21
- References:
- Re: Lisp for the C21
- From: Pascal Costanza
- Re: Lisp for the C21
- From: Markus E Leypold
- Re: Lisp for the C21
- From: Pascal Costanza
- Re: Lisp for the C21
- From: Thant Tessman
- Re: Lisp for the C21
- From: Pascal Costanza
- Re: Lisp for the C21
- From: Thant Tessman
- Re: Lisp for the C21
- From: Pascal Costanza
- Re: Lisp for the C21
- From: Thant Tessman
- Re: Lisp for the C21
- From: Pascal Costanza
- Re: Lisp for the C21
- From: Thant Tessman
- Re: Lisp for the C21
- From: Alexander Schmolck
- Re: Lisp for the C21
- From: Thant Tessman
- Re: Lisp for the C21
- From: Alexander Schmolck
- Re: Lisp for the C21
- From: Thant Tessman
- Re: Lisp for the C21
- From: Markus E Leypold
- Re: Lisp for the C21
- From: Jon Harrop
- Re: Lisp for the C21
- From: Markus E Leypold
- Re: Lisp for the C21
- From: Jon Harrop
- Re: Lisp for the C21
- From: Markus E Leypold
- Re: Lisp for the C21
- From: Joachim Durchholz
- Re: Lisp for the C21
- Prev by Date: Re: Non-general inference in ghc
- Next by Date: Re: Lisp for the C21
- Previous by thread: Re: Lisp for the C21
- Next by thread: Re: Lisp for the C21
- Index(es):
Relevant Pages
|