Issue description

REPL history is not being saved between sessions.

Environment

• Gosh version (commit hash if unreleased): v0.0.1
• go env output: not relevant

Minimal test code / Steps to reproduce the issue

1. Start gosh, type some code, exit.
2. Start gosh again, hit up arrow.

What's the actual result? (include panic message & call stack if applicable)

Nothing.

What's the expected result?

The previous line of code is loaded from the history.

Right now there is a mix of PNG and SVG, and the difference is noticeable.

We should implement an ability to sandbox the interpreter.

Extend scanner to handle several files.
Attach file names, line numbers, column numbers to tokens.

Contributing guidelines should include:

• local setup with modules and without them;
• code style (gofmt -w -s ., make check).

This is a tracking issue for commits that aim to increase code for interpreter package.

Maybe Gosh is not a great name after all…
(note the issue number)

Let's add basic colors to the REPL. Error messages should be in red and results should be in green. And there should be a flag to disable colors.

We probably should use github.com/fatih/color, but if there is something better – feel free to propose it.

Issue description

make check shows errors. It shouldn't – we should either tweak linters configurations or fix code.

Environment

• Gosh version (commit hash if unreleased): v0.0.1
• go env output: not relevant.

Minimal test code / Steps to reproduce the issue

1. Run make check.

What's the actual result? (include panic message & call stack if applicable)

go generate ./...
go install -v ./...
go run misc/check_license.go
golangci-lint run ./...
main.go:132: G304: Potential file inclusion via variable (gosec)
		f, err := os.Open(historyFilename)
main.go:170: G304: Potential file inclusion via variable (gosec)
	b, err := ioutil.ReadFile(filename)
internal/gofuzz/corpus.go:11: G505: Blacklisted import `crypto/sha1`: weak cryptographic primitive (gosec)
	"crypto/sha1"
internal/gofuzz/corpus.go:42: G401: Use of weak cryptographic primitive (gosec)
	name := fmt.Sprintf("%s-%040x.gosh", prefix, sha1.Sum(data))
internal/golden/golden.go:50: G304: Potential file inclusion via variable (gosec)
		tokens, err := ioutil.ReadFile(f + ".tokens")
main.go:135:21: Error return value of `liner.ReadHistory` is not checked (errcheck)
			liner.ReadHistory(f)
			                 ^
main.go:136:11: Error return value of `f.Close` is not checked (errcheck)
			f.Close()
			       ^
main.go:147:12: Error return value of `os.Create` is not checked (errcheck)
		os.Create(historyFilename)
		         ^
make: *** [check] Error 1

What's the expected result?

No errors.

Currently true and false are treated as keywords:

But they are normal predeclared identifiers like println. We should treat them as such. We also should remove special token types for them.

Scanner and parser should return them as identifiers, and they should be added into built-in objects.

https://golang.org/ref/spec#String_literals

We should extend scanner to return whole string literals with escaping, and then extend parser to handle escaping in StringLiteral.

https://travis-ci.org/gosh-lang/gosh

Gosh currently does not has a formal language specification. It should have one.

We should have comments in AST. Their placement must be preserved.

Problem: generated files may not be up-to-date in the repository.

Solution: check that generated files are up-to-date in the CI.

That might be as simple as running git diff --exit-code after make install.

Ok, the title is just a homage to the Ubuntu's bug #1. 😄

Please share your use-cases for Gosh in this issue. It will help us better understand how to improve the language.

https://codecov.io/gh/gosh-lang/gosh/tree/master/parser

Currently, go-fuzz finds crashers in the scanner. We should fix them.

1. Generate mathematical expression with integers and floats, and several operators and braces. For example:

42 + 7 / (13.0)

2. Generate and run a small Go program to get an expression result or error. For example:

package main

import "fmt"

func main() {
    x := 42 + 7 / (13.0)
    fmt.Println(x)
}

3. If there is no error, feed the same expression to Gosh and compare results.

For the first step, we may use go-fuzz with some initial corpus. Later we could create a custom code generator just for mathematical expressions. See also: #40.

While go-fuzz is doing a good job finding bugs in the scanner, it seems to be too inefficient for testing parser and lexer. We need something like https://github.com/dvyukov/gosmith for Gosh.

Language should provide eval() function to evaluate a string of Gosh source code.

https://github.com/golang/go/tree/master/test

Gosh uses "vanity" import paths, but does not enforce them as canonical import paths. That can lead to people importing Gosh via github.com/gosh-lang/gosh/....

We should enforce them. Let's add // import "gosh-lang.org/gosh/ast" comments to package ast in ast/ast.go, etc.

It should be possible to use any Go code from Gosh.

Right now Gosh has a very basic interpreter. We could make a Gosh-to-Go translator or VM.

The language currently does not provides goroutines. Before introducing them we probably should implement some kind of Gosh-level race detector.

Currently, they are not implemented at all.

Suggested label: hacktoberfest.

Function to extend: evalPrefixExpression (located in interpreter/interpreter.go).
Test should be added in TestPrefixExpression (added in #25).

Replace dummy tests with real tests.
See #51.

// The list of object types.
const (
-	INTEGER Type = iota
-	BOOLEAN
-	STRING
-	FUNCTION
-	GOFUNCTION
-	CONTINUE
+	Integer Type = iota
+	Boolean
+	String
+	Function
+	GoFunction
+	Continue
)

It may also require examples/tests update if anything depends on the stringer output for those.

Only Windows CI configuration is left. Open third-party issues:

• client9/shlib#3 (comment)
  • client9/shlib#13
  • client9/shlib#14

We should check types before evaluation.

We should do that before adding new language constructs like structs, methods, and interfaces.