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

Hash-map literal reader syntax never introduced #452

Open
rjtobin opened this issue Oct 5, 2019 · 7 comments
Open

Hash-map literal reader syntax never introduced #452

rjtobin opened this issue Oct 5, 2019 · 7 comments

Comments

@rjtobin
Copy link
Contributor

rjtobin commented Oct 5, 2019

Small omission in the guide: it is implied in step 9 that a {} literal should be parsed as a hash-map in the reader, but this is never explicitly stated earlier on. The sentence in question is: "This is basically the functional form of the {} reader literal syntax".

@kanaka
Copy link
Owner

kanaka commented Oct 6, 2019

Handling of hash-map literals in the reader is described in the deferrable section of step 1. Are you wanting something more? Would you like to send a PR with the change(s) that you think would clarify this?

@rjtobin
Copy link
Contributor Author

rjtobin commented Oct 6, 2019

Thanks for the quick reply! I meant specifically the notion that {} represents a hash-map. Maybe this is still mentioned somewhere? I tried searching for every occurrence of { but couldn't find it. I'm happy to make a PR with a couple of additional sentences.

@kanaka
Copy link
Owner

kanaka commented Oct 6, 2019

@rjtobin oh, you're right! You're the first person to mention this. I think it quickly becomes obvious once you run any of the tests, but it does appear to be stated directly in the guide. I think the same problem applies to vectors.

Yes, please send me a PR. I'm in the home stretch of a PhD dissertation at the moment. I can give 30 seconds to sanity check a PR but all my writing mental energy is over allocated at the moment :-)

@rjtobin
Copy link
Contributor Author

rjtobin commented Oct 6, 2019

It's probably obvious to a Clojure person, but I was a little unsure. Anyway, I'll make the PR shortly. I'm finishing up a Zig implementation (Step9 is passing; just need to do Step A and some tidying), will hopefully make a PR for that soon too.

Good luck with the PhD writeup! I was in the same boat not too long ago.

@dubek
Copy link
Collaborator

dubek commented Oct 6, 2019

wow, a first implementation in 'Z' ! Exciting!

@kanaka
Copy link
Owner

kanaka commented Oct 6, 2019

👍 And then we'll just have three letters to go: 'Q', 'U', and 'X'. I suspect we'll hit 100 implementations before we cover the alphabet though.

@asarhaddon
Copy link
Contributor

Some related questions…

  • Should we rename hash-maps to maps? The term is confusing as the underlying implementation is irrelevant.

  • What is the purpose of dissoc? I know it is already optional, but passing all optional tests seems a common motivation. From my experience, dissoc is a painful step in languages without native mutable maps. I once implemented immutable AVL trees, dissoc alone did represent half the source code. This was instructive, but almost unrelated with LISP.

  • Could {...} be defined as a reader macro for (hash-map ...)? This would remove all map stuff from step 1 and the reader, exactly as @ does for can be implemented long before atoms. Better separation of concerns in types and reader would help both the initial implementation and later maintenance. Of course, this would require changes in most implementations, even if mostly trivial.

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

4 participants