http://d.puremagic.com/issues/show_bug.cgi?id=1255

           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
possible.
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,
Daniel


-- 

<d-bugmail@puremagic.com> wrote in message news:bug-1255-3@http.d.puremagic.com/issues/...
> http://d.puremagic.com/issues/show_bug.cgi?id=1255
> Hi, I try to figure out, whether a port of boost::spirit to D would be
> possible.

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.announce&article_id=6664. So you can write grammars that look like grammars, which is pretty nice.

http://d.puremagic.com/issues/show_bug.cgi?id=1255





------- 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:
    mixin(Rule!(
        "term ::= factor ( ( '*' factor ) | ( '/' factor ) )*"
        ));
And maybe eventually the 'mixin' part won't be necessary either, but for now it
is.

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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1255





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


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1255


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