FAQ
I've come across some behavior that is confusing me, and am hoping someone
can explain. I haven't isolated to a simple code example (and given the
behavior, I'm not sure I can), but I'm happy to upload a larger example if
it would help. The short version is that I'm sometimes seeing an
initialization loop error. What's confusing me is that I can make the
error go away by introducing a new variable which is not referred to by
anything else in the module.

The longer version is that I'm working on a custom Thrift protocol
(intended to be more readable/writable by humans than the existing
JSON/SimpleJSON protocols), and as part of my implementation I've built a
very simple parser/matcher. Here's a subset of the module, containing the
bits that fail to compile (again, I'm happy to share the whole thing if it
will help, but don't want to throw up a wall of code if it's not necessary).



type matcher func(s *backtrackingScanner) TProtocolException

type eitherSeparator struct{}

var _OR_ eitherSeparator

func matchMap(s *backtrackingScanner) TProtocolException {
return s.match('{',
atLeast(0, nil, "map elements",
matcher(matchAnyFn), matcher(matchAnyFn)),
'}')
}

func matchList(s *backtrackingScanner) TProtocolException {
return s.match('[',
atLeast(0, nil, "list elements", matcher(matchAnyFn)),
']')
}

func matchSet(s *backtrackingScanner) TProtocolException {
return s.match('<',
atLeast(0, nil, "set elements", matcher(matchAnyFn)),
'>')
}

func matchStruct(s *backtrackingScanner) TProtocolException {
return s.match('{',
atLeast(0, nil, "struct fields", matchIdent, ':', matcher(matchAnyFn)),
'}')
}

var foo = matcher(matchList) // this is what's confusing me.

var matchAny = oneOf(
matchBool, _OR_,
matchInt, _OR_,
matchFloat, _OR_,
matchString, _OR_,
matcher(matchMap), _OR_,
matcher(matchList), _OR_,
matcher(matchSet), _OR_,
matcher(matchStruct))

// this function was introduced in an attempt to break the initialization
loop.
func matchAnyFn(s *backtrackingScanner) (err TProtocolException) {
return matchAny(s)
}


If I comment out the definition of 'foo', or move it anywhere after the
matchAnyFn definition, I get an initialization loop error. If I leave it
where it is, the code compiles and runs as expected.

The name 'foo' isn't important, but the function converted to a matcher
does -- it must be matchMap, matchList, matchSet, or matchStruct.

Hopefully someone can explain why the presence and position of the 'foo'
definition matters. It's driving me crazy.

Thanks,
-Doug Muir

--
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

  • Minux at Feb 19, 2013 at 9:25 pm
    please give a complete program so that we can try compiling your example.
    i suggest you just upload the complete example to play.golang.org and give
    a link,
    we can download the source code with wget/curl by appending ".go" suffix to
    the
    URL.
    On Wed, Feb 20, 2013 at 5:18 AM, Doug wrote:

    I've come across some behavior that is confusing me, and am hoping someone
    can explain. I haven't isolated to a simple code example (and given the
    behavior, I'm not sure I can), but I'm happy to upload a larger example if
    it would help. The short version is that I'm sometimes seeing an
    initialization loop error. What's confusing me is that I can make the
    error go away by introducing a new variable which is not referred to by
    anything else in the module.

    The longer version is that I'm working on a custom Thrift protocol
    (intended to be more readable/writable by humans than the existing
    JSON/SimpleJSON protocols), and as part of my implementation I've built a
    very simple parser/matcher. Here's a subset of the module, containing the
    bits that fail to compile (again, I'm happy to share the whole thing if it
    will help, but don't want to throw up a wall of code if it's not necessary).



    type matcher func(s *backtrackingScanner) TProtocolException

    type eitherSeparator struct{}

    var _OR_ eitherSeparator

    func matchMap(s *backtrackingScanner) TProtocolException {
    return s.match('{',
    atLeast(0, nil, "map elements",
    matcher(matchAnyFn), matcher(matchAnyFn)),
    '}')
    }

    func matchList(s *backtrackingScanner) TProtocolException {
    return s.match('[',
    atLeast(0, nil, "list elements", matcher(matchAnyFn)),
    ']')
    }

    func matchSet(s *backtrackingScanner) TProtocolException {
    return s.match('<',
    atLeast(0, nil, "set elements", matcher(matchAnyFn)),
    '>')
    }

    func matchStruct(s *backtrackingScanner) TProtocolException {
    return s.match('{',
    atLeast(0, nil, "struct fields", matchIdent, ':', matcher(matchAnyFn)),
    '}')
    }

    var foo = matcher(matchList) // this is what's confusing me.

    var matchAny = oneOf(
    matchBool, _OR_,
    matchInt, _OR_,
    matchFloat, _OR_,
    matchString, _OR_,
    matcher(matchMap), _OR_,
    matcher(matchList), _OR_,
    matcher(matchSet), _OR_,
    matcher(matchStruct))

    // this function was introduced in an attempt to break the initialization
    loop.
    func matchAnyFn(s *backtrackingScanner) (err TProtocolException) {
    return matchAny(s)
    }

    If I comment out the definition of 'foo', or move it anywhere after the
    matchAnyFn definition, I get an initialization loop error. If I leave it
    where it is, the code compiles and runs as expected.

    The name 'foo' isn't important, but the function converted to a matcher
    does -- it must be matchMap, matchList, matchSet, or matchStruct.

    Hopefully someone can explain why the presence and position of the 'foo'
    definition matters. It's driving me crazy.
    --
    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 Feb 19, 2013 at 9:34 pm

    On Tue, Feb 19, 2013 at 10:18 PM, Doug wrote:

    I've come across some behavior that is confusing me, and am hoping someone
    can explain.

    It look similarly to http://code.google.com/p/go/issues/detail?id=4758 ?

    -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 Feb 19, 2013 at 9:38 pm

    On 2013/2/19 Jan Mercl wrote:
    On Tue, Feb 19, 2013 at 10:18 PM, Doug wrote:

    I've come across some behavior that is confusing me, and am hoping someone
    can explain.

    It look similarly to http://code.google.com/p/go/issues/detail?id=4758 ?
    Issue 4758 is not presented as a bug but rather a compiler print glitch.
    This one is a real bug anyway: here is a minimal example.

    package p

    type (
    E int
    S int
    )

    type matcher func(s *S) E

    func matchList(s *S) E { return matcher(matchAnyFn)(s) }

    var foo = matcher(matchList)

    var matchAny = matcher(matchList)

    func matchAnyFn(s *S) (err E) { return matchAny(s) }

    Deleting the "var foo" line triggers an initialization loop, which is absurd.

    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.
  • Rémy Oudompheng at Feb 19, 2013 at 9:40 pm

    On 2013/2/19 Rémy Oudompheng wrote:
    Issue 4758 is not presented as a bug but rather a compiler print glitch.
    This one is a real bug anyway: here is a minimal example.
    I have filed issue 4847.

    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.
  • Doug at Feb 19, 2013 at 9:52 pm
    Thanks for boiling it down Rémy.

    -Doug Muir
    On Tuesday, February 19, 2013 1:40:10 PM UTC-8, Rémy Oudompheng wrote:
    On 2013/2/19 Rémy Oudompheng <remyoud...@gmail.com <javascript:>> wrote:
    Issue 4758 is not presented as a bug but rather a compiler print glitch.
    This one is a real bug anyway: here is a minimal example.
    I have filed issue 4847.

    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
postedFeb 19, '13 at 9:18p
activeFeb 19, '13 at 9:52p
posts6
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase