Re: Little language design/implementation guidance

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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
For more options, visit https://groups.google.com/d/optout.