On Sun, Sep 23, 2018 at 6:41 PM Neil Van Dyke <[email protected]> wrote:
> 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). > > [...] > 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. > -1, I'm fine with reader syntax '#'. > * The popular `lambda`-ish and `define`-ish forms add support for [what > Laurent said above] > +1 * The `let`-ish forms add terse support for frequent multiple-value LHS > (without burdening single-value LHS, nor increasing rightward drift). > +1, yes please. * The `struct` definition forms also generate constructors with keyword > arguments for fields. > +1, or by symbol (but keyword is easier to check for correctness at compile time maybe). > * 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). > +1, I think. > * 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. > Dunno, maybe. > * 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. > That might just need a documentation tweak, like a margin note saying "Warning: Very often people think of using eval when better, faster and safer solution are available but depend on the case. Ask for help on the mailing list <...@...> if your unsure."? > * 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.) > Maybe as a submodule? I'd be happy with a one-file package; I firmly believe in the path-of-least-resistance philosophy (allow for quick and dirty first, but equally importantly also to easily gradually improve). > * 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. > Dunno, maybe. There are pros and cons, in terms of complexity. > * 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). :) > Not sure what you mean. I use square brackets a lot in `let`, `cond` and friends. That makes reading much easier to me. For vectors I sometimes use `@` or `@?` for vector-ref, `!` or `@!` for vector-set!, and `@?!` for a vector-update!: (@?! my-vector index λ(x)(+ (* 2 x) 3)) is even simpler than my_vector[index] = 2 * my_vector[index]) + 3 Maybe @ variant should be generics though. While we're on the wish-list: * Use '_' in place of '-' for word symbol appending. I've grown unfond of '-' word separators, and I heretically prefer '_' because I find it visually easier to group words with '_', and '-' also clashes with the minus sign, which makes it harder to read calculations. But I usually don't use '_' to avoid being frown upon too much :-/ -- 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 to [email protected]. For more options, visit https://groups.google.com/d/optout.
