FAQ
Dear Go folks,

I've been able to move forward in the implementation and now I've
implemented the the basic combinators and am able to "ParseString"

http://play.golang.org/p/UzuzTLI0iA

I've used channels where ever there were lists in the original paper. It's
going to take some more work before interesting Parsers can be written.

It would be really helpful for me if some one could review my code
https://github.com/ckkashyap/parsec/blob/master/parsec.go and give me
feedback on my go usage, particularly channels.

Regards,
Kashyap

On Thu, Jul 25, 2013 at 5:02 PM, André Moraes wrote:


I meant lazy as in Haskell. Thanks for the paper reference.
Yes, waiting with the value is fine...as long as you don't go ahead compute
the whole list.
Regards,
Kashyap
func computeNewValues(result chan value, done chan struct{}) {
loop:
for {
value := "compute one value"
select {
case result <- value: continue
case <-done: break loop
}
}
}

func mainProgram() {
result := make(chan value, 0)
done := make(chan bool, 1)
go computeNewValues(result, done)
<-result // read one value
<-result // read another value
// here I don't need any values
done <- struct{}{}
}

In this way, you will always compute only the next value and not the
whole list of possible values.

The responsible for creating only one value is the blocking select
inside "computeNewValues"

The for loop ensure that new values will be generated until a signal
is received in the "done" channel


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

Search Discussions

  • Adnaan badr at Jul 27, 2013 at 6:01 pm
    Could you please write some quick tests? Its hard to figure out the intent
      of your code.
    On Saturday, 27 July 2013 17:07:06 UTC+5:30, Kashyap CK wrote:

    Dear Go folks,

    I've been able to move forward in the implementation and now I've
    implemented the the basic combinators and am able to "ParseString"

    http://play.golang.org/p/UzuzTLI0iA

    I've used channels where ever there were lists in the original paper. It's
    going to take some more work before interesting Parsers can be written.

    It would be really helpful for me if some one could review my code
    https://github.com/ckkashyap/parsec/blob/master/parsec.go and give me
    feedback on my go usage, particularly channels.

    Regards,
    Kashyap


    On Thu, Jul 25, 2013 at 5:02 PM, André Moraes <and...@gmail.com<javascript:>
    wrote:
    I meant lazy as in Haskell. Thanks for the paper reference.
    Yes, waiting with the value is fine...as long as you don't go ahead compute
    the whole list.
    Regards,
    Kashyap
    func computeNewValues(result chan value, done chan struct{}) {
    loop:
    for {
    value := "compute one value"
    select {
    case result <- value: continue
    case <-done: break loop
    }
    }
    }

    func mainProgram() {
    result := make(chan value, 0)
    done := make(chan bool, 1)
    go computeNewValues(result, done)
    <-result // read one value
    <-result // read another value
    // here I don't need any values
    done <- struct{}{}
    }

    In this way, you will always compute only the next value and not the
    whole list of possible values.

    The responsible for creating only one value is the blocking select
    inside "computeNewValues"

    The for loop ensure that new values will be generated until a signal
    is received in the "done" channel


    --
    André Moraes
    http://amoraes.info
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • C K Kashyap at Jul 28, 2013 at 4:08 pm
    I''ve added a couple of tests. One thing that, in my opinion, demonstrates
    the power of Parsec is the ability of generating complex parsers out of
    simple ones.
    In my Test_Runes - I generate a parser that parses 'A' followed by 'B'
    using the parsers that parse just 'A' and just 'B'

    Regards,
    Kashyap

    On Sat, Jul 27, 2013 at 11:31 PM, adnaan badr wrote:

    Could you please write some quick tests? Its hard to figure out the
    intent of your code.

    On Saturday, 27 July 2013 17:07:06 UTC+5:30, Kashyap CK wrote:

    Dear Go folks,

    I've been able to move forward in the implementation and now I've
    implemented the the basic combinators and am able to "ParseString"

    http://play.golang.org/p/**UzuzTLI0iA<http://play.golang.org/p/UzuzTLI0iA>

    I've used channels where ever there were lists in the original paper.
    It's going to take some more work before interesting Parsers can be written.

    It would be really helpful for me if some one could review my code
    https://github.com/**ckkashyap/parsec/blob/master/**parsec.go<https://github.com/ckkashyap/parsec/blob/master/parsec.go> and
    give me feedback on my go usage, particularly channels.

    Regards,
    Kashyap


    On Thu, Jul 25, 2013 at 5:02 PM, André Moraes wrote:


    I meant lazy as in Haskell. Thanks for the paper reference.
    Yes, waiting with the value is fine...as long as you don't go ahead compute
    the whole list.
    Regards,
    Kashyap
    func computeNewValues(result chan value, done chan struct{}) {
    loop:
    for {
    value := "compute one value"
    select {
    case result <- value: continue
    case <-done: break loop
    }
    }
    }

    func mainProgram() {
    result := make(chan value, 0)
    done := make(chan bool, 1)
    go computeNewValues(result, done)
    <-result // read one value
    <-result // read another value
    // here I don't need any values
    done <- struct{}{}
    }

    In this way, you will always compute only the next value and not the
    whole list of possible values.

    The responsible for creating only one value is the blocking select
    inside "computeNewValues"

    The for loop ensure that new values will be generated until a signal
    is received in the "done" channel


    --
    André Moraes
    http://amoraes.info
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@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 "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at Jul 28, 2013 at 4:30 pm

    2013/7/28 C K Kashyap <ckkashyap@gmail.com>:
    I''ve added a couple of tests. One thing that, in my opinion, demonstrates
    the power of Parsec is the ability of generating complex parsers out of
    simple ones.
    In my Test_Runes - I generate a parser that parses 'A' followed by 'B' using
    the parsers that parse just 'A' and just 'B'
    Test_Runes seems to demonstrate ultimate boilerplate rather than power
    for a very simple task which is parsing the succession of two things.
    Is it because you are unable to express it in a library function ?
    Maybe due to a lack of parametric polymorphism?

    Rémy.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • C K Kashyap at Jul 28, 2013 at 6:02 pm
    Well ... now that you mention, I can see why the "power" story is not as
    compelling :)

    While the test is about composing parser('A') and parser('B) ... in
    principle, this is for composing any two parsers. I'll work out some more
    compelling cases. I'd need to implement the "try" combinator first though.
    (I've been using this for reference -
    http://eprints.nottingham.ac.uk/archive/00000237/01/monparsing.pdf)

    I was hoping to get some confirmation if my usage of channels is indeed
    providing me lazy evaluation or not.

    Regards,
    Kashyap


    On Sun, Jul 28, 2013 at 9:59 PM, Rémy Oudompheng
    wrote:
    2013/7/28 C K Kashyap <ckkashyap@gmail.com>:
    I''ve added a couple of tests. One thing that, in my opinion,
    demonstrates
    the power of Parsec is the ability of generating complex parsers out of
    simple ones.
    In my Test_Runes - I generate a parser that parses 'A' followed by 'B' using
    the parsers that parse just 'A' and just 'B'
    Test_Runes seems to demonstrate ultimate boilerplate rather than power
    for a very simple task which is parsing the succession of two things.
    Is it because you are unable to express it in a library function ?
    Maybe due to a lack of parametric polymorphism?

    Rémy.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jan Mercl at Jul 28, 2013 at 6:05 pm

    On Sun, Jul 28, 2013 at 8:02 PM, C K Kashyap wrote:
    Well ... now that you mention, I can see why the "power" story is not as
    compelling :)

    While the test is about composing parser('A') and parser('B) ... in
    principle, this is for composing any two parsers. I'll work out some more
    compelling cases. I'd need to implement the "try" combinator first though.
    Try? The parser is backtracking?

    -j

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • C K Kashyap at Jul 28, 2013 at 6:18 pm
    Yes indeed :) if things work out correctly that is.
    It will explore all possibilities - lazily hopefully.
    Regards,
    Kashyap

    On Sun, Jul 28, 2013 at 11:35 PM, Jan Mercl wrote:
    On Sun, Jul 28, 2013 at 8:02 PM, C K Kashyap wrote:
    Well ... now that you mention, I can see why the "power" story is not as
    compelling :)

    While the test is about composing parser('A') and parser('B) ... in
    principle, this is for composing any two parsers. I'll work out some more
    compelling cases. I'd need to implement the "try" combinator first
    though.

    Try? The parser is backtracking?

    -j
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at Jul 28, 2013 at 6:30 pm

    2013/7/28 C K Kashyap <ckkashyap@gmail.com>:
    Well ... now that you mention, I can see why the "power" story is not as
    compelling :)

    While the test is about composing parser('A') and parser('B) ... in
    principle, this is for composing any two parsers. I'll work out some more
    compelling cases. I'd need to implement the "try" combinator first though.
    (I've been using this for reference -
    http://eprints.nottingham.ac.uk/archive/00000237/01/monparsing.pdf)
    I am not convinced that monads are the correct abstraction for
    expressing Parser combinators in Go. Go is an imperative language with
    side effects: you can take advantage of it to keep the syntax nice.
    I was hoping to get some confirmation if my usage of channels is indeed
    providing me lazy evaluation or not.
    It's not really providing lazy evaluation, but it's not eager either.
    I think closures are a much better way of implementing lazy evaluation
    than channels: the design you chose is nice and you can find similar
    examples in the Go tutorials. However using it on a large scale will
    cause a much larger memory usage.

    Rémy.

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJul 27, '13 at 11:37a
activeJul 28, '13 at 6:30p
posts8
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase