[sargstuff]

> " General-purpose languages that are expressive enough to let one write business logic in the language of the domain, but without breaking the rules of the language or requiring new tooling .."

gawk compiled to webassembly would seem to fit the bill -- just shifts gawk from "external" dsl to "internal" dsl. orthogonality allows for usage of all modern interface trappings without any retooling and/or breaking rules of gawk language. Makes gawk a module in group of customized modules to form a general-purpose program out of dsl/little languages.

[lmm]

Transpiling to your main language doesn't make it an internal DSL. Reimplementing what gawk does as a library you can use within your language (and not just by passing opaque strings to it, but by actually expressing awk-style commands in a proper datastructure) is the kind of thing I'm advocating for.

[sargstuff]

Transpiling the language changes the operational domain.

Reimplimenting/supporting the library in language means, have to do that for each OS operational domain that the gawk interpreter runs in (aka each relevant OS & OS version for mac, unix, windows, non-pc OS's, plus mobile versions).

Modifying language also means that anything that relies on lanuage will have to be re-evaluated to assess potential language change issues/implications.

Transpiling to change the operational domain means can just focus on task at hand, as long as not tied to specifics outside the operational domain of webassembly. aka file paths

Avoids the need to assess potential language change issues/implications.

Changing the operation domain in this case means can leverage the operational environments orthononality to 'express awk-style commands in a propper data structures' that awk doesn't provide without modifiying the language. (or writing the feature in awk)

Changing the operation environment also means no required new retooling. Changing the language may force/require retooling.

Case study context example:

Long term 10-40 year studies where same code written at start of study needs to be runnable / usable / understandable at the end of the study without being rewritten.

Note: Hardware and/or OS used at start may be entirely different than that used at end of study.

Fairly simple to get 10,000+ awk scripts running under IBM/DEC/Mac/Windows/Unix/BeOS to run under any of the other OS domains using webassembly by transpiling awk. Fairly trivial to leverage browser to permit a user customizable GUI usable under any of the aformentioned OS domains without having to modify/recertify the awk scripts.

Finding / recompiling / supporting awk for each of those OS domains (OS & verions variants, GUI libs) bit more time consuming (short term & long term).

[sargstuff]

> "... (and not just by passing opaque strings to it, but by actually expressing awk-style commands in a proper datastructure) ..."

Explicit, in language data structures are not a feature at the chomsky language level that traditional awk targeted at, but in-place file block state manipulation can be setup/arranged in a data structure form.

Something like a bnf/ebnf language data structure description would need to be used/processed by an awk script to make use of data structures within an awk script. aka ANI spec in BEGIN section. Something akin to overlaying a script on top of a script and/or printf being passed description of string format.

awk not traditionally set up to do homoiconicity forms within same script instance. (abuse of system call & gawk exentions not withstanding)

[sargstuff]

Add what ARC language provides to mix to get one common customizable reference for html template interface across multiple OS/platforms. (vs. multiple file copies of a html template instance)