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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.