Stephen De Gabrielle wrote on 2/6/19 11:25 AM:
Dave Herman recently tweeted
BTW, Dave Herman was a great contributor of Racket (PLT Scheme)
packages, and has been missed, though I understand the attraction of
Mozilla at the time.
More generally, can you recommend resources a developer (without a
background in language design) should refer to if they are building a
simple templating system, application configuration file, etc. - that
may grow into a little language?
If I could offer a few quick general guidelines instead:
* Consider whether declarative or imperative is better. Declarative can
let you do more static reasoning (even though you might implement by
syntactic transformation to imperative Racket), and is often the thing
to do. However, sometimes imperative is what you want even when
initially it looks like declarative, especially when you get into the
next guideline...
* If you ever find yourself writing bits of an imperative language,
consider just exposing a real language, like Scheme. Even if you don't
go for Emacs-like extensibility, there is a long-long history of
everyone almost always reinventing a half-butted language when they
would've been in a much better position by taking a real language off
the shelf. Perhaps a real language with extensions (like, if you really
want a prototype object system, go Scheme with a small layered prototype
object system).
* Consider whether your DSL, in which the the two previous guidelines
might have you do as a mix of declarative with scattered bits in an
off-the-shelf real imperative language... is even better as the
off-the-shelf imperative language at the top level, with a couple really
well-chosen syntax extensions or procedures.
* Don't be overinfluenced by the above guidelines. Often, the less we
know, the easier it is to make blanket generalizations. :)
Sorry I have to run and can't give a more thoughtful brain dump right
now, but quick anecdotes of my own (criticize oneself first) from
Racket: two non-public DSLs I made, one for high-performance XML
transformation, and one for processing some cool and big tabular data,
both make me cringe -- partly because of how I implemented them
(`syntax-rules` rather than `syntax-parse` or `syntax-case`), and
partly, with the latter, a bit less contrived declarative would've been
more flexible yet looked about the same.
Another DSL, I might be the only one who likes it, but I really wanted
to make it as part of rethinking Web development a bit, and you can see
that I used the DSL only where I got benefit (moving some trivial
computation and checking to syntax expansion time), and I expressly (see
"By design...") avoided doing things like inventing my own declarative
iterators, or reinventing a half-butted Scheme. There are some static
checking things that I can't do this way (e.g., full HTML5 validation),
but it seemed a good tradeoff, and I could always *layer* that crazy
static checking later, if I really wanted to do things like make
declarative language for mapping database results. One DSL decision I
made was to sacrifice the S-expression representation as data accessible
to the programmer, in favor of emphasizing writing the byte stream as
you go (yes, I've seen this get massive, in practice), and also using
normal Racket ports, so that it could be combined with other Racket
ways, for flexibility (again, not reinventing or restricting the
language when it didn't benefit me).
https://www.neilvandyke.org/racket/html-template/
BTW, related, a few places in the list archives, I talk about an
alternative to configuration files, like thinking of the application
instead as a framework, and the configuration file is actually an
instantiation of the framework. And some simple practical startup
mechanics for doing that (e.g., executable that falls back to the
default instantiation if no config file available, and maybe writes a
"config file"). You don't have to do all that way, but you see how this
could be powerful. If you do it right, in a lightweight (in the
developer burden sense) way, and, together with other factors, you could
also encourage an ecosystem and culture of very casual extension of your
application (like was part of what made Emacs so loved and powerful).
--
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.
