-
Notifications
You must be signed in to change notification settings - Fork 176
Closed
Description
I think we need an abstraction of Vec<T>:
- There's a
node_list_ttype that stores an array of node pointers. Is it intentional? For better locality it should be an array of nodes (i.e.node *instead ofnode **). - There's a stack of string literals that has fixed size, so this is another place where we need Vec
- We will need a stack of sets of local variables
- We will need a stack of "current attribute"s to distinguish errors like in
def foo(bar = bar)fromdef foo(bar = def foo(x = bar); end); end - We need a stack of nested contexts (module in class in method in defined etc) to know where we are during parsing.
- We need a stack of numparams to handle nested procs/lambdas with numbered parameters
- We need 2 stacks for pattern matching: one to track uniq items in a list, one to track uniq keys in a hash pattern
Also I noticed that nodes encapsulate tokens, is it intentional? There are cases when node needs a value that is based on token, but is slightly different:
- in
foo.bar = bazmethod name should be "bar=" - in
foo.(bar)method name is "call" - in
-foomethod name is "-@" (same with "+") - unary operators on numeric literals can include sign in their value for simplicity (i.e. "-42" should be
Int("-42")) - ... and maybe more.
I think it makes sense to extract a type string_t:
typedef struct {
char *start;
char *end;
} string_t;WDYT?
Metadata
Metadata
Assignees
Labels
No labels