Documenting the gists

[Ron Savage]

Hi

Is it a worthwhile idea for me to go thru the mail archives and note the
gists?

I was thinking of putting them on the wiki, along with a bit of context,
as a way of distilling ideas which have been implemented.

Obviously some were to demonstrate bugs, and some have been superceded.
To deal with that I'd just get the gist authors to scan the list and
offer feedback via this list.

I could include other gists you know about not mentioned in the archives...

--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622

[Jeffrey Kegler]

Actually, what I think might be easier, more fun & more useful is a
weekly (?) summary of Marpa doings, told from a reportorial point of
view. Kind of a cross between what Gabor does for Perl, and the
summaries for the Perl 5 porters & Perl 6.

Sorting out what's still OK in the gists and what's not would take a lot
of effort, and at this point it's really a moving target.

-- jeffrey

[Ron Savage]

Hi Jeffrey

On 14/05/13 12:45, Jeffrey Kegler wrote:
> Actually, what I think might be easier, more fun & more useful is a
> weekly (?) summary of Marpa doings, told from a reportorial point of
> view. Kind of a cross between what Gabor does for Perl, and the
> summaries for the Perl 5 porters & Perl 6.

Hmmm. I'll consider that instead.

> Sorting out what's still OK in the gists and what's not would take a lot
> of effort, and at this point it's really a moving target.

Yes, the bit-rot aspect was worrying me. Bye-bye gist history!

> -- jeffrey
>
> Ron Savage wrote:
>> Hi
>>
>> Is it a worthwhile idea for me to go thru the mail archives and note
>> the gists?
>>
>> I was thinking of putting them on the wiki, along with a bit of
>> context, as a way of distilling ideas which have been implemented.
>>
>> Obviously some were to demonstrate bugs, and some have been
>> superceded. To deal with that I'd just get the gist authors to scan
>> the list and offer feedback via this list.
>>
>> I could include other gists you know about not mentioned in the
>> archives...
>>
>

[Peter Stuifzand]

The Marpa Guide also appreciates contributions about various parts of Marpa. http://marpa-guide.github.io/

About a week ago I added information about parsing expressions (chapter 2).

My 'plan' for the chapters is as follows:

1. basic rules

2. expression: "1 + 2" and more.

3. formatting language: simple HTML perhaps...?

4. template language: simple tags that insert values from a hash (like Text::Template) perhaps

5. combine outer language from chapter 3 with template language from chapter 4

6. combine expression language from chapter 2 with template language

I want to use Scanless to do this, but not everything is currently possible. The external scanner is a step in the right direction, but I think I need to be able to pass in whole subtrees as G1 symbols to make chapter 5 and 6 possible.

The structure could also be different, in that we could use a programming language instead of the formatting language in chapter 3. Combining that with a template language (in chapter 5) is also nice for code generation.

Any ideas about the later chapters are also much appreciated.

--
Peter Stuifzand | peterstuifzand.nl | @pstuifzand

--
You received this message because you are subscribed to the Google Groups "marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email to marpa-parser+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jeffrey Kegler]

This is very nice looking. -- jeffrey

Peter Stuifzand wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to marpa-parser...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "marpa parser" group.

To unsubscribe from this group and stop receiving emails from it, send an email to marpa-parser...@googlegroups.com.

[Jeffrey Kegler]

I think I need to be able to pass in whole subtrees as G1 symbols to make chapter 5 and 6 possible.

Here is a way to do it with the current feature set:  Let the value returned by any of the lexeme_read() methods of the subparse contain the value of the entire subparse.  The subparse value could be in a blessed object in order to mark it more clearly.  In G1 the node above the subparse which needs to take its value from the subparse could search its descendant's for the blessed subparse value, and return the subparse value as its node value, throwing away everything else it finds.

-- jeffrey

Peter Stuifzand wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to marpa-parser...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "marpa parser" group.

To unsubscribe from this group and stop receiving emails from it, send an email to marpa-parser...@googlegroups.com.

[Peter Stuifzand]

I just rewrote the demo-te-parser that I created some time ago. I have changed the code to use the lexeme_read as you describe (I think). It works, but it's currently not clean or nice.

https://github.com/pstuifzand/demo-te-parser/

--
Peter Stuifzand | peterstuifzand.nl | @pstuifzand

[Peter Stuifzand]

Jeffrey,

is it necessary that I pass in the start, length and value of the lexeme with lexeme_read. Could there be another method where I can pass in a name and a value, more like read in Marpa::R2::Recognizer?

Maybe they are both the same thing, but for me it seems that passing in a value is different from passing in a lexeme. The one is strings, the other is values.

--
Peter Stuifzand | peterstuifzand.nl | @pstuifzand

[Jeffrey Kegler]

As the documentation acknowledges, the relationship of a G1 lexeme to the location in the G0 input stream may have to be completely artificial, but Marpa requires such a relationship to exist.  Various points in the logic depend on that relationship.  For example, Jean-Damien has asked for a way to get the G0 position for the G1 locations in the progress() output.  The G1-location-to-G0-stream mapping must come originally from the lexemes.

I could see someday cutting the thin thread between G0 stream location and G1 lexeme and therefore, G1 Earley set.  But until I am more comfortable I see and can deal with all the implications, Marpa requires every lexeme to have a position in the input stream, even if the lexeme's value in no way corresponds to that location.

Also, from the application point of view, error reporting for the lexeme and its value will refer to the G0 input stream.  So it's best to try to concoct some kind of relationship that makes sense in that context, however artificial the relationship may be.

When I started back in 1997, I envisoned and talked about using parsing in situations with no input stream, but as a way of structuring an ordered series of any kind.  I don't think a single person understood me at taht time.  So it's pleasantly ironic to be asked why I am hanging on to the input stream relationship.