LALR parser generators are not the last word in parsing technology. Many
unambiguous context-free languages are not well suited to LALR parsing. The
C language is an exception: the C grammar from the ISO standard can be
typed almost verbatim into a YACC/Bison file, and it will produce just the
one
7:36 PM, Ian Grant
wrote:
> LALR parser generators are not the last word in parsing technology. Many
> unambiguous context-free languages are not well suited to LALR parsing. The
> C language is an exception: the C grammar from the ISO standard can be
> typed almost verbatim into a YAC
On Mon, Sep 15, 2014 at 2:29 PM, Stefan Israelsson Tampe <
stefan.ita...@gmail.com> wrote:
> i find that logic programs together with memoization and auto cut ideoms
> helps in making powerful parsers, really fun at least.
>
You should definitely look at Tom's paper then, the "director's cut" is
On Mon, Sep 15, 2014 at 3:59 PM, Ian Grant
wrote:
> The parser's cache can be used as a compact representation of
> the otherwise hyper-exponential size of the ASTs ...
This is wrong. They're not hyper-exponential, they're just exponential.
> it could explore non-deterministic relations, like a
>This amused me, because I implemented the earlier (pre-oracle) parser he
described in Standard ML, and I did something which I thought later was a
bit stupid: I executed all the semantic actions _during the parse_ and
>cached the semantic results in the "memo-pad" along with the syntactic
derivati
I'll make this the last reply to my own message.
Here is a memoizing (with 'eager' semantic actions) implementation of
Ridge's combinator parsers in 221 lines of Standard ML. Scheme wouldn't be
much more,
Adding the binarizing grammar generator and an Earley oracle wouldn't add
more than another 3
On Mon, Sep 15, 2014 at 4:38 PM, Stefan Israelsson Tampe <
stefan.ita...@gmail.com> wrote:
> I have been wondering if one could speed proofs myself, and especially for
> type provers.
>
What do you mean by 'type provers'? Do you mean type inference? I did a
purely functional implementation of Hin
Ian Grant writes:
> LALR parser generators are not the last word in parsing technology.
[...]
> Important examples of grammars which are not LALR parsable include
> ASN.1 and Standard ML.
[...]
> But I think the problem of parsing has actually been solved. Tom
> Ridge's &qu
Hi Ian,
Replying to guile-devel, as mails to bug-guile open tickets, and I don't
feel like figuring debbugs out right now :)
On Sat 10 Sep 2011 16:02, Ian Price writes:
> I used the top 30 sites according to alexa.org, top 30 on reddit as of
> now, and the contents of my RSS reader (not necessa
Andy Wingo writes:
> Out of curiousity, you aren't getting any Transfer: chunked issues?
Actually, I have, but I'd been busy with other things and so hadn't
investigated. I'm assuming from this email that it hasn't been
implemented except as a header? :-)
--
Ian Price
"Programming is like pi
On Wed 21 Sep 2011 15:31, Ian Price writes:
> Andy Wingo writes:
>
>> Out of curiousity, you aren't getting any Transfer: chunked issues?
>
> Actually, I have, but I'd been busy with other things and so hadn't
> investigated. I'm assuming from this email that it hasn't been
> implemented except
y, let's try to use guile-log to deduce a little framework
for parsing and tokenizing. Here we go (DISCLAIMER NOT DEBUGGED CODE).
(use-modules (logic guile-log))
(use-modules ((ice-9 match) #:renamer (prepend-tag 'ice-9-')))
;; th
Dear Guile maintainers,
I want to report various problems with locale-dependent number
parsing in Guile version 3.0.8 (other versions, e. g. 2.2.7, have these
issues, too). Furthermore I want to propose a patch resolving these problems.
First consider the problems with function
‘locale
Dmitry Bogatov writes:
> Hello!
>
> Beeing in need to parse html(not xml) with Guile, I discovered that we
> have no one-true-way solution, like python's Beautiful Soup. The best we
> have is htmlprag-0.16. It works for me, good documented(even in
> TexInfo), but it is dropped by it's author. I t
taylanbayi...@gmail.com (Taylan Ulrich B.) writes:
> If I'm not mistaken, having a nontrivial amount of code (e.g. whole
> module) become part of the official Guile distribution requires the
> copyright of the code (and subsequent contributions) to be assigned to
> the FSF. So both you and all or
Mark H Weaver skribis:
> taylanbayi...@gmail.com (Taylan Ulrich B.) writes:
>
>> If I'm not mistaken, having a nontrivial amount of code (e.g. whole
>> module) become part of the official Guile distribution requires the
>> copyright of the code (and subsequent contributions) to be assigned to
>>
Hello Guilers!
RhodiumToad found an error in sxml where it would not properly parse CDATA: >
would be converted to > inside CDATA blocks. This is probably due to some wrong
reading of the XML spec:
"Within a CDATA section, only the CDEnd string is recognized as markup, so
that left angle b
Mike Gran writes:
> One of the things that looks odd are the complex numbers in polar format
>
> 0@+nan.0 equals zero, for example.
If that we accept the R6RS's (admittedly dubious) claim that +nan.0 is a
real number, I think this is correct.
We can deduce that mag*e^(i*ang) is 0 when MAG is 0,
This patch implements the ideas outlined in my response to Mike Gran's
recent post entitled "Effects of updated number fixes on parsing".
In brief, it modifies scm_i_string_to_number to apply exactness
specifiers to each component _before_ calling scm_make_rectangular or
scm_ma
Oleg replied that he will look into this bug when he has time (and that the
patch looked reasonable), which sounded non-imminent :) Hopefully this means
that there will be an upstream patch sometime in the future.
--
Linus Björnstam
On Thu, 16 Jan 2020, at 13:00, Linus Björnstam wrote:
> Hel
On Thu 03 Feb 2011 10:14, Mark H Weaver writes:
> This patch implements the ideas outlined in my response to Mike Gran's
> recent post entitled "Effects of updated number fixes on parsing".
Applied, and thanks again for the high quality of these patches, their
commit logs,
Hello!
Andy Wingo writes:
> On Thu 03 Feb 2011 10:14, Mark H Weaver writes:
>
>> This patch implements the ideas outlined in my response to Mike Gran's
>> recent post entitled "Effects of updated number fixes on parsing".
>
> Applied, and thanks agai
l...@gnu.org (Ludovic Courtès) writes:
> One nitpick: it would be nice if (part of) the documentation that’s in
> the commit logs were in the source files, so one sees it when reading
> the corresponding code.
Excellent suggestion. I've just submitted a patch to do this.
Thanks!
Mark
23 matches
Mail list logo
