"SQL" is not the answer the poster wanted, but arguably the correct one. :D

Transactions do figure into my thoughts about language design, and OS/HCI design in general, but I haven't clarified it enough to talk much about it. I'm also very interested in the community's thoughts here.

Clojure and Haskell with Software Transactional Memory?

The "predict the effect of this code without running this code" aspect of some of the examples runs afoul of the Halting Problem in the general case. 🤷‍♂️

Would multiparty session types fit the bill here?

Appendix

If you want to play along with this experiment, the code is in github.com/guitarvydas/cfunc.

c.ohm

A quickie grammar that matches function declarations in a C file.

Note that this grammar is longer than a REGEX, but, is significantly shorter than a CFG specification (LR(k), YACC, etc.) for the C programming language.

Cfunctions {

  program = item+

  item =

    | comment

    | string

    | applySyntactic<FunctionDecl> -- decl

    | any -- other

  FunctionDecl = name "(" param+ ")" "{" block+ "}"



    param =

      | "(" param+ ")" -- nested

      | ~"(" ~")" any  -- flat



    block =

      | "{" block+ "}" -- nested

      | ~"{" ~"}" any  -- flat



      name = letter (alnum | "_")*

      comment =

        | "//" (~nl any)* nl

        | "/*" (~"*/" any)* "*/"

      string =

        | bqstring

        | dqstring

        | sqstring

      bqstring = "`" (qbq | (~"`" any))* "`"

      dqstring = "\"" (qdq | (~"\"" any))* "\""

      sqstring = "'" (qsq | (~"'" any))* "'"

      qbq = "\\" "`"

      qdq = "\\" "\""

      qsq = "\\" "'"

      nl = "\n"

      spaces += comment

}

Can this grammar be improved and optimized? Probably. But, why would you care?

You would care only if you used this code in an end-user product.

If you use this code in something like a batch-editing environment, “efficiency” takes on a different meaning. End-users don’t care about the efficiency of your code editor and its Find-and-Replace function. End-users don’t care how efficient your command line tools, like grep , are.

When you treat Ohm-JS + Fab as batch editors for development, then, only development efficiency matters.

I strongly believe that one shouldn’t write code. One should write code that writes code. From this perspective, “efficiency” breaks down into 2 camps:

• developer efficiency
• end-user efficiency.

Note that traditional compilers are simply apps that write code. Developers use compilers . End-users don’t care if a developer created end-user app code by hand or by using a compiler. The only things that end-users care about is if the app is cheap and runs on cheap hardware. The final app is assembler, regardless of how it was created. Developers, on the other hand, do care about development time and effort. Hand-writing apps requires much more effort than using high-level language compilers to generate the final app code. Debugging apps is easier when using high-level languages with type-checkers. On the other hand, developers usually buy fancier hardware than that which is used by end-users. Developers can afford to burn CPU cycles on their fancy hardware to give themselves faster - and cheaper - development and debugging times.

The final step in development is that of Production Engineering an app to make it cheap-enough to sell. Up until that point, the development workflow should consist of anything that speeds up and cheapens development time, for example, dynamic language environments and REPLs. For example, Rust is a Production Engineering language and needn’t be used until the last moment.

c.fab

A .fab file is a specification that creates strings based on the above grammar. Fab is an experimental transpiler tool that works with Ohm-JS. It generates JavaScript code required by Ohm-JS. This could all be done by off-the-shelf Ohm-JS. Fab simply reduces the amount of keyboarding needed for creating JavaScript “semantics” code required by Ohm-JS. Fab is written in Ohm-JS.

Cfunctions {

  program [item+] = ‛«item»'

  item_decl [x] =  ‛«x»'

  item_other [x] =  ‛'

  FunctionDecl [name lp param+ rp lb block+ rb] = ‛\n«name»'

    param_nested [lp param+ rp] = ‛'

    param_flat [c] = ‛'

    block_nested [lp block+ rp] = ‛'

    block_flat [c] = ‛'

      name [letter c*] = ‛«letter»«c»'

      comment [begin cs end] = ‛'

      nl [c] =  ‛«c»'

      spaces [cs] =  ‛«cs»'

      bqstring [begin cs* end] = ‛'

      dqstring [begin cs* end] = ‛'

      sqstring [begin cs* end] = ‛'

      qbq [bslash c] = ‛'

      qdq [bslash c] = ‛'

      qsq [bslash c] = ‛'

}

grep.c

The above was tested against grep.c from the Gnu grep repo.

git clone git.savannah.gnu.org/git/grep.git

Even Smaller

I’m playing with the design of a new tool that I call bred (bracket editor). It’s like a super-simple batch editor that walks through text that contains bracketed constructs.

The full specification consists of 2 strings

• what to match
• how to rewrite it.

The above specifications might be re-expressed as:

‛«name» («params») {«block»}'

‛«name»'

which reads as:

• match, recursively, anything that looks like «name» («params») {«block»}
• then, throw away everything except the name

Currently, my concepts have warts - what happens when a comment or a string or a character constant contains brackets, or, even worse, what happens if they contain unmatched brackets?

Nice ideas.

Re 0D, my next question is: how to decide at what granularity to stop using function calls? Or are you suggesting eliminating them entirely?

Re transpiler pipelines: I tried this for a while a few years ago. The conclusion I reached was that they were great for adding capabilities but they can't add restrictions. In first class languages often a lot of value comes from guarantees that certain events won't occur. An int won't be assigned to a string. There you need a single coherent grammar. Does this seem right?

this talk is quite relevant —

youtu.be/JMZLBB_BFNg

... re: 0D ...

ideal: use both, without letting language influence your thinking

ideal: use both, but, remain aware of what each choice accomplishes

ideal: 0D to be so cheap that it could be used on every line of code

reality: 0D is entangled with Multiprocessing and the current grain size is “Process”

alternate reality: 0D can be couched in terms of closures and FIFOs, hence, grain size is “function” (where closure is roughly equivalent to function)

reality: CALL/RETURN and the callstack are hard-wired into CPUs (there used to be a time when CPUs didn’t have hard-wired callstacks)

reality: 1950s IDEs for Programming were Programming Languages, but, in 2022++ IDEs include other stuff, like powerful programming editors

CALL is used for 2 reasons: (1) compacting code size, (2) DRY (Don’t Repeat Yourself). There is no good reason to allow CALL/RETURN to leak into end-user code except for case (1) compacting code size [corollary: case (2) should be entirely optimized away at “compile time” and “edit time”]

x.f(x) is syntax with the meaning “mutate the global callstack and mutate the IP to point at the method function x.f” (and “return” means “put the return value in a special place, then mutate the global callstack, then mutate the IP to point at the caller’s continuation code”)

but, there is no popular builtin syntax for Send()ing to an output queue and passing the finalized output queue back up to the parent Container

... re: transpiler pipelines question ... thinking ...

... re: transpiler pipelines question, progress towards answering the question, WIP ...

... this doesn’t necessarily answer the question, but might show where my thinking is going, while I try to figure out what is really being asked ...

... I think of a PL as 2 issues: (1) data (2) control flow, i.e. (1) operands and (2) syntax ...

... I am playing with Orthogonal Programming Languages, where (1) is OO, (2) is syntax ; based on Cordy’s Orthogonal Code Generator ideas and based on RTL and based on dataless PLs (like Holt’s S/SL (used in PT Pascal, Concurrent Euclid, Turing, etc.)) ...

... I think that dataless languages boils down to 2 entities: (1) Things, (2) Lists of Things. Types are opaque and cannot be defined at the dataless language-level (Types are defined and manipulated in other layers, implemented in common PLs (e.g. Python, C, etc.))

Src

String s

s <- ‘abc’

s <- 7

Gather

$defsynonym (‘s’, ⟨od, kind=var, type=“String”, key=‘s’⟩)

s <- ‘abc’

s <- 7

Normalize

$defsynonym (‘s’, ⟨od-var, “String”, ‘s’⟩)

$Assign s, ⟨od-lit, “String”, ‘abc’⟩

$Assign s, ⟨od-lit, “int”, 7⟩

... same as ...

$Assign ⟨od-var, “String”, ‘s’⟩, ⟨od-lit, “String”, ‘abc’⟩

$Assign ⟨od-var, “String”, ‘s’⟩, ⟨od-lit, “int”, 7⟩

Semantic Check

“String” == “String” --> OK

“String” != “int” --> Error

This looks like simple name equivalence. Lower layers are free to use structural equivalence instead (using names as keys to a map containing more detail for each type).

[The goal here is to think of a compiler as a string of pearls on a pipeline instead of as a honking big tree].

[od - oh-D, not zero-D, means “object descriptor”]