advanderveer / gor Goto Github PK

• Completer example of Writing an Interpreter: https://github.com/skx/monkey/
• Rob Pike's Ivy: https://github.com/robpike/ivy/blob/master/scan/scan.go#L615
• Typechecker: https://github.com/AZHenley/knox/tree/master/typechecker
• Phylosophy of software design: https://www.mattduck.com/2021-04-a-philosophy-of-software-design.html

• Zero runtime exceptions
• Safe interop with Javascript
• Bundler included
• Aggressive Tree shaking
• Simple codebase for contribution: should be an absolute joy to contribute to the codebase
• Deal elegantly with types "context"/"providers". Passing values through the component tree (cross cutting) but with type safety

Inserting implicit semicolons is hackisch and comparing line numbers to distinguish between leading and line comments is also pretty bad: https://cs.opensource.google/go/go/+/refs/tags/go1.21.0:src/go/parser/parser.go;l=225

It could also improve code formatting.

Further acknowledged by the fact that the literal value of the "semi" colon is checked. in various places to separate an "implicit" vs an "explicit" one.

BUT: semicolon insertion seems common: https://www.reddit.com/r/ProgrammingLanguages/comments/w5m4l7/statementterminatorless_languages/

This should also allow decoupling of the parser, ideally it should only be dependant on the scanner. Not on the underlying file representation (except for error handling)

OR, maybe the comment token should carry more info about the line structure (since we only use it for lead/line information)

spec: https://go.dev/ref/spec#Semicolons

goweb (gow.dev, goweb.dev, goweblang.com)

Instead of some react-like library (that we need to include)

During expression parsing:

func (p *parser) parseBinaryExpr(x ast.Expr, prec1 int) ast.Expr {
	if p.trace {
		defer un(trace(p, "BinaryExpr"))
	}

	if x == nil {
		x = p.parseUnaryExpr()
	}
	// We track the nesting here rather than at the entry for the function,
	// since it can iteratively produce a nested output, and we want to
	// limit how deep a structure we generate.
	var n int
	defer func() { p.nestLev -= n }()
	for n = 1; ; n++ {
		incNestLev(p)
		op, oprec := p.tokPrec()
		if oprec < prec1 {
			return x
		}
		pos := p.expect(op)
		y := p.parseBinaryExpr(nil, oprec+1)
		x = &ast.BinaryExpr{X: x, OpPos: pos, Op: op, Y: y}
	}
}

To allow functions to be named, imported and used as <html-tag-name/>

Maybe just through the worker interface

E.g: bit flipping

So we can provide more clarity to the user

Or, maybe just re-use Go's actual ast types for all nodes that are the same?

Maybe use type aliases

Escaping inside double quotes
Backtick (uninterpreted) string literals

And easy ways to extend it with new loaders, and customise the final url as bundled

Extensibility usecases

• Adding Linting rules
• Add bundling of files (how to encode, how to return url)

Entensibility possibilities

• Should just include a package in the file with the go:generate (call a method to configure)
• Or, add an executable with gor-<name> for cross language extensibility (e.g protobuf)

Easily add linting rules through adding

• Add executable with given names gor-
• Or, go API

query by aria labels etc

When building the crewlinker/nxt ui it is common to type a component property with the requirement that it only accepts certain other components (only SVG, only img tag, or only certain other components)

This should be easy to do

Also, it should be easy to type what kind of child elements a custom component accept. In fact, why is there no type checking for build-in html elements being nested inside others in Current frontend frameworks?

See: https://stackoverflow.com/questions/57627929/only-allow-specific-components-as-children-in-react-and-typescript