On Sun, Sep 23, 2018 at 6:41 PM Neil Van Dyke <n...@neilvandyke.org> 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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
