-
Notifications
You must be signed in to change notification settings - Fork 32
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
Lexer behaviour #45
Comments
I am fine either way. You could also do something like this:
|
Ok, so let's go with option 1 where I add two new callbacks to the lexer behaviour. It doesn't break backward compatibility, which is good.
I'd prefer if you added that to |
I will push tomorrow morning the latest and do a new release. |
NimbleParsec v1.2.3 is out! |
I haven't updated the behaviour yet, but I think I'll make the two new callbacks optional so that old lexers don't need to update. Even in this case, I'm not sure how I'll handle the The important part is that the latest version of the Elixir lexer already implements the two new combinators, which means I could reuse it for my (H)EEx lexer (which I'll publish today). |
Pinging @josevalim because of the discussion on the NimbleParsec repo.
Currently, the lexer behaviour defines these two callbacks: https://github.com/elixir-makeup/makeup/blob/master/lib/makeup/lexer.ex#L8-L17
However, when I defined this behaviour, I was thinking of reusing combinators from one lexer inside another lexer. The goal would be to be able (for example) to create an EEx lexer that would call the Elixir lexer for the Elixir part. This means that the
root_element
and theroot
combinators should be accessible from outside of the Lexer as combinators (not only as functions).My question is:
root_element__0/6
function and aroot__0/6
function?fun__0/6
) are exported?I think that for backward compatibility reasons we should go with option 1. Also, the way we are implementing the
lex/2
function in most lexers is based on a the fact that aroot/1
function exists.What do you think @josevalim? This would be a good case for the
export_combinator: true
option you've talked about?The text was updated successfully, but these errors were encountered: