getting to v1.0

[mflatt]

No language is ever done, but Rhombus is usable, documented, and stable. With a C FFI coming in the next week or so, Rhombus will have an end-to-end story that I see as one kind of "done" for the design and implementation.

A transition to 1.0 would signal that Rhombus is ready even for not-so-early adopters, and it would mean that we promise not to break programs going forward (or, at least, that the bar for breaking changes is much higher).

Task I see as remaining before 1.0, which I think could be finished over the next month:

• C FFI.
• More support for lower-level memory operations, like weak boxes and CAS.
• More evt constructors, such as alarm-evt.
• Improve the getting-started documentation organization and navigation, taking advantage of language-family rendering that became enabled at docs.racket-lang.org with the Racket v9.1 release.
• Revise rhombus-lang.org.

What more is needed? Is there anything else you think needs to be in place before we call it 1.0? Is there something that we will likely want in the near future, but that would need a breaking change if we don't get to it now?

[distractedlambda]

Regarding the lower-level memory operations, we already have it so that when you write:

class MyBox():
  field val = #false

you get a function MyBox.val that you can use to read and write the val field. Could we extend that function to be something more general (idk, Field or something?) that provides other modes of access like CAS?

[mflatt]

That sounds like a property. Do you have in mind some distinction that doesn't fit into a property?

[distractedlambda]

What I mean is that, in addition to being a function that can get and set the value, the MyBox.val created by the class form should also provide methods for atomic rmw operations, e.g. a .compare_and_set method. That way, there would be a straightforward way to perform synchronized access to fields without needing to add a level of indirection.

Part of what I'm channeling here is the JVM's notion of a VarHandle, or the Atomic{Integer,Long,Reference}FieldUpdater APIs that predated it.

[mflatt]

I think I see what you mean, and I can imagine something along those lines.

[distractedlambda]

Regarding breaking changes, what about deprecating None in favor of a new name like Never or Unreachable? None is used in Python as an analog to a "null" value, and I'm not sure I've otherwise seen it before as the name for a bottom type (though Kotlin's Nothing comes close).

[mflatt]

Nothing is arguably a better complement to Any than None. Never seems less parallel, but maybe it's clearer in context, so I'd be happy with that, too.

[usaoc]

I think I chose None because Racket has none/c, but Nothing may be better since it’s found in Typed Racket. Though, another thing to consider is both None and Nothing can allude to a kind of Option type, while Never or Unreachable clearly says something about the evaluation.

[rfindler]

Never sounds like nice to me. Also possibly worth considering is a longer name like TotalFailure or AlwaysFails or NeverSucceeds or something like, since this won't be used much and, when it is, it may make sense to call attention to it?

[capfredf]

I like Never

[mflatt]

#778

[mflatt]

All bullets except the one (revise the web page) are now done, so we're getting very close.

Thinking beyond the language itself, what's still missing in the ecosystem or potentially confusing for a new user? I notice that the Guide doesn't explain modules and packages, so that's one thing I'll add. It's also probably time to add a notion of language family to pkgs.racket-lang.org.

For distributing Rhombus, I think it makes sense to continue offering two installation paths: Rhombus+Racket installer and Rhombus as a package for an existing Racket installation.

• The former would be a download page along similar lines to the current "Install a snapshot Racket with Rhombus included" page. It will be a release version of Rhombus that is built with a release version of Racket.
• To improve the installation experience for the second path (relevant to Will racket-minimal include Rhombus? #781), there will be a package catalog with built Rhombus packages for recent Racket release versions. There can be Rhombus-version-specific catalogs plus a default catalog, which is the latest Rhombus release. Longer term, maybe Racket management will decide that it makes sense to have the default Rhombus catalog in a Racket release's configuration (i.e., in the package-catalog configuration alongside https://pkgs.racket-lang.org).
• Technical detail: Both the built-Rhombus catalog and the Rhombus+Racket installer will be derived from a Racket release build, so built packages will all be consistent (because built packages depend on specific builds of other packages, especially for fast installation).

I've prepared the catalog part of this plan, almost, and I think I see the path to Rhombus+Racket release builds. This plan allows Rhombus releases to be on a different schedule than Racket releases, and I imagine Rhombus will need more frequent releases for a while.

[sohang3112]

the Guide doesn't explain modules and packages, so that's one thing I'll add.

Yes how to import or create a new module or package is confusing. The Rhombus equivalents of the following Python should be documented in one place (if these are already there in one place please share link as I didn't see it in docs):

• Import styles:

import lib; lib.foo       # import module and then access variables or functions with dot (.)
from lib import foo, bar    # import specific things in module
from lib import *       # import everything from module in global namespace

# import from dynamic module path
from importlib import load_mdoule; module = load_module('/path/to/script.py')

• make a module or package that can be imported from the same or different folder

[mflatt]

The Rhombus Guide does have a section on modules and packages now: https://docs.racket-lang.org/rhombus-guide/module-and-package.html, where section 8.4 there describes import syntax in more detail.

[sohang3112]

Thanks, that link does clarify packages and imports.

I have a suggestion regarding documentation: a reference cheat-sheet should be prominently included near the start of docs. For example, this Racket reference is useful (though it's not in official docs): https://learnxinyminutes.com/racket/