gwl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Preparing for a new release


From: Ricardo Wurmus
Subject: Re: Preparing for a new release
Date: Mon, 10 Feb 2020 07:31:45 +0100
User-agent: mu4e 1.2.0; emacs 26.3

zimoun <address@hidden> writes:

>> * It’s not possible to select more than one tagged item
>>
>>   In my test workflow I’m generating a bunch of inputs by mapping over
>>   an argument list.  Now the problem is that I can’t select all of these
>>   inputs easily in a code snippet.  With the syntax we have I can only
>>   select the first item following a tag.
>>
>>   To address this I’ve extended the accessor syntax, so this works now:
>>
>> --8<---------------cut here---------------start------------->8---
>> process frobnicate
>>   packages "frobnicator"
>>   inputs
>>     . genome: "hg19.fa"
>>     . samples: "a" "b" "c"
>>   outputs
>>     . "result"
>>   # {
>>     frobnicate -g {{inputs:genome}} --files {{inputs::samples}} > {{outputs}}
>>   }
>> --8<---------------cut here---------------end--------------->8---
>>
>>   Note how {{inputs::samples}} is substituted with “a b c”.  With just a
>>   single colon it would be just “a”.  Single colon = single item; double
>>   colon = more than one item.
>
> I am confused by the syntax.
> Well how to select the second element "b"?
>
> Naively, I would tempt to write {{inputs:samples:2}} or {{inputs::samples:2}}.

There’s no syntax for that because you can use good ol’ list processing
(let’s call it “Listp”, or perhaps “Lisp”…) to work on this outside of
the code snippet.

To me these two cases — accessing a single item and accessing multiple
items — are just really common enough to deserve their own syntax,
especially because the plain Scheme way to do this is rather dense:

   (and=> (memq inputs #:hello) cadr)

and

   (and=> (memq inputs #:hello)
          (lambda (sublist)
            (break keyword? (cdr sublist))))

I wouldn’t want to see bioinformaticians paste these kind of things all
over the place.

My hope is that in-list access is much less common and could either be
rewritten to place the item of interest in the first place, or could be
solved with a let binding.

--
Ricardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]