parser: Error on function redeclaration #69
Conversation
|
firebase-deployment: https://evy-lang--69-zhgobwkg.web.app (dfc06ad) |
| p := &Parser{funcs: builtins, wssStack: []bool{false}} | ||
|
|
||
| p := &Parser{funcs: map[string]*FuncDecl{}, wssStack: []bool{false}} | ||
| for name, funcDecl := range builtins { |
There was a problem hiding this comment.
🍍 shame you can't use generics - you could use x/exp/maps.Clone() here (or on the line before even: funcs: maps.Clone(builtins))
There was a problem hiding this comment.
oh nice!! i think tinygo 1.27.0 is coming out soon and it works with got 1.20.
I wonder if the issue was again that I didn't hoist things on main.
I've got a cleanup PR due that replaces all errormessages with Printfs now that that's possible. In fact, I should maybe consider exposing them in evy!?
pkg/parser/parser.go
Outdated
| @@ -80,6 +84,14 @@ func New(input string, builtins map[string]*FuncDecl) *Parser { | |||
| p.advanceTo(i) | |||
| fd := p.parseFuncDeclSignature() | |||
| if fd != nil { | |||
| if p.funcs[fd.Name] != nil { | |||
There was a problem hiding this comment.
perhaps a switch?:
switch {
case p.funcs[fd.Name] == nil:
p.funcs[fd.Name] = fd
case builtins[fd.Name] == nil:
p.appendErrorForToken("redeclaration of function "+fd.Name, fd.Token)
case builtins[fd.Name] != nil: // could be `default:`, but maybe this reads better?
p.appendErrorForToken("cannot override builtin function "+fd.Name, fd.Token)
}
There was a problem hiding this comment.
or perhaps swap the last two cases?
There was a problem hiding this comment.
switch {
case p.funcs[fd.Name] != nil && builtins[fd.Name] == nil:
p.appendErrorForToken("redeclaration of function "+fd.Name, fd.Token)
case p.funcs[fd.Name] != nil && builtins[fd.Name] != nil:
p.appendErrorForToken("cannot override builtin function "+fd.Name, fd.Token)
default:
p.funcs[fd.Name] = fd
}There was a problem hiding this comment.
any of them. i'll got with your suggestion.
There was a problem hiding this comment.
I deliberately didn't do it your way since you can take advantage of the case ordering to put the happy path first and not require the more complicated case expressions. but up to you
There was a problem hiding this comment.
but we don't do the happy path first typically.
we do it left and last, don't we?
There was a problem hiding this comment.
but rules are made to be broken. happy path is more about less nesting than what comes first. it just ends up putting the happy path last mostly.
Error on function redeclaration, including builtin functions. Before we would just let new functions override existing functions which is pretty confusing, err early err often.
Error on function redeclaration, including builtin functions. Before we
would just let new functions override existing functions which is
pretty confusing, err early err often.