Interpreter crashing on sliced Array access

[64kramsystem]

When I access an array in sliced form Array[start, length], the interpreter crashes.

Sample command:

a = [0, 1, 2]
a[0, 3] # kaboom!

Exact run output (the interpreter overwrites the second line when crashing):

$ ./goby -i
Goby 0.1.2 😙 😇 🤔
» a = [0, 1, 2]
#» [0, 1, 2]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x7114c5]

goroutine 1 [running]:
github.com/goby-lang/goby/compiler/ast.(*BaseNode).MarkAsExp(0x0)
  /home/saverio/code/go/src/github.com/goby-lang/goby/compiler/ast/ast.go:36 +0x5
github.com/goby-lang/goby/compiler/parser.(*Parser).parseStatement(0xc420114240, 0xfdb598, 0x1)
  /home/saverio/code/go/src/github.com/goby-lang/goby/compiler/parser/statement_parsing.go:34 +0xbd
github.com/goby-lang/goby/compiler/parser.(*Parser).ParseProgram(0xc420114240, 0x7, 0xc420063e40)
  /home/saverio/code/go/src/github.com/goby-lang/goby/compiler/parser/parser.go:176 +0xdf
github.com/goby-lang/goby/igb.StartIgb(0xb1be56, 0x5)
  /home/saverio/code/go/src/github.com/goby-lang/goby/igb/repl.go:160 +0x4d1
main.main()
  /home/saverio/code/go/src/github.com/goby-lang/goby/goby.go:29 +0x954

===============

• Your operating system Ubuntu 16.04 64bit
• How did you install Goby From source
• Goby version 93d2e10fecedf5451e517afbcee2b8e275ad5217
• The value of $GOBY_ROOT $HOME/code/go/src/github.com/goby-lang/goby

[st0012]

@saveriomiroddi Can you help fixing this?

[64kramsystem]

@st0012 I need a couple of days to get acquainted with the lexer (or parser) :smile:

I will write back with a positive or negative answer in a couple of days :smile:

[64kramsystem]

@st0012 ok, I had a look at the parser, and definitely manual parsers are not my thing :smile: so I'll pass on this, sorry.

[st0012]

@saveriomiroddi So, would you suggest we use a parser generator? (this is not relevant to this issue)

[64kramsystem]

@st0012 this is an interestring/complex subject; I'm not sure.

Wrapping up the pros/cons of the current implementation:

• pros
  1. lots of work has been put on it, and it's working, which is fundamental :smile:
• cons
  1. I think it requires more maintenance (more bugs, and bugs are more difficult to fix)
  2. it has a high barrier of entry; it's very difficult to make extensions/bugfixes without knowing in details how parsers work
• open points
  1. I'm not sure about how programming language frameworks tackle parsing. I originally thought any large project would have a handcrafted parser, but turns out this is not correct; ruby for example uses bison (see introductory article).

I'm unsure. Switching in the short term would be very hard, because it would be a lot of work, and the current implementation works. I think the best approach is to have a look at how large projects tackle parsing, and then decide. In case parser generators would be the common practice, then definitely a parser generator should be seriously taken into account.

It's crucial to know that a handcrafted parser will cause newcomers to the project to struggle and likely not touch the parsing code (see the Regexp (#390) and Float (#443)), overall making the project less attractive to actively contribute to (IMO). I spent over an hour yesterday on this (#403) bug, and I have a vague idea of what's causing it, but I have no idea at all about how a fix would be, as it's hard to follow parsing logic in general.

For clarity, I had, in the past, experience with parser generators, but it was for SQL, which is a relatively small language.

[64kramsystem]

Another point: since Ruby uses a parser generator, and Goby is very similar, the Ruby grammar definition could (not 100% sure, though) be recycled, making the cost of switching [significantly] lower than starting from scratch.

[st0012]

But do you understand how to write those parser generator's grammar rules? I think understand the Go code's logic is still far more easier than learning how to write the grammar rules.

Using parser generator means contributors needs to learn both Go and how to define a grammar rule, which is like learning a new language. So I don't think switching to parser generator will lower the entry barrier.

[st0012]

And I personally want to restrict some syntax usage in Goby, and we also won't support some usages like URI("http://example.com"). So copying Ruby's grammar definition won't be a good way for switching to parser generator, we still need to define our grammar rules.

[64kramsystem]

But do you understand how to write those parser generator's grammar rules? I think understand the Go code's logic is still far more easier than learning how to write the grammar rules.

Fair enough, I take the perception of the difficulty of each approach is personal :smile:

[ishankhare07]

@st0012 is this issue still open? can you give me a heads-up for this- like where to begin debugging it. I can probably look into fixing this issue.

[st0012]

@ishankhare07 I think this issue hasn’t been fixed, but I can’t tell you much now because I’m about to fly home. You should join our slack and ask this in discussion channel and someone would help you https://goby-lang-slackin.herokuapp.com/

[Alexius-Huang]

I think PR #559 solved this issue, so this issue can be closed now.