www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1255] New: operator overloading

reply d-bugmail puremagic.com writes:

           Summary: operator overloading
           Product: D
           Version: 1.014
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: Daniel919 web.de

Hi, I try to figure out, whether a port of boost::spirit to D would be
This library is heavily using C++ operator overloading.
Now there are some problems I figured out:
C++ allows the * operator to be overloaded in case of dereferencing.
Spirit uses it as the "kleene star": *(expr) means repeat expr 0 or more times.
D has opMul(_r), which overloads: "a*b" and "null*b", but not: "*b" since the
latter means dereferencing.
In the docs it's said "!", "&&" and "||" will likely never be overloadable.
C++ allows all of them to be overloaded and spirit makes use of it.
"!(expr)" means expr is optional (so 0 or 1 match). "||" and "&&" are used for
sequential matching.

So my feature req for D:
without further arguments:
*(expr) -> opDeref()
!(expr) -> opNot()
&(expr) -> opAddr()

WITH one more argument and _r:
expr1 && expr2 -> opAndAnd
expr1 || expr2 -> opOrOr
expr1 , expr2 -> opComma

The following is not possible in C++:
value = expr1 expr2;
Because nothing is not overloadable as an operator.
What about opNothing in D ;) ?

Thanks in advance,

Jun 03 2007
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
<d-bugmail puremagic.com> wrote in message 
news:bug-1255-3 http.d.puremagic.com/issues/...
 Hi, I try to figure out, whether a port of boost::spirit to D would be

Kind of OT, but I think one of the questions is: is it really necessary to have something like Spirit in D? We have much more powerful compile-time constructs at our disposal, like CTFE, compile-time string manipulation, and string mixins, which basically allow us to generate any kind of code we'd like from some other, more reasonable looking DSL. An example can be found here: http://www.dsource.org/projects/scrapple under DParser. A link to the relevant topic is: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.annou ce&article_id=6664. So you can write grammars that look like grammars, which is pretty nice.
Jun 03 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:

------- Comment #1 from wbaxter gmail.com  2007-06-03 19:18 -------
As Jarrett pointed out in the NG follow-up, porting Spirit line-by-line is
undoutedly the wrong way to go about it.

With spirit you can have the syntax:
    boost::spirit::rule<ScannerT> factor, term;
    term = factor >> *( ( '*' >> factor) | ( '/' >> factor ) );

Which admittedly looks pretty similar to BNF.
But with the compile time text processing stuff that's been going into D you
can just use the BNF:
        "term ::= factor ( ( '*' factor ) | ( '/' factor ) )*"
And maybe eventually the 'mixin' part won't be necessary either, but for now it

Operator overloading abuse is cute, but it's just working around the lack of
ability in C++ to do more generic compile-time processing.  The biggest issue
with operator overloading for this kind of thing is that you're stuck with the
built-in precedence rules and operators (*prefix* kleen star?)

One approach might be to build a standard API-based syntax for a
parser-generator first (like C# ports of boost -
http://www.codeproject.com/csharp/spart.asp).  Then use the compile time string
facilities in D to translate BNF strings to that API.

Just a thought.
But in any event, I can tell you for sure that "I want to use unary * as a
Kleen star operator so D needs to have opDeref()" is not an argument that will
gain any traction with Walter.  He's a firm believer in operator overloads not
changing the semantics of the underlying operator.

Jun 03 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:

------- Comment #2 from Daniel919 web.de  2007-06-04 03:43 -------
It would be really nice without the need of writing "mixin" and with more
compile-time function capabilities.

Having an API and then translate the EBNF string onto it sounds like a good
This way the EBNF can be kept 100%, so there would be no reason for having ">>"
like it's necessary in spirit.

Thanks for clarifying this.

Jun 04 2007
prev sibling parent d-bugmail puremagic.com writes:

Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
             Status|NEW                         |RESOLVED
                 CC|                            |andrei metalanguage.com
         Resolution|                            |WONTFIX

Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 08 2011