You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having now written a couple hundred lines of Rhombus code, I tried to write down a few observations.
First, Rhombus code takes some getting used to for a Racketeer, and there are plenty of rough edges, but overall it ends up looking quite nice. I'm more positive about the direction than before doing this.
I think there are some "style" questions that are important to think about now. In particular, how much do we want to lean into the dot, and how much do we want to encourage a pipeline style. I think the dot matters the most right now, because it affects other aspects of the design. For example, if we want to write a lot of programs with method call syntax, then we need a way to add methods to things, and we need to think about questions like whether we should support adding methods to the same type in multiple places. We should also think about harder questions like whether this style relies too much on annotations, or whether we need to add more generic operations that use runtime dispatch.
For the pipelined code question, I think the big thing is that we should build in something like fancy-app sooner rather than later.
Another thing that I think merits early thought is how Rhombus can support quoted data. The More tutorial uses xexprs for HTML, which works very well. Do we want to (a) build in support for quoted s-exps (b) provide some escape to Racket (c) expect people to write bespoke HTML construction (d) have a nice Rhombus macro that generalizes such libraries (e) something else?
The third thing I think worth discussing at this point is how to support macro writing. Macros in Rhombus, because of the multiple layers of syntax, are harder to connect from patterns to concrete syntax, which makes it (in my experience so far) harder to write. This is probably some combination of syntax classes, library forms, error messages, tooling, and documentation, and we should think about this challenge.
I'm excited to figure out the answers to these questions, and to hear about how everyone else is navigating them.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Having now written a couple hundred lines of Rhombus code, I tried to write down a few observations.
First, Rhombus code takes some getting used to for a Racketeer, and there are plenty of rough edges, but overall it ends up looking quite nice. I'm more positive about the direction than before doing this.
I think there are some "style" questions that are important to think about now. In particular, how much do we want to lean into the dot, and how much do we want to encourage a pipeline style. I think the dot matters the most right now, because it affects other aspects of the design. For example, if we want to write a lot of programs with method call syntax, then we need a way to add methods to things, and we need to think about questions like whether we should support adding methods to the same type in multiple places. We should also think about harder questions like whether this style relies too much on annotations, or whether we need to add more generic operations that use runtime dispatch.
For the pipelined code question, I think the big thing is that we should build in something like
fancy-app
sooner rather than later.Another thing that I think merits early thought is how Rhombus can support quoted data. The More tutorial uses xexprs for HTML, which works very well. Do we want to (a) build in support for quoted s-exps (b) provide some escape to Racket (c) expect people to write bespoke HTML construction (d) have a nice Rhombus macro that generalizes such libraries (e) something else?
The third thing I think worth discussing at this point is how to support macro writing. Macros in Rhombus, because of the multiple layers of syntax, are harder to connect from patterns to concrete syntax, which makes it (in my experience so far) harder to write. This is probably some combination of syntax classes, library forms, error messages, tooling, and documentation, and we should think about this challenge.
I'm excited to figure out the answers to these questions, and to hear about how everyone else is navigating them.
Beta Was this translation helpful? Give feedback.
All reactions