I know that delegates are in.  C-style function pointers still work as well (in DLI, at least).  Is there any plan for delegate-style syntax of extern(C) function pointers?

The problem I'm facing is that I'm writing a parser for D.  It's pretty trivial to write a grammar rule for a function declaration:

function_declaration:
	type IDENT ( type IDENT , ... ) { statement ... }

It's clean, sensible, and easy to read.  But if I have to support old-syntax C function pointers, then things get REALLY REALLY ugly! Now, the type is spread out, partially in front of the IDENT and partially after it.  So the grammar gets really hard to read:

function_declaration:
	type IDENT ( func_decl_arg , ... ) { statement ... }

func_decl_arg:
	type IDENT
	type ( * IDENT ) ( func_decl_arg , ... )

However, if we could use something like the delegate syntax for EVERYTHING, then the complexity could be hidden inside my 'type' grammar.

"Russell Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3E2ED62E.9010304@deming-os.org...
> I know that delegates are in.  C-style function pointers still work as
> well (in DLI, at least).  Is there any plan for delegate-style syntax of
> extern(C) function pointers?

Daniel and I have talked about a unified syntax for delegates and function pointers, but so far it's just talk.


> The problem I'm facing is that I'm writing a parser for D.

Why not just use the free one I supply? That way you're assured it will work just like the D compiler.

Walter wrote:

> "Russell Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3E2ED62E.9010304@deming-os.org...
> > I know that delegates are in.  C-style function pointers still work as
> > well (in DLI, at least).  Is there any plan for delegate-style syntax of
> > extern(C) function pointers?
>
> Daniel and I have talked about a unified syntax for delegates and function pointers, but so far it's just talk.
>
> > The problem I'm facing is that I'm writing a parser for D.
>
> Why not just use the free one I supply? That way you're assured it will work just like the D compiler.

The parser project started a long time ago.  As it turned out, I've written from the ground up a whole new automatic parser generator - like Bison, but substantially more powerful.  Developing a D parser has been a way to test the new utility.

I have kind of fallen in love with the output of this new type of parser, so if I ever actually do any D development, I think my preference would be to use my parser rather than anybody else's.

Anyhow, whether I ever use my parser or not, I think the issue still stands for *anybody* who will be writing a parser for D.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Russell Lewis wrote:
> I know that delegates are in.  C-style function pointers still work as well (in DLI, at least).  Is there any plan for delegate-style syntax of extern(C) function pointers?

I agree, the current function pointer syntax is weird; nontrivial usages of it are nearly incomprehensible.  Howabout:

    type function ( declaration , ... ) IDENT;

I don't like using "function", but it's the only name I can think of.

Maybe we should get rid of function pointer types altogether.  They're in the same fix as wchar; a language interface type that is badly supported and atrophying.  You'll still be able to get the address of a function, but it'll be as a void pointer.

The delegate of a function would be a minifunction that wraps the call properly:

    popl %eax // Put the return EIP in EAX
    movl %eax, (%esp) // Cover the null "this" pointer
    call function // Execute the real function
    jmp (%esp) // Jump to the caller

Because the caller cleans up the stack in extern (D), we can't just substitute a "jmp function" in there and skip the last instruction; if we could, this could just be a couple bytes right before the real function and not have a jmp at all.

Ironically, it would make calling class delegates faster than function delegates, but it wouldn't affect normal execution.

Burton Radons wrote:
> The delegate of a function would be a minifunction that wraps the call properly:
> 
>     popl %eax // Put the return EIP in EAX
>     movl %eax, (%esp) // Cover the null "this" pointer
>     call function // Execute the real function
>     jmp (%esp) // Jump to the caller

Wait, that's not right; the real function will still have four bytes too many on the stack, thanks to the call.  Uh... I can't see how it can be done cheaply.  We need the stack space, and we need to correct the stack before returning.  This requires eight bytes, and we only have four to play in.

If we put the this pointer at the end of the arguments this wouldn't be a problem.  But that makes COM interfacing impossible.

The only solution is to move the arguments down four bytes, stick the real return value after the arguments, and then correct later.  This won't allow delegates for variadic functions, and of course it'll spike the speed hit considerably.  Something like:

    movl (%esp), %eax // Put the return EIP in EAX
    movl %esp, %esi // Source part of the data move
    addl $4, %esi // Move from one cell up
    movl %esp, %edi // Destination part of the data move
    movl $argumentSize, %ecx // Number of bytes to move
    rep movsb
    movl %eax, argumentSize(%esp) // Stuff the return EIP
    call function // Execute the real function
    jmp argumentSize(%esp) // Jump to the caller

Better than compiling two versions of every function.

Hi, Russ.

How is your parser generator more powerful?  If it's significantly better than Bison, are you putting it into the open source comunity? I'm just interested in case it's something I should be using.  I currently do tons of Bison.

Thanks,
Bill Cox

Russ Lewis wrote:
> Walter wrote:
> 
> 
>>"Russell Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
>>news:3E2ED62E.9010304@deming-os.org...
>>
>>>I know that delegates are in.  C-style function pointers still work as
>>>well (in DLI, at least).  Is there any plan for delegate-style syntax of
>>>extern(C) function pointers?
>>
>>Daniel and I have talked about a unified syntax for delegates and function
>>pointers, but so far it's just talk.
>>
>>
>>>The problem I'm facing is that I'm writing a parser for D.
>>
>>Why not just use the free one I supply? That way you're assured it will work
>>just like the D compiler.
> 
> 
> The parser project started a long time ago.  As it turned out, I've written from
> the ground up a whole new automatic parser generator - like Bison, but
> substantially more powerful.  Developing a D parser has been a way to test the
> new utility.
> 
> I have kind of fallen in love with the output of this new type of parser, so if
> I ever actually do any D development, I think my preference would be to use my
> parser rather than anybody else's.
> 
> Anyhow, whether I ever use my parser or not, I think the issue still stands for
> *anybody* who will be writing a parser for D.
> 
> --
> The Villagers are Online! http://villagersonline.com
> 
> .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
> .[ (a version.of(English).(precise.more)) is(possible) ]
> ?[ you want.to(help(develop(it))) ]
> 
> 

Hello.

My opinion corresponds to:
http://www.acm.org/crossroads/xrds7-5/bison.html

So i hope yours *is* better than Bison. What algorithm(s) is it based on?

I am going to write a easy-to-use parsing library for D, which would provide run-time extention. So it would not be a parser generator, rather something like Dino's runtime Earley parser. In fact, it might become an Earley parser. I might simply adapt it from Dino source, sice it's GPL and written in good C.

The disadvantage is a lower speed - that's what compiler compilers adress. The distinct advantage of a run-time Earley parser would be, that no deep algorithm understanding is requiered, run-time extention is possible, as well as natural-language parsing.

The run-time performance of a Dino's parser is about 30_000 C code lines per second on a 500Mhz P6, which i consider usually enough. And it requieres very little time to read in the grammar.  It seems to me that parsing speed is not that important, since GCC uses a very fast parser, and is yet slow as hell. In fact the absolutely slowest compiler I've ever experienced. General design is of major importance.

-i.

Russ Lewis wrote:
> The parser project started a long time ago.  As it turned out, I've written from
> the ground up a whole new automatic parser generator - like Bison, but
> substantially more powerful.  Developing a D parser has been a way to test the
> new utility.
> 
> I have kind of fallen in love with the output of this new type of parser, so if
> I ever actually do any D development, I think my preference would be to use my
> parser rather than anybody else's.
> 
> Anyhow, whether I ever use my parser or not, I think the issue still stands for
> *anybody* who will be writing a parser for D.

Bill Cox wrote:

> Hi, Russ.
>
> How is your parser generator more powerful?  If it's significantly better than Bison, are you putting it into the open source comunity? I'm just interested in case it's something I should be using.  I currently do tons of Bison.

Unfortunately, the company I work for is really strict about intellectual property issues.  I hope to convince them to release it to the open source community, but for the moment I can't talk too much.  In a nutshell (without revealing company secrets), it is

    1) a GLR parser (though Bison just recently added this feature)
    2) uses a syntax much like Bison, but FAR more expressive.  Complex expressions
that would have taken multiple rules in Bison can be expressed in a single line in my
parser
    3) parses the entire tree, returning a root object, rather than making you
hand-code each and every rule
    4) can handle (and return to you) multiple parsings, in case the language is
ambiguous
    5) outputted parser is in D, and thus the parser output is a tree of D objects

I call it "cebu" - the C Enabled Bison Upgrade.  It currently can generate parsers that parse D, and I believe that there is no reason it cannot parse C as well.  As anybody who has used Bison knows, Bison cannot parse C without some massive hacks.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Burton Radons wrote:

> Maybe we should get rid of function pointer types altogether.  They're in the same fix as wchar; a language interface type that is badly supported and atrophying.  You'll still be able to get the address of a function, but it'll be as a void pointer.

You could do that, except that we would need some syntax for interfacing with C code that requires function pointers.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Russ Lewis wrote:
>     1) a GLR parser (though Bison just recently added this feature)

Wonderful. This solves a myriad of problems.

>     2) uses a syntax much like Bison, but FAR more expressive.  Complex expressions
> that would have taken multiple rules in Bison can be expressed in a single line in my
> parser

Good.

>     3) parses the entire tree, returning a root object, rather than making you
> hand-code each and every rule

Like CocoM Early parser. (used in Dino)

>     4) can handle (and return to you) multiple parsings, in case the language is
> ambiguous

CocoM Early does this as well.

>     5) outputted parser is in D, and thus the parser output is a tree of D objects

Another similarity.
Just that it's gonna be much faster than CocoM.

> I call it "cebu" - the C Enabled Bison Upgrade.  It currently can generate parsers
> that parse D, and I believe that there is no reason it cannot parse C as well.  As
> anybody who has used Bison knows, Bison cannot parse C without some massive hacks.

Kewl :>

Another difference of CocoM left, is that it can read a grammer at run time. It's a parser, not a parser generator. Another domain of use, at runtime, which also requieres that parser's internal structures must be built very quickly.

-i.