-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generic type for Trait functions #1553
base: main
Are you sure you want to change the base?
Conversation
} | ||
|
||
TraitFunction: TraitFunction<Expression> = { | ||
<name:Identifier> ":" <params:TypeTermList> "->" <value:TypeTermBox> => TraitFunction { name, ty: Type::Function(FunctionType{params, value}) } | ||
<name:Identifier> ":" <ty:Type> => TraitFunction { name, ty } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know where the parsing ambiguity comes from?
I think we could change this to TypeTerm here and fix it, but then we would need to use parentheses for functions which is not ideal.
Would it be an option to have to lines here, one for an explicit function as before and one for TypeTerm?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the other hand, it's not too bad to use ;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok I think it's because a: x, y, z -> w
would need too much look-ahead to find out the meaning of the ,
after the x
. Although it's really not too much look-ahead, it's just a single token...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok I think it's because a: x, y, z -> w would need too much look-ahead to find out the meaning of the , after the x. Although it's really not too much look-ahead, it's just a single token...
Yes, exactly, by using commas at the end of functions, the parser cannot differentiate when it's another type and when it's the end of the function.
Would it be an option to have to lines here, one for an explicit function as before and one for TypeTerm?
Not really, because it would be equivalent to simply "opening" Type
in its two possible variants and replacing them.
On the other hand, it's not too bad to use
;
And it's like in Rust 🥇 😝
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean rust traits use fn
functions.
I would really like traits to be similar to structs, and I think the two alternatives would work: Note that the second is not Type but TypeTerm, so if you want to use that to represent a function type you would have to put it in parentheses. But you could still use
trait X<T> {
some_const: T,
some_fun: T -> T,
}
Generalises the type of the functions of a trait, to allow more than just functions.
To avoid ambiguity in the grammar, the token marking the end of a trait function was changed from
,
to;
.