Skip to content
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

Incorrect parsing in the "language" series #1

Closed
amosonn opened this issue Sep 17, 2020 · 3 comments
Closed

Incorrect parsing in the "language" series #1

amosonn opened this issue Sep 17, 2020 · 3 comments

Comments

@amosonn
Copy link

amosonn commented Sep 17, 2020

This is maybe not the best place, but I couldn't find a repo for the contents of the language being implemented.

Currently, letaaa=1+2 would also be accepted. A workaround would be using the tag let (with space), a better approach would be to have extract_white_space(min=1) or so.

Perhaps it is planned to address this later, but it's worth to at least add mention for now.

@lunacookies
Copy link
Owner

Ah, thanks for the bug report. While I was writing the parser I realised this would happen, but decided to hope no-one would notice and leave it for the parser rewrite. I still think this is the best course of action, but maybe it’s worth leaving a footnote saying that the issue is acknowledged, but that it won’t be addressed until later. What do you think?

I couldn't find a repo for the contents of the language being implemented.

There’s a link to it on the Make A Language index page thing, but maybe I should make it more prominent. Where do you think would be a good place to put it?

@amosonn
Copy link
Author

amosonn commented Sep 21, 2020

I got to the blog-posts through TWiR, so I never saw the landing page. I think I would have expected it also in the 1st blog-post. But as it is, I just searched for it in your repos, and still didn't find it; I guess this one's on me :)

If you're rewriting the parser anyway, then it's probably not worth the trouble; but I think a footnote is in order, this is after all a shortcoming of the current one, perhaps all-the-more reason for rewriting?

If you are deleting parts of the code, I guess that begs the question, how are you going to structure it in the repo? Someone reading Post 2 might want to look through the full code at that point, even if you're already at Post 7. One option would be to have branches for each post; the other would be to use specific commit hashes, and then you'll also have a link to the repo in each post (at the end, probably).

@lunacookies
Copy link
Owner

I addressed this in part four of the series. Do you think it’s worth adding a footnote to where the bug was introduced?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants