Ruby grammar interest?

[Torsten Rüger]

Hi,

i was wondering if anyone is interested in working on a ruby parser. I started all right, but . . .

First the good news, some basic stuff works (and has test cases)

- Constants: integers,float,string,symbol

- Structures: Array, Hash , Class , Module

- Function definition (with braces)

- Method calling (with braces)

- operators: all binary with correct precedences 

- while statement

- return statement

- if statement (with else)

But:

- non-braces is on the list and makes me squirm

- blocks are off course a must, though they seem simpler

- simple ifs, case, ....

- the biggie: my parser is using parslet, not treetop. 

I chose Parslet because it does not generate code, but am coming to a point where i would actually like that. So that can change and for me is not the main point.

The main question is really if there is interest. I saw some posts where people said they would be, but that was long ago. So ?

Torsten

Btw, the parser is here https://github.com/salama/salama-reader

and i am using the output to generate binary (machine) code, so the direction is a vm in ruby.

[Stojan Dimitrovski]

I might be but honestly I don't see the point. This is a VERY complex exercise.

--
Stojan Dimitrovski

http://hf.github.io

[Torsten Ruger]

Hi Stojan,

As an "exercise" i very much agree it would be way too much work.
 
But there are three very distinct points to having a peg ruby parser:
- anyone can understand it. So it is very educational in parser writing and ruby itself
- i am writing a ruby virtual machine in ruby and that needs a parser. (i prefer an extensible/understandable one)
- it then allows for extending ruby's grammar (when my vm works)  . Because of the first point. This puts a whole new aspect on dsl's.

there is a whole lot of stuff in the area of code analysis one could do, but that is not my goal.

Torsten

Stojan Dimitrovski

1 Oct 2014 17:32

--
You received this message because you are subscribed to the Google Groups "Treetop Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to treetop-dev...@googlegroups.com.
To post to this group, send email to treet...@googlegroups.com.
Visit this group at http://groups.google.com/group/treetop-dev.
For more options, visit https://groups.google.com/d/optout.

[Clifford Heath]

Torsten,

On 2 Oct 2014, at 4:57 am, Torsten Ruger <tor...@villataika.fi> wrote:
> - it then allows for extending ruby's grammar (when my vm works) . Because of the first point. This puts a whole new aspect on dsl's.

This was a goal that Nathan had when he first wrote Treetop.
At the time he thought that the existing Ruby implementations
might use his parser; he didn’t intend to create a new one.
I think that a side-by-side implementation added to an existing
Ruby VM wold work best - I’d probably choose Rubinius.
I undertook an examination of doing that for the V8 Javascript
interpreter...

It’s a worthy goal, and the idea of an extensible language syntax
has long tantalised me (vis my “polyglot” gem as a small step).

However, such an interpreter would inevitably be very slow to
load Ruby files, hence the need for a side-by-side implementation.

You shouldn’t create your own syntax test suite, but instead use
the one shared by JRuby, MRI and Rubinius.

Clifford Heath.

[Torsten Ruger]

Hi Clifford,

this is all good to hear. You took over from Nathan right ? Good on you, and thanks to both of you.
So if you know him, he may be interested to hear that his old dream may still come true and it's not too late to join:-)

I also like the idea of extensible languages, and the fact that people experiment with them. It would be very nice to have a solid base for that, so not everyone would always have to write  a new vm just to get
a small twist onto a language. And anyway, we should all be nicer to our neighbours and accept other oo languages. Work together .... but this is phase two of my already 10year plan.

btw: i am not writing an interpreter, but a vm. I produce binary machine code from ruby. And the idea is that the vm will be such a binary that implements ruby syntax and libraries, on top of a general core (that may also implement python or java/script). The vm would jit the new code, in much the same way that i now compile it. (so if it's not faster than mri i have done something very wrong :-) *
There is no c involved (no compiler/llvm, no libraries, not even libc), so i have obviously taken the long road. But i am old enough not to be in a hurry, and found that in life direction is much more important than speed.

As to the tests, i sort of agree, but needed to see that my stuff works, before actually checking that it also is correct ruby. One can see them as unit tests.
Eventually i will go the (is it) mspec way, but for now (before i achieve bootstrap) i am happy with a sensible subset.

Torsten

* 'cause i'm happy to talk about the vm at any length, but it is off topic so i won't here. https://github.com/salama

Clifford Heath

1 Oct 2014 23:48

Torsten,

This was a goal that Nathan had when he first wrote Treetop.
At the time he thought that the existing Ruby implementations
might use his parser; he didn't intend to create a new one.
I think that a side-by-side implementation added to an existing
Ruby VM wold work best - I'd probably choose Rubinius.
I undertook an examination of doing that for the V8 Javascript
interpreter...

It's a worthy goal, and the idea of an extensible language syntax
has long tantalised me (vis my "polyglot" gem as a small step).

However, such an interpreter would inevitably be very slow to
load Ruby files, hence the need for a side-by-side implementation.

You shouldn't create your own syntax test suite, but instead use
the one shared by JRuby, MRI and Rubinius.

Clifford Heath.

Torsten Ruger

1 Oct 2014 21:57

Hi Stojan,

As an "exercise" i very much agree it would be way too much work.
 
But there are three very distinct points to having a peg ruby parser:
- anyone can understand it. So it is very educational in parser writing and ruby itself
- i am writing a ruby virtual machine in ruby and that needs a parser. (i prefer an extensible/understandable one)

- it then allows for extending ruby's grammar (when my vm works)  . Because of the first point. This puts a whole new aspect on dsl's.

there is a whole lot of stuff in the area of code analysis one could do, but that is not my goal.

Torsten

--
You received this message because you are subscribed to the Google Groups "Treetop Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to treetop-dev...@googlegroups.com.
To post to this group, send email to treet...@googlegroups.com.
Visit this group at http://groups.google.com/group/treetop-dev.
For more options, visit https://groups.google.com/d/optout.

Stojan Dimitrovski

1 Oct 2014 17:32

I might be but honestly I don't see the point. This is a VERY complex exercise.

--
Stojan Dimitrovski

http://hf.github.io

--
You received this message because you are subscribed to the Google Groups "Treetop Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to treetop-dev...@googlegroups.com.
To post to this group, send email to treet...@googlegroups.com.
Visit this group at http://groups.google.com/group/treetop-dev.
For more options, visit https://groups.google.com/d/optout.

Torsten Rüger

30 Sep 2014 14:08