[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Dynamic code generation and linking

Joshua Haberman

2/22/2006 9:58:00 PM

Benjohn Barnes wrote:

>Another example would be creating a parser from a BNF like notation.
>It should be possible (making use of this module) to specify a
>grammar with a Rubyish domain specific language, and then compile
>that to native code and immediately make use of it from within the
>same Ruby program.
>
>
I had exactly this idea recently! I was particularly interested in
lexing, because that's the bottleneck in some parsers I've written
recently. And conveniently, re2c (google it) is an existing re->c
compiler that generates optimized C from a regular expression
description. Sounds perfect for the task.

>A further possibility is that it could pull all that pesky linking
>with external libraries (well I don't get on with it anyway, but it's
>not really my bag) in to the domain of Ruby, and make it a fun thing
>to explore from within IRB, for example. An offshoot from that would
>be an explorative SWIG like system: a simple c parser that you can
>point at a library's header file, allowing you to start hacking about
>with the c library as if you were back programming BASIC on your BBC
>[2] :)
>
>
Wow, I had this idea too -- except I had the idea of getting function
signatures from a .so's debugging information, so you wouldn't need the
C header file.

I'm really interested in any work you do in this area. I'd like to be
working on this, but I am heavily invested in other problems at the moment.

Regards,
Josh


1 Answer

Matthias Georgi

2/23/2006 4:06:00 PM

0

> Benjohn Barnes wrote:
>
> >Another example would be creating a parser from a BNF like notation.
> >It should be possible (making use of this module) to specify a
> >grammar with a Rubyish domain specific language, and then compile
> >that to native code and immediately make use of it from within the
> >same Ruby program

I worked on a compiler backend, which actually does this. It takes a
symbolic expression represented by a nested array and compiles it to
assembly code, which is processed by gas. This can be required
immediately as ruby extension. The compiler is stack based as this
simplifies the algorithm a lot. At the time local variables,
parameters, literal floats and many other things are missing, but it
works.
.
> I had exactly this idea recently! I was particularly interested in
> lexing, because that's the bottleneck in some parsers I've written
> recently. And conveniently, re2c (google it) is an existing re->c
> compiler that generates optimized C from a regular expression
> description. Sounds perfect for the task.
>
> >A further possibility is that it could pull all that pesky linking
> >with external libraries (well I don't get on with it anyway, but it's
> >not really my bag) in to the domain of Ruby, and make it a fun thing
> >to explore from within IRB, for example. An offshoot from that would
> >be an explorative SWIG like system: a simple c parser that you can
> >point at a library's header file, allowing you to start hacking about
> >with the c library as if you were back programming BASIC on your BBC
> >[2] :)

Implementing a c parser is cumbersome.

> Wow, I had this idea too -- except I had the idea of getting function
> signatures from a .so's debugging information, so you wouldn't need the
> C header file.

This approach seems much easier. Maybe something similar to Ruby/DL.

>
> I'm really interested in any work you do in this area. I'd like to be
> working on this, but I am heavily invested in other problems at the moment.
>
> Regards,
> Josh

Cheers,
Matthias