-
-
Notifications
You must be signed in to change notification settings - Fork 58
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
initial candidate experimental prototype Rhombus #163
base: master
Are you sure you want to change the base?
Conversation
As you know, it's very big and it seems pointless to comment on little things. I have lots of little comments, like want things like The propagation-of-dot-information discussion feels ad-hoc to me. I think it would be nice to be able to explain how the current prototype propagates as far as it does and how it would be easy (or not) to get that pushed further, rather than just say "Maybe it should go further". In other words, I feel like there should be a "dot protocol" that is discussed. I'd like to hear how the syntax discussion does or does not comport with syntax classes and whether that is "nice" (or rather how hard a rhombus-wrapper is to make) |
Pasting an installation guide here, in case anyone wants to try it out:
To get @mflatt's repo, run:
To get this PR (which as I understand is more stable, but will be behind @mflatt's repo), run:
If you have an out-of-date Rhombus, update to the latest version with For @mflatt's repo:
For this PR:
|
|
I think I agree about the propagation-of-dot question. The parts here are some of the last pieces I put in place for the draft proposal, and I figured it was better to start a discussion than try to sort out more. I expect syntax quotes to work well with syntax parse and syntax classes, and they work well for implementing all the predefined forms using Racket. The S-expression encoding of shrubbery notation is working the way it's supposed to. Using Yes, I mean that Yes, a binding form can bind multiple variables, as in I'll get corrections and clarifications in the next update. |
A thought on names like |
Change `define`->`def`, `value`->`val`, `function`->`fun`, and `forward`->`let`. Also, precedence declaration now supports `same-on-left-as` and `same-on-right-as`, used to disallow `*` on the right of `/`.
I somehow missed the |
|
The For example, suppose you write this, where
The |
The new draft uses Imports now involve a prefix by default to discourage “namespace dumping” (see #159). Supporting hierarchical names for imports and other purposes, such as The idea of dot providers for the infix It's not clear that overloading |
The required prefix is pretty painful for operators as you note. I can't really know without trying to program in it, but I feel like I might want the ability to only import some things without a prefix by explicitly naming them:
I don't understand why the dot-provider doc repeatedly uses the phrase "(with|has|) a structure-type contract"... why is it not "a dot-provider"? For example, why does A in In the dot provider doc, you talk about how a parenthesized expression defeats dot propagation. That's very unsatisfying and I feel like a syntax-property system could propagate the information out. Finally, I don't understand why the Typos:
|
The Yes, the dot-provider part generalizes to contracts that have associated dot providers, not just structure-type names. The main document says that, but I haven't written the extra document well enough, yet. Things can also be dot providers directly, but I haven't written that down well enough, either. Parenthesization does not normally defeat dot providers. The "modulo parentheses" part at the top is meant to say that extra parentheses are fine, except currently in that last special case (which could be revised). See the updated enforestation proposal (#162) for more on lexicons, which are used for imports, and why the |
|
The latest draft fills in the explanation of static information as a generalization of dot providers, and the explained features are now implemented. The implementation now requires a Racket snapshot dated 20210807 or later. Looking forward, my plan is to add lists and general indexing of the form |
Excellent |
These additions triggered a further revision of static info and bindings, which has evolved to an even more Turnstile-like bindirectional protocol at the level of bindings.
The latest version adds lists, arrays, and maps. Really, this version is an overhaul of the static-information and binding system, which has evolved into a even more Turnstile-like system of bidirectional flow. The “downward” flow is mostly constrained to binding space (as opposed to expressions), but the In summary, the proposal is now really four things:
These four things are separable to a large degree. For example, the Rhombus expander and the static-information layer could be adapted to a different reader-level syntax. It makes sense to discuss the merits of individual pieces, and that's why there are multiple PRs. But these pieces have also been codesigned in an attempt to make everything fit together nicely, and it's probably easier to judge the combination than the pieces. |
Ship it ;) |
Partial reversal of previous design choice. Also, printing is now implemented.
I've updated the proposal for changes to shrubbery notation (#122). Although the changes at the shrubbery level seem big, the effect on the |
Also, reorganize macro forms to `macro` and `rule` variants and add `rhombus/macro` for importing macro and compile-time bindings.
'keyword' -> ~keyword ? -> ' ¿ -> $ +$ -> &
The demo file reads much better for me with |
Just so everyone knows, the switch to Rhombus discussion should be here in GitHub as much as possible, especially on specific proposals, but this kind of detail benefited from real-time interaction. Of course, the conclusion is not set in stone, merely the next thing to try. |
Note that currently DrRacket seems to get frozen on
|
@sorawee Change pushed to mflatt/shrubbery-rhombus-0. |
Searchability of ConstructsIt is probably a good idea to have names for uncommon operators in order to improve searchability. If a beginner sees Formatting of RFCI would recommend adding a TOC to the 0000-rhombus.md doc using internal links for easier navigation. |
I read
and was very confused for a while, because I thought it's defining a function
I really like pattern matching though, so personally I think either of the following should happen:
For (1), I'm thinking about languages like ReasonML which does not provide function definition shorthand, but its lambda syntax (borrowed from JavaScript) is really concise. And users seem to be perfectly fine with the absence of the function definition shorthand.
For (2), it will still be confusing, but not as confusing as the |
@sorawee Another possibility: get rid of Using |
@mflatt could you elaborate on this bit from the proposal?
I much prefer |
To make sure we're on the same page: It would work to have Suppose that How would In general, it seems like only the binding form can know how the expansion should interact with I note that the issue exists even within |
For example, `1+2` immediately produces `3` without an extra line containing `;`.
The special treatment of keywords as keys does not seem like a good idea after all.
rhombus/0000-rhombus.md
Outdated
... `)`. Keyword keys with values can be written like keyword | ||
arguments to `Map`, but seperate key and value arguments must be | ||
combined into a two-element `(` ... `)`: | ||
... `)`. Within curcly braces, the key and value are joined by `:`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:s/curcly/curly
rhombus/import-export.md
Outdated
extensible, but it includes the following forms: | ||
|
||
* `rename` followed by a block with any number of groups of the form | ||
`<old-name> 'to' <new-name>`, where each `<old-name>` or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'to'
should be changed to ~to
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also seems that the prefix convention has changed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, "import-export.md" was out-of-date, now updated.
Rendered
Here's an initial candidate experimental prototype Rhombus using shrubbery notation.