Andrei Alexandrescu pisze:
aarti_pl wrote:
Andrei Alexandrescu pisze:
downs wrote:
aarti_pl wrote:
Andrei Alexandrescu pisze:
aarti_pl wrote:
Don pisze:
There's been some interesting discussion about operator overloading
over the past six months, but to take the next step, I think we
need
to ground it in reality. What are the use cases?
I think that D's existing opCmp() takes care of the plethora of
trivial cases where <, >= etc are overloaded. It's the cases where
the arithmetic and logical operations are overloaded that are
particularly interesting to me.
The following mathematical cases immediately spring to mind:
* complex numbers
* quaternions (interesting since * is anti-commutative, a*b = -b*a)
* vectors
* matrices
* tensors
* bigint operations (including bigint, bigfloat,...)
I think that all of those are easily defensible.
But I know of very few reasonable non-mathematical uses.
In C++, I've seen them used for iostreams, regexps, and some stuff
that is quite frankly bizarre.
So, please post any use cases which you consider convincing.
DSL support in mother language. As an example I can give SQL in D or
mockup tests description language (usually also in D - not as a
separate script language).
In my previous posts I already put few arguments why it is sometimes
much more handy to use "DSL in mother language" approach rather than
string mixins with DSL language itself.
I saw that, but few, if any, of the arguments you made apply to
operators vs. named methods. You argued on string mixins vs. using
named symbols. In fact one argument of yours works against you as
there's no completion for operators.
Andrei
I put my argument much earlier in this discussion:
eg. here:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81040
To sum up: using methods to emulate operators is just completely
unreadable and looks awful. It's very easy to make an error using
such a
technique.
Later, I just replayed to posts convincing that solution for
supporting
DSL languages in D is using string mixins. I believe I could provide a
few weighty arguments to support my opinion that it is not always best
solution for this problem. In many cases it is much better to
integrate
DSL into D as a kind of API, not separate sub-language. Then we can
get
some support from IDE, while using string mixins we probably would get
nothing...
Best Regards
Marcin Kuszczak
(aarti_pl)
Scrapple.Tools uses operator overloading to provide fake infix
keywords along the lines of [2, 3, 4] /map/ (int i) { return
format(i); }, with a simple and convenient syntax for defining them
(mixin(Operator!("map", "something something use lhs and rhs; ")); ).
Forcing the end user to write mixin(function()) for such keywords is
*NOT* the way to go, for several reasons: a) it's hard to extend,
and b) it's needlessly verbose.
The reason infix keywords are useful, is because they can be used as
a simple way to chain bijective operations together, i.e. a /foo/ b
/map/ c /select/ d. Without infix keywords, this would take the form
of select(map(foo(a, b), c), d), which is an atrocity because it has
to be read in two directions - middle-leftwards for the operations,
and middle-rightwards for the parameters.
(and yes, I know it's wrong to rely on operator evaluation order. So
sue me. )
Of course, a more convenient solution would be the ability to extend
the D syntax manually, but that's unlikely to appear in our lifetime.
I sometimes think of a subtoken-based approach, e.g. any function
name starting and ending with an underscore is by definition infix.
It's the kind of solution that turns Walter's nose so I never brought
it up to him.
Andrei
Maybe:
R op[Infix|Postfix]_Name(A a, B b ...);
That's not quite elegant. What if there is a symbol called Name in
scope? This will confuse the parser to no end. (I forgot to mention that
in the sub-token approach you'd still have to write the underscore when
issuing a call.)
Andrei
I have just noticed that you were talking more about parsing than
resolution of symbols. Sorry, I was too fast with my previous answer :-)
In case of parsing I can not help too much. It might be that something
like underscores would be necessary to make parser happy.
Please notice that I am usually trying to say things from user
perspective, so from perspective of person who doesn't know all internal
details. And from user perspective I can say that I really don't like
underscores in core language names. They make language feel hackish and
not properly rethought. So I hope they can be avoided without
ambiguities for parser.
BR
Marcin Kuszczak
(aarti_pl)
