alexgustafsson / bake Goto Github PK

Implement simple conversions between types such as strings, bools etc. This makes it possible to convert, for example, an string environment variable to an int.

Instead of immediately panicking with the error, first print the location of the issue using the TreeError mechanism.

Should it always be output?
Should it optionally be output?
Should it explicitly be output (like it is now with print)?
Should a failing shell statement block the execution of the function or scope?

Move the current stdlib directory to contrib and document that they're a growing set of utilities for services etc. that are not meant for the stdlib (#15) itself.

Make engine handle and, or etc. and only expose "truthy" and "falsy" to the delegate. That way the engine may make decisions to not evaluate operands etc.

Make it possible to merge strings, arrays etc. This is done via the + operator as well as the spread operator.

There's a possibility that the current builtin mechanics will not scale well. Instead, create a stdlib where the imports have paths like std/io to use like so:

io::print("hello")

Perhaps some functions, such as print should be kept a builtin? Others, such as split, range etc. should perhaps not. They could even become a "property function" like in JS - "hello".split("\n"), Array.range(0, 2) etc.

The shell grammardDoesn't work for context.shell.stdout.string etc. as shell* will be marked as a string. Add an assert for only whitespace before the shell expression

The AST-based TreeError struct may be solved in a better way. Evaluate alternatives and see if the error formatting may be done in a less memory-intensive manner.

Comments have been solved in a hacky way. Whenever the parser sees a comment, it discards it and moves on. This makes it harder to keep the comments in the correct place in the AST. It's possible, however, to make them accessible via another channel. From the code:

// TODO: Hacky way of ignoring comments. Have them in a separate channel?
// or just add them to a separate structure for future referencing:
// comments.At(line, column) -> comment
for {
	item := parser.lexer.NextItem()
	if item.Type != lexing.ItemComment {
		return item
	}
}

Functions and rule functions should be able to be declared anywhere. In a perfect world, aliases and rules would to - but they may use top-level code and variables.

We want:

let prefix = get_prefix()
let version = "v0.1.0"
let commit = get_commit()
let go_version = get_go_version()
let compile_time = get_compile_time()
let build_variables = "-X \"$(prefix).Version=$(version)\" -X \"$(prefix).Commit=$(commit)\" -X \"$(prefix).GoVersion=$(go_version)\" -X \"$(prefix).CompileTime=$(compile_time)\""
let build_flags = "-ldflags '$(build_variables)'"

func get_prefix {
  shell go list ./internal/version
  return context.shell.stdout
}

func get_commit {
 shell git rev-parse --short HEAD 2>/dev/null
 return context.shell.stdout
}

func get_go_version {
  shell go version
  return context.shell.stdout
}

export func get_compile_time {
  shell LC_ALL=en_US date
  return context.shell.stdout
}

// Build tools
export alias tools: [vscode, nano, prism]

// Copy the nanorc file to the build output
export alias nano : ["tools/nano/bake.nanorc"]
"tools/nano/bake.nanorc" {
  shell {
    mkdir -p build
    cp tools/nano/bake.nanorc build
  }
}

// Build the vscode tool
export func vscode {
  shell {
    bake run --in tools/vscode package
    mkdir -p build
    cp tools/vscode/bake-lsp*.vsix build
  }
}

// Build the PrismJS grammar
export func prism {
  shell {
    bake run --in tools/prism build
    mkdir -p build
    cp tools/prism/build/* build/
  }
}

We have:

func get_prefix {
  shell go list ./internal/version
  return context.shell.stdout
}

func get_commit {
 shell git rev-parse --short HEAD 2>/dev/null
 return context.shell.stdout
}

func get_go_version {
  shell go version
  return context.shell.stdout
}

export func get_compile_time {
  shell LC_ALL=en_US date
  return context.shell.stdout
}

let prefix = get_prefix()
let version = "v0.1.0"
let commit = get_commit()
let go_version = get_go_version()
let compile_time = get_compile_time()
let build_variables = "-X \"$(prefix).Version=$(version)\" -X \"$(prefix).Commit=$(commit)\" -X \"$(prefix).GoVersion=$(go_version)\" -X \"$(prefix).CompileTime=$(compile_time)\""
let build_flags = "-ldflags '$(build_variables)'"

// Copy the nanorc file to the build output
export alias nano : ["tools/nano/bake.nanorc"]
"tools/nano/bake.nanorc" {
  shell {
    mkdir -p build
    cp tools/nano/bake.nanorc build
  }
}

// Build the vscode tool
export func vscode {
  shell {
    bake run --in tools/vscode package
    mkdir -p build
    cp tools/vscode/bake-lsp*.vsix build
  }
}

// Build the PrismJS grammar
export func prism {
  shell {
    bake run --in tools/prism build
    mkdir -p build
    cp tools/prism/build/* build/
  }
}

// Build tools
export alias tools: [vscode, nano, prism]

https://rome.tools/blog/2021/09/21/rome-will-be-rewritten-in-rust

Whitespace is generally ignored by the parser, but newlines are not. This makes the parser explicitly deal with newlines here and there, which may hurt flexibility in the syntax.

let object = {
  is_this_legal:
   1,
  // ?
}

[0,

1, 2

]

func (
 a,
 b
)
{
  // helllo
}

Allow trailing commas in arrays, arguments, objects etc.

The parser seems to become stuck when evaluating "hello\tworld" and other evaluated strings.

Currently, all values are evaluated - but the syntax borrows from other languages where short-circuiting is implicit. Bake should follow the same standard.

Assignments are not full featured. They don't handle assigning to object properties and the value they assign to may not always be what the user actually wants.

Rule functions and using them (deriving them) in a rule should be implemented.