Hi,
A brief note to say that I have merged the PEG parser written by Michael
Lucy for GSOC 2010 to master.
I just noticed that I did the rebase incorrectly: the commit
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=eee0877c3e6ade8f2fa243cfa696918451c67aff
should have carried
st suggesting on what parts of PEG
> internals to look at would be really useful.
After thinking about it more, you have two choices.
The easiest thing would be to parse each line (or extended line, if it
ends with "\") with a PEG parser, and use your own logic for the
blocks. Your p
Hi, thanks for a quick response!
I've actually found no PEG library that has a string syntax for the
equivalent of ignore. I'm guessing most people are satisfied with just
specifying another nonterminal and matching that one. Probably because it
is seen as less ugly than extending on the formal de
Hello,
Thanks for emailing! I suppose I am the one to talk to, since I was
the last one to work on it.
I didn't make the PEG parsing syntax, but I would guess the reason
there isn't a string syntax for ignore is that there's no conventional
way to write it, but there is for the other PEG elements
Actually, I think I found a way to make it work. I had missed a macro
that needed to be copied from one module to another. I made each
module import the other, and that seemed to work all right.
As soon as I have time, I hope to turn this into a patch series that
splits the PEG module up into nice
On Wed 23 Feb 2011 16:10, Noah Lavine writes:
> I need to ask for help in order to work on this more. I thought I
> would first move the code-generating functions to their own module. It
> seems like this should be a simple and obviously-correct
> transformation, because I didn't change any code
Hello,
I tried looking at it a bit. First of all, your cleanups are awesome. :)
Unfortunately, I need to ask for help in order to work on this more. I
thought I would first move the code-generating functions to their own
module. It seems like this should be a simple and obviously-correct
transfor
On Wed 02 Feb 2011 01:26, Noah Lavine writes:
> Here it is! All of the unhygienic syntax is gone, is a series of only
> 20 commits. :-) The peg.test tests should all pass after each one of
> these commits.
Thanks! You've probably seen that I've applied this to wip-mlucy, which
we should probabl
Hi,
> However, I have a suspicion something odd is going on and this does
> not contain all of the work it should from guile's repo. I ended up
> having to use git cherry-pick instead of git rebase because I had made
> a mistake when I first made my local peg branch. I checked out
> origin/wip-mlu
On Sat 29 Jan 2011 20:37, Noah Lavine writes:
> I'm about halfway through porting peg.scm to use hygienic macros
Super! I'll work on other bugs then :)
Andy
--
http://wingolog.org/
Hello all,
Sorry for the late notice, but I'm about halfway through porting
peg.scm to use hygienic macros, so if anyone else was thinking of
doing it, you might want to save your effort for something else. Or
email me and I'll send you what I have.
I hope no one else has already started.
Noah
On Sat 29 Jan 2011 05:15, Michael Lucy writes:
> Also, macros are notoriously difficult to debug, especially when
> they're generating several hundred lines of code that compiles fine
> but mysteriously produces the wrong result after a seemingly trivial
> change. So porting them from list gener
On Sat 29 Jan 2011 04:07, Noah Lavine writes:
> Yes, the binding stuff actually seemed very weird to me too, mostly
> because it's very non-idiomatic. More specifically, the peg module
> does most of its code generation in regular functions rather than
> macros. safe-bind implements hygiene for t
On Fri, Jan 28, 2011 at 9:07 PM, Noah Lavine wrote:
> Hello,
>
>> Indeed! I'm looking forward to having it in Guile.
>
> Great! I don't intend to be pressuring you to merge it, by the way. I
> hope my message didn't come across that way.
>
>> The reason I didn't merge it yet was twofold: (1) the
Hello,
> Indeed! I'm looking forward to having it in Guile.
Great! I don't intend to be pressuring you to merge it, by the way. I
hope my message didn't come across that way.
> The reason I didn't merge it yet was twofold: (1) the commit logs were
> not in the standard style, and (2) I wasn't c
Heya,
On Thu 27 Jan 2011 06:17, Noah Lavine writes:
> The peg matcher is really awesome. I am glad to be able to use it soon.
Indeed! I'm looking forward to having it in Guile.
The reason I didn't merge it yet was twofold: (1) the commit logs were
not in the standard style, and (2) I wasn't c
Putting it in single quotes should work. E.g. " '[' ". Similarly,
you can add a literal single quote by making it part of a character
class. E.g. " ['] ".
You're right, I should definitely add something about that to the documentation.
Any other weak parts you've noticed while perusing?
On Th
Hello again,
I've run into another issue with the parser that should be addressed
in the documentation (or the code?).
How do you match a character that is used in the PEG grammar, like
"["? Can you only define such matchers via s-expressions?
Noah
On Thu, Jan 27, 2011 at 12:17 AM, Noah Lavine
Hi,
> It flattens until you have a list where each element either:
> 1. Is an atom.
> or 2. Is a list whose first element is in the list of keywords.
>
> So the car of the argument will change if it's a list that doesn't
> start with the right keyword. E.g.:
> (keyword-flatten '(a) '((c (a b)) (a
On Wed, Jan 26, 2011 at 8:38 PM, Noah Lavine wrote:
> Hello,
>
>> I'm the guy that originally wrote this for GSOC, so I figured I'd jump
>> in. I'd be happy to help with getting the PEG module merge-ready.
>
> Great!
>
>> keyword-flatten is described in api-peg.texi. It's basically a
>> special
Hello,
> I'm the guy that originally wrote this for GSOC, so I figured I'd jump
> in. I'd be happy to help with getting the PEG module merge-ready.
Great!
> keyword-flatten is described in api-peg.texi. It's basically a
> special case of context-flatten which collapses S-expressions
> accordin
Hi,
I'm the guy that originally wrote this for GSOC, so I figured I'd jump
in. I'd be happy to help with getting the PEG module merge-ready.
On Wed, Jan 26, 2011 at 7:40 PM, Noah Lavine wrote:
> Hello again,
>
> I've attached my coverage results. The html file expects the css file
> to be in th
Hi,
Noah Lavine writes:
>> It should have produced $top_builddir/guile.info, which can be used as
>> input to LCOV to generate an HTML code coverage report
>> (http://ltp.sourceforge.net/coverage/lcov.php).
>
> Oh, that worked. The current tests check 92.6% of the lines in
> peg.scm, and 90.7% o
Hello all,
> It should have produced $top_builddir/guile.info, which can be used as
> input to LCOV to generate an HTML code coverage report
> (http://ltp.sourceforge.net/coverage/lcov.php).
Oh, that worked. The current tests check 92.6% of the lines in
peg.scm, and 90.7% of the functions. I look
Hello!
Noah Lavine writes:
>> “./check-guile --coverage peg.test” can be used to measure code
>> coverage, normally.
>
> I tried running that, but what all I got was this output:
>
> Running peg.test
>
> Totals for this test run:
> passes: 21
> failures: 0
> unexpec
Hello,
> “./check-guile --coverage peg.test” can be used to measure code
> coverage, normally.
I tried running that, but what all I got was this output:
Running peg.test
Totals for this test run:
passes: 21
failures: 0
unexpected passes: 0
expected failures:
Hi!
Thanks for looking into this! Perhaps Andy has some insight to share,
too?
Noah Lavine writes:
> First of all, it passes its test suite. This is pretty good, because
> its test suite includes a grammar for itself, a grammar for basic
> mathematical equations, and a grammar for parsing /etc
Hello all,
I was just looking at the PEG parser code, which is currently in the
"mlucy" branch of the Guile repo. I was looking at it to see if it was
ready to be merged.
First of all, it passes its test suite. This is pretty good, because
its test suite includes a grammar for itself,
Hi,
On Sun 29 Aug 2010 00:45, Phil writes:
> So is there a sort of ETA on when [PEG and other SoC projecsts] will
> be part of Guile?
Mmm, not really. I hope it will be soon, but I want to go through the
code patch-by-patch, and that will take at least 3 or 4 hours, if
everything goes well -- i
#:use-module (a))
>
> (b '(1 2 3))
> => 1
>
> You see that the expansion of `(b '(1 2 3))' in the module `(d)'
> produced a reference to `c' -- but `c' is private in the `(a)'
> module. Barring the use of datum->syntax, syntax-case macros *scope free
> identifiers within the lexical conext and module in which they
> appear*. That's what "hygiene" is.
>
> Anyway, I hope to have time to poke this next week. I'm very much
> looking forward to having a good PEG parser!
>
> Cheers,
>
> Andy
> --
> http://wingolog.org/
>
>
You see that the expansion of `(b '(1 2 3))' in the module `(d)'
produced a reference to `c' -- but `c' is private in the `(a)'
module. Barring the use of datum->syntax, syntax-case macros *scope free
identifiers within the lexical conext and module in whic
On Fri, Aug 6, 2010 at 1:40 AM, Michael Lucy wrote:
> On Wed, Jul 28, 2010 at 12:13 AM, Michael Lucy wrote:
>> I've officially eliminated the last define-macro expression.
>>
>> However, I get the feeling that things may not be exactly as desired.
>> The original program made extensive use of fun
On Wed, Jul 28, 2010 at 12:13 AM, Michael Lucy wrote:
> I've officially eliminated the last define-macro expression.
>
> However, I get the feeling that things may not be exactly as desired.
> The original program made extensive use of functions in building the
> macros, and I originally tried to
On Wed, Jul 28, 2010 at 12:41 AM, No Itisnt wrote:
> On Wed, Jul 28, 2010 at 12:13 AM, Michael Lucy wrote:
>
>> Another question about module namespaces: I have some syntax that I'd
>> like to be available to code generated by macros in my module, but
>> which I'd rather not export to the user (
On Wed, Jul 28, 2010 at 12:13 AM, Michael Lucy wrote:
> Another question about module namespaces: I have some syntax that I'd
> like to be available to code generated by macros in my module, but
> which I'd rather not export to the user (to avoid clobbering their
> functions). Is there a standa
I've officially eliminated the last define-macro expression.
However, I get the feeling that things may not be exactly as desired.
The original program made extensive use of functions in building the
macros, and I originally tried to replace these with macros. This
turned out to be a little diffi
I'm still working on this. I haven't dropped off the face of the
earth; it's just taking a bit. The way I wrote the original
define-macro macros, they called some functions (passing in symbol
names) to generate blocks of code. This technique essentially depends
on variable capture, so I can't re
Hi,
I'm another of the GSOC students--I figured I'd introduce myself since
I may be asking questions on this list. I'm going to be writing a PEG
parser/matcher for Guile. My paperwork is still working its way
through the system so I can't point to any repositories where my c
38 matches
Mail list logo
