Re: Preparing for a new release

[Ricardo Wurmus]

zimoun <address@hidden> writes:

> On Mon, 10 Feb 2020 at 07:31, Ricardo Wurmus <address@hidden> wrote:
>> 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.
>
> If I understand correctly, for such cases, 3 solutions:
>
> 1. manually split
>
>  inputs
>    . sample-1: "a"
>    . sample-2: "b"
>    . sample-3: "c"
>
> or 2. split elsewhere 'samples' using piece of Lisp
>
> or 3. use Lisp features
>
>  inputs
>    . sample-1: `(list-ref ,samples 1)
>    . sample-2: `(list-ref ,samples 2)
>    . sample-3: `(list-ref ,samples 3)
>
>
> Right?

That’s correct, but to directly access values in the “inputs” field,
though, you’d have to use a let binding around the definition of the
code snippet, which would be uglier.

So ugly in fact that I decided to write this little procedure:

--8<---------------cut here---------------start------------->8---
;; Simplify access to tagged items in lists.
(define pick
  (case-lambda
    ;; First item.
    ((key collection)
     (and=> (memq key collection) cadr))
    ;; Nth item
    ((n key collection)
     (let ((sub
            (and=> (memq key collection)
                   (lambda (sublist)
                     (break keyword? (cdr sublist))))))
       (cond
        ((number? n)
         (and (> (length sub) n)
              (list-ref sub n)))
        ;; All items
        ((and (procedure? n)
              (eq? (procedure-name n) '*))
         sub)
        ;; SRFI-1 accessors like "first"
        ((procedure? n)
         (n sub))
        (else (error "pick: Selector not supported.")))))))
--8<---------------cut here---------------end--------------->8---

Then I noticed that it’s really inconvenient to use let bindings inside
of fields, so I changed the “make-process” macro to allow for
definitions inside of the fields of a process.

So you can do this now:

--8<---------------cut here---------------start------------->8---
process foo
  inputs
    . "something"
    . samples: "a" "b" "c"
  procedure
    define second-sample
      pick second samples: inputs
    . # { echo {{second-sample}} }
--8<---------------cut here---------------end--------------->8---

Unfortunately, the leading dot sticks out like a wart here.  We could
only drop it if I manage to rewrite the code-snippet value so that it
really is a procedure that will return itself when applied to zero
arguments…  It might be possible with some tinkering.

(Note that you do need the “procedure” field name here; it can be left
off only when the last value is a code-snippet.)

--
Ricardo