Guix Workflow Language

Post by heavenlyhash » Fri, Jul 12, 2019, 8:02 AM UTC

zmmmmm wrote: post #49

jkh1 wrote: post #11

Earlier quoted context omitted.

but many, if not most, are not domain-specific.

Depends what you mean by that. For example, in the bioinformatics space it's super common to parallelise a workflow over genomic regions and then merge the results. So I use a tool that has a top level construct for that, literally language syntax which makes that both utterly trivial and extremely robust (for example, deals with the annoying problems of edge effects, overlapping regions, trying not to create breaks…

That's a really excellent example -- crossing the regionality information of genomics with an otherwise-basic parallelization problem definitely makes it nontrivial. Thank you :D

Post by chriswarbo » Tue, Jul 16, 2019, 12:33 PM UTC

blunte wrote: post #26

chriswarbo wrote: post #5

Earlier quoted context omitted.

Lisp doesn't need to use s-expressions (i.e. parentheses), that just-so-happens to be the most popular serialisation format. These examples look more like I-expressions to me ( https://srfi.schemers.org/srfi-49/srfi-49.html ); i-expressions and s-expressions are equivalent and can be converted back and forth trivially. Lisps can also support arbitrary input formats using reader macros, so it might be using that (I ha…

But with sexps, if your code suffers some formatting catastrophe (such as all instances of whitespace being reduced to a single space), the sexp code is trivially recoverable/reformattable. Depending on whitespace and indentation creates such fragile code that I can't understand why the trade-off would be made.

If that's a concern then serialise using s-expressions. You can still edit using i-expressions or something equivalent if you like (it's trivial to convert, after all). Code on-disk doesn't need to be the same as code in-editor (for example, syntax highlighting isn't saved to disk either)

Re: Guix Workflow Language

Re: Guix Workflow Language