rhombus-prototype VS inspector

See related post. The dot operator in Rhombus will allow a function call like expr.map(…) to be statically specialized to Some.map(expr, …) provided that expr carries sufficient static information. This isn’t possible in Racket given the lack of static information in general.

If you want to know more the best starting point is https://github.com/racket/rhombus-prototype They have discussion on the GitHub repo

Racket has the concept of binding space built on top of the scope-set model. The experiment language Rhombus makes heavy use of this for contextual bindings. Note that bindings are used for language extensions among other purposes in Racket.

The notion of “tail sequence” in general doesn’t exist in Lisp’s macro-expansion model, since Lisp macros are strictly local transformations. A “tail sequence” allows a macro to control the expansion of the whole context, which requires wrapping the whole context in another macro in Lisp’s model. This is what leads to proposals like #%local-definition in Racket. However, this notion does exist in the enforestation model, which is what the experiment language Rhombus is based on, although it’s probably not quite a Lisp ;)

Rhombus is: - just another #lang. It is built on top of the existing Racket VM and written in Racket. It interoperates with existing Racket code and uses the Racket expander. - macro extendable. Hygiene and all of the good stuff work. - being developed in the open. We meet biweekly over Zoom, and discussions also occur in GitHub Discussions.

Querying Git references for rhombus-prototype at https://github.com/racket/rhombus-prototype.git Using cached16617263581661726358301 for https://github.com/racket/rhombus-prototype.git DrRacket install: version mismatch for dependency for package: https://github.com/racket/rhombus-prototype.git mismatch packages: base (have 8.6, need 8.6.0.9)

Instead of hoping, you might consider reading the discussions to see what the developers are actually saying. Just a thought.

> show me an example of how having 'spec' is going to help me refactor the code that I got wrong the first time, as easily as what a proto-ML-like static type checker does. It's not a question of "types are bad vs types are good thing". It's a question of "this property was called 'name', but now I need it to be 'names', and I really need to know every possible place of my code base that uses it so that I can recursively change all code paths to handle the fact that it's a list, now." I read the spec doc a dozen times, and I don't think it does help in this simplest of simple case.

For this, I think the way to go is to use `fdef` to annotate the arguments to each function. This is a lot more explicit keyboard-typing on the programmer's part, but then so is a statically-typed language.

Where I think Clojure will still come up short is in tooling to support finding each reference in a better way than grepping your project for `:user/name`. All the information you need is in there, as you can see from this proof-of-concept tool[0], but it's not implemented seamlessly into the workflow.

[0]: https://github.com/clj-kondo/inspector

Hopefully specs are ending up in an s/fdef rather than a comment. Sadly no editor integration yet but I know /u/borkdude did some experiments looking at integrating this with clj-kondo here https://github.com/clj-kondo/inspector/. I'm not sure what the final verdict was for feasibility.