Wrapping other parser engines
Jeffrey (mainly), Suppose I have a programming language that does not (yet) have libmarpa bindings, but which does have its own Earley parser. Case in point being Ruby and the Rley engine: https://github.com/famished-tiger/Rley How would you feel about my implementing the SLIF (or something SLIF-like) as an add-on wrapper to Rley? I don't want to step on anybody's toes, in terms of intellectual property, but at the same time, it feels like making a high-level lexer & grammar specifier that would be pluggable for both Rley and any future Marpa implementation would be for the Greater Good, so to speak. Thanks for your guidance, -- Paul Bennett P/PW/PWBENNETT -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Switching between grammars in one parse
Any good examples of mixing grammars? In my "main" grammar I have :discard ~ whitespace (etc), but in the XPath spec whitespace seems to be significant. I'm obviously behind the times ... I guess I could use "..." around my XPath expressions and treat them as blind strings handled by the semantics. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Switching between grammars in one parse
I'm writing a tinylang. One of the things the lang needs is a token "XPath", which parses as per the w3c XPath spec, which is highly different to the rest of the language spec. I plan to approach it by writing two grammars. It seems the words for me to grep the pod for are "pause" and "expect" if I'm reading it right. Are there any teachable examples out there that I can learn from? Thanks in advance... -- P/PW/PWBENNETT -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
To mark the occasion, a short composition
:discard ~
whitespace ~ [\p{Separator}]+
S ::= H B J
H ::= 'Very' H
| 'Happy'
B ::= 'Birthday,'
J ::= 'Illustrious Idiosyncrat'
| 'Jeffrey'
--
P/PW/PWBENNETT
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Java 8 Parser
On Oct 15, 2016 13:01, "Jeffrey Kegler"
wrote:
>
> Re #4, why not implement Perl regexes? A full syntax of Perl regexes is
gruesomely complex, and much of it is symptoms rather than features.
Somewhere deep within perldoc there's a howto on making your own \p{} named
properties, which AFAICT are acceptable to Marpa's regex engine. IIRC, I
once had some progress that way.
--
P/PW/PWBENNETT
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
ANNOUNCE: Gloria has begun
Work has finally begun in earnest on my log analyzer that I promised to work on "one day" back when I started to get into Marpa . There's not much to see yet, aside from one work-in-progress "input config" file. Input config spec coming soon -- as soon as I've nailed down what input specs need to be capable of. One of the things it will need to be capable of is using Marpa-based parsers to grok log entries (as well as using simple regexes). I may also need to use Marpa to make the query language, which in turn might need me to work on an SQL::Translator module to convert generic SQL into the SQL needed to query the database of parsed logs. I plan to store it in SQLite (by default, but let the user choose), but SQLite lacks some of the features that I've grown to know & love that are present in Oracle, and that I want to have in my SQL dialect. https://github.com/PWBENNETT/perl-Gloria/tree/develop -- Paul W Bennett https://www.avast.com/sig-email"; target="_blank">https://ipmcdn.avast.com/images/logo-avast-v1.png"; style="width: 90px; height:33px;"/> This email has been sent from a virus-free computer protected by Avast. https://www.avast.com/sig-email"; target="_blank" style="color: #4453ea;">www.avast.com -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: SLIF style guide / best practices?
On Nov 22, 2015 4:10 PM, "Ron Savage" wrote: > > I always try to write the ::= rules top-down, and then list the ~ rules alphabetically. This has turned out very well, for me at least. > Sounds sensible. In my (admittedly gargantuan) grammar linked above, do any of you have specific examples of ways you can make it better? The idea is basically to concatenate the separate files together into one big grammar, but to split that monstrosity into ... I guess ... "functionally similar" slices, to allow Processing Instructions to come along and maybe mutate the tag L0 terminals (for instance) without having to glark the whole grammar. If there's a better way to modify the grammar more or less on the fly, I'd like to know about it too... Thanks, -- P/PW/PWBENNETT -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
SLIF style guide / best practices?
Is there such a document? My specific scenario... I have a grammar broken up into chunks (corresponding more or less with similarity of meaning in the official SGML spec) at https://github.com/PWBENNETT/MarpaX-SGML/tree/master/lib/MarpaX/SGML/Grammar My specific question... Within each file, is it polite to other (human) readers to sort the productions alphanumerically, or to cluster them so that things that refer to each other are near each other, or something else? Thanks, -- Paul -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Emacs marpa-mode
On Sat, Nov 21, 2015 at 3:42 PM, Paul Bennett wrote: > https://github.com/PWBENNETT/MarpaX-SGML/blob/master/Marpa.tmLanguage And here it is in action: https://drive.google.com/file/d/0B21ee_I1WzbwNFlVdXE5T2dMQnM/view?usp=sharing Apologies for the many emails. I'm growing too accustomed to modern social media, where you can edit and comment and edit your comments, and so on. -- Paul -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Emacs marpa-mode
On Sat, Nov 21, 2015 at 3:35 PM, Paul Bennett wrote: > > Ooh, I don't support comments with that. Working on it. > Here, and in its semi-proper location instead of as a gist ... https://github.com/PWBENNETT/MarpaX-SGML/blob/master/Marpa.tmLanguage -- Paul -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Emacs marpa-mode
On Sat, Nov 21, 2015 at 3:17 PM, Paul Bennett wrote: > https://gist.github.com/PWBENNETT/0e860d907fc59554f1ce Ooh, I don't support comments with that. Working on it. -- Paul -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Emacs marpa-mode
On Sat, Nov 21, 2015 at 2:09 PM, Paul Bennett wrote: > I'm looking at implementing the exact same thing right now. https://gist.github.com/PWBENNETT/0e860d907fc59554f1ce -- Paul -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Emacs marpa-mode
On Fri, Nov 20, 2015 at 4:33 PM, Jeffrey Kegler wrote: > Kind of nice the way that the colors distinguish G1 and L0 rules. I haven't played with my TextMate / SublimeText highligher for Marpa in a long time. I agree it's a nice touch. I'm looking at implementing the exact same thing right now. Please stand by, as .tmLanguage files are not entirely for the uninitiated (and it's been a while since I was initiated). -- Paul -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: OPML: Another XML-based markup language
On Tue, Nov 11, 2014 at 5:09 PM, Ron Savage wrote: > https://en.wikipedia.org/wiki/OPML Interesting, and I suspect JD will have things to say. For me, it's just a sad reminder that my SGML implementation hasn't been worked on in far too long. I really need to get into a room with JD, a couple of computers, and a large whiteboard with plenty of colors of pen, so that I can learn his XML code sufficiently to "embrace and extend" it to full SGML. I'm stuck thinking that I'll need user-programmable L0 rewrites (for which I will probably need to invent a DSL), and at least a G2 layer (or would it need to be ... some kind of L2 layer???) for well-formedness and a G3 layer for validation. At least I've started in on envisioning the GUI for a wizard that will be able to scaffold the L0 rewrites based mostly on radio and check buttons. It's all going far too slowly, though. -- PWBENNETT -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Python port of Libmarpa?
Well, how about that? I was just going to SWIG the low-level C code, and build a method-compatible API suite on top. I'll have to check out this guy's work for sure. On Sun, Nov 9, 2014 at 9:55 PM, Jeffrey Kegler wrote: > [ Warning: family unfriendly repo name ] > > If you've been following the IRC channel, you may have noticed that koo6 > seems to have ported Libmarpa to Python and written a first example parser: > https://github.com/koo5/new_shit/blob/dev/marpa_cffi/marpa.py > > I know a Python port is something that's been talked about for some time -- > perhaps this is a start that could be built on. > > -- jeffrey > > -- > 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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Yet another ambitious project
On Jul 21, 2014 1:04 AM, "Ruslan Shvedov" wrote: > > A couple of nits on the updated grammar: > > 1 > >> Expression ::= Value > > > and, later, > >> Value: >>> >>> ... >>> >>> | Expression action => eval >>> >>> ... > > > This alternative looks redundant. Well, I'm not entirely sure at this point in pre-design. My feeling is that: a. If you encounter an Expression where a Value is expected, you need to evaluate it and substitute the result b. If you encounter a Value where an Expression is needed, that's fine, and you can keep on rolling. > 2 > > UDFExpr ::= UDF OptionalExpressionSequence > > you probably know better, but why not just > >> UDFExpr ::= UDF Expression > > just like FuncExpr? > A UDF can take arbitrarily many arguments, such as uniform i j := var u ~ random in return i + (u * (j - i)) std_logistic := var u ~ random in return log u ... and several even worse examples. Unless, as is possible, I misread the spec. Thanks again for helping me get my thoughts in order. -- P/PW/PWBENNETT -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Yet another ambitious project
>> In the paper's if X then Y else Z, X seems to be a (bound) variable (not >> sure if/how they convert it to boolean, perhaps by whether it has PDF or >> not), while it is a comparison in the grammar. > > The name "comparison" is just a notational thing for my convenience. > Oh, but yes. Yes, indeed. Variables are not allowed in the "X" slot in > my version. I'll have a think about that, and update the gist again > later. Okay. I've had more of a think, not just about the grammar but also about practical ways to implement the language. I may have strayed beyond the letter of the spec, but I suspect I've stayed within its spirit. URL as always is https://gist.github.com/PWBENNETT/8435996 Thanks, -- P/PW/PWBENNETT -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Yet another ambitious project
On Sun, Jul 20, 2014 at 10:06 AM, Ruslan Shvedov
wrote:
> Hi Paul, here are my 2cents on this, in no particular order
>
> C style #include's — aren't they supposed to be processed before parsing the
> program? The grammar has actions for include's, but I honestly can't see how
> you are going to inject the included file's contents at the recongition time
> except probably with event completed statements which will read() the
> included file contents.
An #include is "just another macro". I was thinking of doing almost
exactly as you say: spawning a second recce and using that to inject
into the main symbol table (accomplished by the "our $self = bless { }
=> __PACKAGE__ ; sub new { return $self } ; ..." trick, where $self
holds (among other things) the symbol table).
I've updated the gist https://gist.github.com/PWBENNETT/8435996 to
rename "Definition" to "Macro", and to allow an #include anywhere a
Macro is allowed, to hopefully better explain my intentions (that is,
until I actually have some "real" code to show).
> To make a long story short, if you think the language needs a preprocessor,
> write a preprocessor (or just use cpp).
Maybe. It's certainly a good idea. I don't know whether I want to have
the full capability for users to shoot themselves in the foot that cpp
might provide, but there's definitely a good case to be made for it.
> I can't see a rule for free (unbound) variables (FV (·)) and (·,·) in the
> grammar.
Syntactically I see no difference between bound and free variables
that can't be made by context.
Isn't (·,·) just the notation for what I've called a Tuple in my grammar?
> LE/le seem to include both < and <=, while the paper has only <.
The paper has, as you quote below, both < and ≤, which is incorporated
into the (revised) gist as syntactic sugar for (or sugared by?) <= (or
⩽)
> In the paper's if X then Y else Z, X seems to be a (bound) variable (not
> sure if/how they convert it to boolean, perhaps by whether it has PDF or
> not), while it is a comparison in the grammar.
The name "comparison" is just a notational thing for my convenience.
Oh, but yes. Yes, indeed. Variables are not allowed in the "X" slot in
my version. I'll have a think about that, and update the gist again
later.
Thanks for the input,
--
P/PW/PWBENNETT
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Yet another ambitious project
Hi all, I've started working here https://gist.github.com/PWBENNETT/8435996 on a practical grammar for the language described here http://ashishagarwal.org/2011/10/04/pdf-type-theory/ Trouble is, I don't (yet) understand the math in the above paper well enough to know whether I'm actually on the right track with the language spec (but I am working on it). It's a bit vague and airy in the paper itself, and I'm trying to tie it down to something actually implementable. I've also taken the liberty of allowing *NIX style shebang lines and C style #include lines, as a convenience to any future users of the language. Anyway ... any opinions on what I might be doing wrong (or right), at this early stage in the game? Thanks, -- P/PW/PWBENNETT -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: I may be teaching my colleagues Marpa
On Wed, Jun 18, 2014 at 8:01 PM, Jeffrey Kegler wrote: > Grune & Jacobs suggest that "::=" be read as "may be replaced by". I'll > often read it as "produces". All, I've taken a number of your suggestions on board (as well as some other thoughts). The URL for the presentation-in-progress remains the same ... https://docs.google.com/presentation/d/1LCU4C8jdl8gM7eMg_yoab2dJqIy7YRMtOtLoUwEpBdk/edit?usp=sharing Keep 'em coming, folks! I want to make this thing as close to truthful as it can be without being painful... -- Paul -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: I may be teaching my colleagues Marpa
On Wed, Jun 18, 2014 at 12:01 PM, Jeffrey Kegler
wrote:
> Thanks for doing this. Reading even unfinished presentations is helpful to
> me, because I come to Marpa from the viewpoint of 1970's parsing theory, and
> so what most people need explaining and what does not is very hard for me to
> figure out.
My colleagues come from a "just muddle through with split() and
regexes" viewpoint, as did I before I discovered Marpa (though I could
read BNF). I'm trying to build knowledge and (hopefully) understanding
on top of that platform, so I'm really taking it down to baby-steps
where I can. That said, I work with some really smart cookies, so I
will tend to power through "full steam ahead" and wait for questions.
> Here are my comments on the slides.
>
> Slide 2: Calling Marpa a scribe is a bit like calling Indiana Jones a
> professor. Marpa was an explorer/adventurer/teacher/translator, and founder
> of the major lineages of Tibetan Buddhism.
Yes, but there's only so much you can fit on a slide without
butchering the font size and whatnot. I'll see whether I can squeeze
in a footnote quoting that description verbatim though.
> Also on slide 2: The LHS of a production is not really its name, it's a
> symbol. That is, "A ::= B" says that symbol A derives (or produces or can
> be rewritten to) symbol B.
Point taken.
> "A" is sometimes used to "name" the rule, to be
> sure, but it's dangerous to think of it as the rule's name. One reason it
> is dangerous is that several rules can have the same LHS:
>
> A ::= B
> A ::= 'hello!'
> A ::= # empty
Point not taken. Point, in fact, blew my mind. More research is required.
> Still beating up on slide 2 (sorry): The middle graf about "terminal" versus
> "nonterminal" is not really right. You might what to consult my explanation
> of "structural" versus "lexical", which lays out the concepts carefully:
> https://metacpan.org/pod/distribution/Marpa-R2/pod/Scanless.pod
Wilco. Again, I'm trying to baby-step things, and that might be one of
the baby-steps that gets a "... well, I lied to you earlier, to save
you some pain" slide later in the presentation.
> Slide 3: The first graf of this actually talks about the same thing as the
> middle graf of slide 1, but does get it right.
Huh. Okay.
> Slide 5: The LHS of a production is *not* a name. I'm repeating myself, but
> it's a really important point.
I haven't grasped the importance yet, but I haven't read the
above-lined POD yet either.
> Btw, the *major* difference between structural ("::=") and lexical ("~")
> rules is that the structural rules produce a tree and can have syntax
> applied to them. The lexical rules are just for recognizing strings.
That's a dramatically clear way to put it. That's going on a slide for sure.
> Slide 6: "G0" as a term is deprecated. It's now L0.
Consider it fixed.
> Slide 7: The SLIF "mess of directives" is the aspect of the SLIF where I
> most disappointed myself. I'm not sure how, but I feel I could have chosen
> better syntax for the various directives.
Nothing I can do about that, I'm afraid. I did change "mess" to
"collection", though.
> Slide 10: Btw, I picked up the term "adverb", and the basic idea for their
> syntax, from Perl 6.
Interesting tid-bit. I may slide that in, but Perl 6 has a bad
reputation in certain corners.
> Slide 12: Actually "::first" *overrides* the default "[name,values]"
> semantics. The slide suggests that first the "[name,values]" semantic is
> applied, then "::first". That's not the case. It's one *or* the other.
Yep. I've nuked the entire slide dealing with "[name,values]" and I'm
going to try again on it from scratch,
> I hope this is helpful! -- jeffrey
Jeffrey, you've never been anything _but_ helpful. Very, very many
thanks for taking the time to even look at it, let alone give such
good constructive criticism.
--
Paul
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: I may be teaching my colleagues Marpa
By the sound of it, I'll have plenty to draw on, or even just use, for my lessons (and it's turning into multiple lessons for sure) at work. This project really has some of the best community members of anything I've been involved in. You all rock like rockstars! For the record, my two more-or-less false starts so far are at https://docs.google.com/document/d/12Q8DGoFNB-vuwGtiifBlPZxUt3ZMBW-bqFSQzmji8tw/edit?usp=sharing and https://docs.google.com/presentation/d/1LCU4C8jdl8gM7eMg_yoab2dJqIy7YRMtOtLoUwEpBdk/edit?usp=sharing The latter is more recent, and slide-based, as opposed to the first one, which is older and a document. -- Paul -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
I may be teaching my colleagues Marpa
Yesterday, I was approached at work about the possibility of leading a seminar on Marpa . I feel thrills of excitement and of terror in equal proportion, but I'm going to start penciling together a few slides and see how it goes. I wonder whether any of the luminaries in the field (e.g. Ron, JD, and of course Jeffrey, among others on this list) would have any pointers on leading a group of competent Perl programmers from zero to hero in the space of an hour or two? Also, if I do go through with it, I wonder how much interest there would be in recording a screencast of the presentation (or a recording of the actual seminar) to be shared online? tl;dr? I need to teach Marpa. HELP! -- Paul PAUSE: P/PW/PWBENNETT -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Back on the SGML trail ...
On Wed, Feb 26, 2014 at 12:05 PM, Jeffrey Kegler wrote: > Looking at it, I noticed there seems to be no test suite. Test suites are > worth the trouble. Test suites for SGML parsing are are _hard_. I've tried getting one going using "vanilla" Docbook, and I can't quite get my thoughts in place to know what exactly I want the API to even look like. The plan is to have a test suite that roundtrips between two or more various SGML applications (maybe XML and Wikimedia or something). Also, test suites in general are hard. They assume that the person writing the tests is smarter than the person writing the code. I could do some Test::LectroTest generation of ... something, and at least have some "doesn't die" tests. > Perhaps related, a "target app" might help. Except that it should be > something you care about, don't be fussy about this -- all that is necessary > is that it exercise what you're developing in some way. The target app is mostly "gloria", my work-in-progress log-groveler. I want it to be able to comprehend any SGML application, and I want a command language to instruct it on how to attach semantics to the parsed syntax. For XML, the obvious route is via XPath and XSD (and maybe XSLT), and for structured text of other kinds (that isn't covered by an existing module, like JSON or YAML), Marpa's SLIF itself is probably the obvious route. For SGML, I think I'm going to need to generalize XPath, and that's why my main goal is reproducing an API that looks and feels a bit like Marpa::R2::HTML, because the end-user inputs to _that_ API are quite XPath-like. Thanks, also, for linking MarpaX::xPathLike the other day. I think some reading of both the source and docs is going to be required there. -- Paul -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Back on the SGML trail ...
I've had a sleepless night, so I've been tinkering with code. Among my efforts is the latest MarpaX::SGML at https://github.com/PWBENNETT/MarpaX-SGML Forewarning: I tend to do a lot of what Abelson and Sussman refer to as "programming by wishful thinking". Don't expect this code to run, and if it does run, don't expect it to be right. I'm more a kind of "smudge this in for now, and refine it when the time comes" kinda guy. That said, am I heading down a dark and dangerous path with this, or does it look like it might just (one day) work? Thanks for your time, -- Paul -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: A new blog post: Significant newlines? Or semicolons?
On Feb 25, 2014 8:25 PM, "Jeffrey Kegler" wrote: > > @Paul: While you're online, I've a question for you. You spoke of a Python port at one time. Did you have in mind Python 2 or 3? -- jeffrey > My preference would be both / either / let-the-user-choose. Since (when I pick the project back up) I'm going via SWIG, I hope the SWIGged stage will be helpful to others, too. I've got eleventy billion things on the boil right now, and Real Life keeps intruding. -- Paul -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: A new blog post: Significant newlines? Or semicolons?
On Feb 25, 2014 8:08 PM, "Jeffrey Kegler" wrote: > > Do not do either one. > I concur. FWIW, I think my current version of Marpa.tmLanguage does rely on some whitespace to figure out the highlighting rules, because it's easier to do the regexes. I'll add it to The Big List Of Stuff To Fix. Oh, and that reminds me: Marpa.tmPreferences is needed to help at least with Ctrl+/ commenting / uncommenting. Belated thanks for the LATM options, btw. I get the feeling my SGML magic wand is going to be a lot easier to build properly. -- Paul -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Moderately low-hanging fruit: Statistics Language
On Wed, Jan 15, 2014 at 5:28 AM, Paul Bennett wrote: > See the pre-print and slides here: > > http://ashishagarwal.org/2011/10/04/pdf-type-theory/ > > Basically, the author describes a DSL for describing statistical > distributions, and programming techniques for turning those > descriptions into random number generators. I've got what I think might be a good start on describing the DSL (barring misunderstandings) here https://gist.github.com/PWBENNETT/8435996 -- Paul -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Moderately low-hanging fruit: Statistics Language
See the pre-print and slides here: http://ashishagarwal.org/2011/10/04/pdf-type-theory/ Basically, the author describes a DSL for describing statistical distributions, and programming techniques for turning those descriptions into random number generators. This is something I've been looking for, on and off, for about 20 years. I think I'm going to have a try at implementing it, SGML having proven itself ludicrously high-hanging for the time being. On that note: If anyone wants to take over my SGML effort, I'll push my latest to the github repo, and you can feel free to have at it. The plan, such as it is, is to parse any dialect of SGML into an AST stored as a tree of Tree::DAG_Node objects, and to provide a Marpa::R2::HTML-like interface for transforming and translating the data, and to make a re-serializer to render the wrangled AST back into the same dialect of SGML as the original. Subsequent parts of the plan involve parsing schema documents into systems of callbacks that will validate an AST. Back to the statistics thing. The grammar is tiny, but involves Unicode. I'm tempted to provide "US Typeable" equivalents for the Unicode bits, which are mostly "Γ", "ϒ" and "⋅" as far as I can see at first glance. I trust nobody would object too loudly if I used "GAMMA", "UPSILON" and maybe "." for them? Maybe just "G", "Y", and "."? They also casually kick "π" around, and I'd assume "pi" is quite sufficient for "US Typeable" there. Expressions in the DSL look like: var x ~ random in return (x) std_normal := var u ~ random in var v ~ random in return (sqrt(-2 * log u) * cos(2 * pi * v)) normal e1 e2 := var x ~ std_normal in return (e2 * x + e1) Aside from me, does anyone else feel like teaming up on the coding of the semantics of the DSL as actual Perl code? I think I can handle the writing up of the DSL as a SLIF grammar, but the mathematics used in the rest of the document is right at the borders of my understanding. I know there are some _seriously_ smart cookies on this list, so maybe if I had one or two people prepared to act as "math coach" if / when the going gets tough, that might be enough. Thanks, -- Paul -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
