-
Notifications
You must be signed in to change notification settings - Fork 50
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
Feature: implied parentheses #22
Comments
As a personal perspective -- after a long time of doing Lisp, and then coming to Haskell, I have come to value its visual terseness. It seems to increase the raw perception bandwidth. |
I agree that this would be nice if it could be done perfectly, but it’s trickier in practice than it might seem. I do think it would be cool to have an opt-in ML-like reader that you could get with
The fact that there are three different standards for this hints that this is a harder problem than it might seem. I would encourage you to study the different tradeoffs each of them makes to better understand what the challenges are. |
While I agree that Haskell-like syntax may be easier on the eyes for some, I doubt that the individual perception bandwidth is increased all that much. And the parentheses are not only useful for macros but for editors' structural editing capabilities (which can be thought of as development-time [i.e., pre-compile time] key-bound macros). |
Since this is 21'th century, we probably can have many (most?) parentheses implied, in a way that is not dissimilar to how Haskell does implicit
{ ... }
blocks (which people mostly don't use for a couple of reasons that are not directly relevant here, since the tradeoffs are different, because no macros).To be precise: the idea is to allow BOTH options (as in Haskell), since:
To consider the difference of presentation -- using the example from the README:
..versus:
The text was updated successfully, but these errors were encountered: