Re: Do people build things using little languages any more?

Kaz Kylheku <480-992-1380@kylheku.com>
Tue, 5 Jul 2022 01:57:27 -0000 (UTC)

          From comp.compilers

Related articles
Do people build things using little languages any more? costello@mitre.org (Roger L Costello) (2022-07-04)
Re: Do people build things using little languages any more? 480-992-1380@kylheku.com (Kaz Kylheku) (2022-07-05)
| List of all articles for this month |
From: Kaz Kylheku <480-992-1380@kylheku.com>
Newsgroups: comp.compilers
Date: Tue, 5 Jul 2022 01:57:27 -0000 (UTC)
Organization: A noiseless patient Spider
References: 22-07-002
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="53679"; mail-complaints-to="abuse@iecc.com"
Keywords: design
Posted-Date: 05 Jul 2022 10:43:52 EDT

On 2022-07-04, Roger L Costello <costello@mitre.org> wrote:
> Hi Folks,
>
> I am reading the "Little Languages and Tools" book. (I can't remember who, on
> this list, recommended the book, but whoever it was thank you! It is an
> awesome book!)
>
> The first chapter was written by Jon Bentley. Incredible writer! The thing
> that struck me most from reading his chapter is that writing little tools
> (using little languages such as AWK, Lex, Yacc, pic (picture language),
> scatter (scatter plot language), troff, sed) and then assembling them together
> via pipes, e.g.,
>
> scatter infile | pic | troff >outfile


The problem with this is that, for instance, I can't use a clever
troff macro to generate input foir scatter or pic, because they
are earlier in the pipeline. Unless maybe I cob together some
sort of multi-pass hack.


The Lisp macro approach for small domain languages is superior;
all macros are expanded by the same code walker, and can nest
with each other.


Pipes are wasteful; everything has to convert to the character level and
be sent to the operating system (several buffer copies), and then
lexically analyzed again.


How pic should have been designed is not as a separate pipeline element
that just recognizes some pic commands and produces "pic-free" output
fed to troff, but as a utility program which provides services invoked
by a package of pic macros executed by troff.


Like say you just want something simple, like use troff's .if/.el to
conditionally select a picture. Because pic runs first, it will be
oblivious to the conditional and wastefully process the picture
specification in both branches.


That might even be a nonstarter: say that you want the pic code to
refer to some files, but only the files for the taken branch of the
.if/.el actually exist.


Speaking of macros, pic wastefully implements its own macro language,
and one which is quite different from the troff one.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.