unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Zelphir Kaltstahl <zelphirkaltstahl@gmail.com>
To: tomas@tuxteam.de
Cc: Guile User <guile-user@gnu.org>
Subject: Re: Re: Re parse-result
Date: Sun, 20 Jan 2019 12:35:20 +0100	[thread overview]
Message-ID: <e1c8f2a5-90ad-874e-d325-53e850833c6b@gmail.com> (raw)
In-Reply-To: <20190120083208.GA22502@tuxteam.de>

Hey tomás,

On 1/20/19 9:32 AM, tomas@tuxteam.de wrote:
>>                              My best bet for applying such a thing would
>> be to search through old documents from university [...] But this
>> is also only to prove that a language is not regular, if I recall
>> correctly.
> There's one for regular languages and one for context-free. The
> "repeating itself" in CFGs is a bit more elaborate (it's pairs
> that repeat, think parentheses :-) but the gist is similar.

Ah right, I forgot that there was one for CFGs too! I think I never
learned that one though. Neither Ogden's (which at least I have heard
of) or Parikh's.

>> I think in a practical setting (for example: "I want to write
>> a parser for ReStructuredText! Can I use parser combinators?") the
>> problem is, figuring out whether the real language is in a specific
>> class of languages and then understanding, whether or not the parsing
>> tool I want to use is able to parse such language.
> First you gotta have a grammar. There's a lot of fudging in that
> part (you can shift things to or from the "semantic part": e.g.
> you might want to express in your grammar that a variable has to
> have a "previous" declaration, but nobody in her right mind tries
> to do that).

Yes, I imagine that to be difficult to express in a grammar. On the
other hand, I know that (for example's sake) ReStructuredText has
arbitrary document internal references, so the sink or target of the
reference needs to be defined somewhere, possibly far away from the
reference itself. I think I am beginning to understand, why the
reference implementation of RST is more "rolled their own" instead of
visibly based on a grammar.

> Then you have to look at the grammar and see whether it is
> context-free. As above, you can try to fudge things a bit to
> "make it so" -- after all, you have a (nearly, the tape and
> your patience being limited) Turing-complete beast under your
> belt.

I was afraid someone would tell me I have to figure out the grammar
first, in order to judge the language class. :D

> In practice, most libraries and tools cheat, so most regular
> expression machines offer things which take them beyond regular
> languages (and you pay the price in possibly exponential run
> time, but us programming folks love that risk ;-) -- and most
> (sub-) CFG machineries cheat in similar ways, but that makes
> them interesting.
>> Is it trial and error in the end?
> That's our trade it seems :-) Have a look at this one:
>
>   https://en.wikipedia.org/wiki/Context-free_language#Decidability
>
> to get a "feel" on how fractal-y the limits are.
I always wonder how people know that their parsing approach will be
sufficient. So maybe they do not and simply try it with their favorite
parsing tool.
> OTOH -- all inputs being finite, all languages are regular,
> given enough time and storage :-)
I never thought about it like this. This is kind of funny actually. I
wonder what a "theoretical CS" teaching person would say to that. Maybe
that you still don't know ahead of time (parsing) exactly how long your
input is and that it therefore seems infeasible to construct a correct
grammar for that regular language, so in practice this does not help
you, when looking for a "correct" result.
>> Here is an example of such a case from some time ago, when I wanted to
>> do some parsing in Rust, because I could not use ReStructuredText in a
>> Rust project: https://github.com/flying-sheep/rust-rst/issues/4 (This
>> one actually mentions PEG parsing.)
> Thanks, and I promise I'll be having a look at this one. I just
> Should Be Doing Something Different (TM) at the moment, so it
> might take a couple of days.
>
> It just happens that I am doing some parsing stuff at the moment
> (an archeological language, using Python, alas, and their pyparsing
> combinator library. I'd rather play with Guile, but perhaps I can
> learn things to steal them later ;-)
>
> Cheers
> -- t

I did not mean to ask here for anyone to solve that one. Really only an
example of where I got stuck because of not knowing things and then
losing motivation.

Anyway, thank you for your reply!

Regards,

Zelphir




  reply	other threads:[~2019-01-20 11:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.109.1547658023.1050.guile-user@gnu.org>
2019-01-16 20:31 ` Re: parse-result (Catonano) Zelphir Kaltstahl
2019-01-16 21:47   ` tomas
2019-01-17  7:16   ` swedebugia
2019-01-17  7:43     ` Re parse-result Zelphir Kaltstahl
2019-01-17  9:56       ` swedebugia
2019-01-17 10:49       ` tomas
2019-01-19 13:23         ` Zelphir Kaltstahl
2019-01-20  8:32           ` tomas
2019-01-20 11:35             ` Zelphir Kaltstahl [this message]
2019-01-17 19:47       ` John Cowan
2019-01-16 20:34 ` Tangerine Edition penultimate report: how I voted, how you're, voting (John Cowan) Zelphir Kaltstahl
2019-01-20  2:24   ` John Cowan
2019-01-20 12:02     ` Arne Babenhauserheide
     [not found] <mailman.119.1547830820.13037.guile-user@gnu.org>
2019-01-18 22:27 ` Re: Re parse-result Zelphir Kaltstahl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e1c8f2a5-90ad-874e-d325-53e850833c6b@gmail.com \
    --to=zelphirkaltstahl@gmail.com \
    --cc=guile-user@gnu.org \
    --cc=tomas@tuxteam.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).