-
Notifications
You must be signed in to change notification settings - Fork 472
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
Do we have keywords? #463
Comments
Well the spec says that there's no concrete syntax, which would tend to imply that there aren't any keywords either! The grammar's so rigid that there's surely no danger of conflicts if we do allow re-use of keywords, but looking at the parser/lexer source it looks as it might require quite a lot of rewriting to do that, since it does have to treat 'keywords' specially when they appear in certain positions, but when you tell the lexer that they are keywords, it'll complain if it finds them elsewhere. Another issue here is that now that we have extensible builtins we've kind of lost control of the grammar: some external person might unwittingly implement a new builtin called |
Well, in this instance it bit me because I had a generated AST with |
Modifying the lexer/parser would get us away from standard methods - this is pretty much exactly what you do in other languages. But it would be possible if we really want compliance with the spec, I guess - it seems to me a little weird. |
Easy solution: keywords like Is that the sound of distant screaming I hear? |
I think the easiest solution is to just make
I'm sure that some clever person could exploit that to their advantage in writing malicious obfuscated code. I propose we make all the relevant things into keywords and any case where the generated ASTs would try to use those names, we just append some unique number or an underscore or some junk like this. |
Can I close this? Or do we want to note this somewhere in the spec? |
If we have keywords then IMO that should be in the spec. I don't buy that there is "no concrete syntax" - the figure says "lexical grammar of Plutus Core" which sure sounds like it's telling us how to tokenize it! IMO builtin names should also not be keywords, but that would be a parser change. We know that we're getting a builtin name from context, so we can just parse an arbitrary identifier, try to map it to a builtin, and fail if it's missing. |
I'm just in the process of trying to get the spec sorted out, so I'll deal with this shortly. |
I've now modified the spec to say that |
Are syntax identifiers like
lam
,error
etc. keywords?echo "(program 1.0.0 (lam error (forall a (type) a)) error" | plc typecheck --stdin
Unexpected 'error' at 1:21
The text was updated successfully, but these errors were encountered: