Laurent wrote on 9/19/18 8:29 AM:
I don't mind `#:`, but I'd prefer to write `[#:foo 5]` rather than `#:foo [foo 5]`, that is, I don't like the repetition of the name (I first came to Racket precisely to avoid repeating code).

Now that you mention it, I realize that I'd probably use that myself (since it already fits my naming conventions, and would avoid a lot of clutter).  And the syntax you propose doesn't seem to break anything, and seems unlikely to conflict in the future.  My one problem with it is that I try to avoid introducing bindings to an identifier that doesn't appear as a lexeme in the source (like Racket already does for struct definition forms accessors&mutators), but this might be another reasonable tradeoff, and it's much smaller than the `define-struct` one was.

So... What do people think of a `#lang` that is mostly `racket/base`, but with a few additions, maybe something like the following?

* Symbols that start with `:` (and aren't `:` exactly) read as keywords.

* The popular `lambda`-ish and `define`-ish forms add support for the

* The `let`-ish forms add terse support for frequent multiple-value LHS (without burdening single-value LHS, nor increasing rightward drift).

* The `struct` definition forms also generate constructors with keyword arguments for fields.

* Support for embedded documentation for pro (ideally, also `provide`d by the module for both Scribble complete document generation and perhaps online help fragments), together with shorthand for define+provide+doc (and maybe contracts too).

* Support for terse embedded unit tests (e.g., you don't have to type out `(module+ test` all the time), and some standard lightweight unit test definitions (maybe not RackUnit nor Overeasy, since we can improve upon both) that work with the Racket package CI stuff.

* Maybe have a small language tweak to try to encourage people to know what they're doing before they use `eval`, and/or to make the use of such a powerful and oft-misused feature by a module more prominent.

* Look at making the "info.rkt" metadata optionally embeddable in single-source-file packages.  I can talk more about why one might want this sometime, but one of the big cases involves lightweight and interface-oriented modularity practices by default for well-engineered closed-source systems, and low-friction selective open sourcing.  (I think this also requires tweaking more than just the `#lang` itself.)

* Look at richer version/compatibility specification and confidence for package dependencies, and possibly also add in simultaneous multiple version support and/or other ways of providing backward compatibility.

* Tolerate square brackets, unless and until we someday find a much better use for them (replacing `send` isn't good enough, but maybe someday for vectors/arrays in dense numerical work). :)

These particular examples are off-the-cuff, and I rattled them mainly out to suggest a degree of tweaks, not an exact set.  I'm sure there are many opinions on the details, by people who love programming, and that people will also have base language itches they've been wanting to scratch for a while.  I don't know offhand how difficult it would be to find an optimal compromise, but maybe BDFL isn't necessary.

You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to