unofficial mirror of gwl-devel@gnu.org
 help / color / mirror / Atom feed
From: Roel Janssen <roel@gnu.org>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: gwl-devel@gnu.org
Subject: Re: Comments on process template syntax
Date: Mon, 03 Feb 2020 13:56:38 +0100	[thread overview]
Message-ID: <6be1d411b6caab4e91b67fd24bde5095afb65bc5.camel@gnu.org> (raw)
In-Reply-To: <87lfpjswla.fsf@elephly.net>

On Mon, 2020-02-03 at 13:07 +0100, Ricardo Wurmus wrote:
> Hi Roel,
> 
> > On Sun, 2020-02-02 at 11:20 +0100, Ricardo Wurmus wrote:
> > > Hi,
> > > 
> > > While looking at the examples at
> > > https://www.guixwl.org/beyond-started,
> > > I found that process templates might be difficult to understand,
> > > and
> > > that they have no pretty syntax.
> > > 
> > > --8<---------------cut here---------------start------------->8---
> > > process: (list-file-template filename)
> > >   name
> > >     string-append "list-file-"
> > >                   basename filename
> > >   packages "gzip"
> > >   inputs filename
> > >   outputs
> > >     string-append filename ".list"
> > >   run-time
> > >     complexity
> > >       space 20 mebibytes
> > >       time  30 seconds
> > >   # { gzip --list {{inputs}} > {{outputs}} }
> > > --8<---------------cut here---------------end--------------->8---
> > > 
> > > The first line is easy to understand for lispers but it might
> > > look
> > > weird
> > > to people who come from other workflow languages or programming
> > > languages.  This describes a procedure called “list-file-
> > > template”
> > > that
> > > returns a process parameterized on the argument “filename”.
> > > 
> > > Nextflow has no concept of procedures that produce processes when
> > > given
> > > arguments.  It does however have a concept of data streams that
> > > can
> > > be
> > > fed into processes, which results in a process to be instantiated
> > > for
> > > every element of the stream.  The stream may be created from a
> > > directory
> > > containing files.
> > > 
> > > This implementation likely stems from the realization that the
> > > “template
> > > case” is the most common case for processes.  Rarely ever is it
> > > necessary to define a process that does *not* require
> > > parameterization
> > > on its inputs.
> > > 
> > > Can we make the common case simpler and easier to understand?
> > 
> > Perhaps with some parentheses?  That it is a Lisp is a good thing,
> > not
> > something you'd rather hide.. :)  Like you've said; what you've
> > defined
> > above is a procedure, not a record.  That's a really cool "feature"
> > of
> > the GWL!
> 
> I agree.  I wouldn’t want to hide it e.g. by somehow “inferring”
> procedure inputs via the inputs field.  I think it’s good that it
> closely resembles a procedure, because that’s what it is.
> 
> I still think that the syntax is sub-optimal.  We support Wisp to
> make the Lispiness a little easier to swallow for the skeptics.  But
> the procedure case does not benefit much from Wisp — it would look
> worse
> if we expressed it in the Wisp way:
> 
>     process : list-file-template filename
> 
> Note the space between “process” and the remainder.  It would be
> wrong
> to remove the space after “process”.  That’s a pitfall stemming from
> a
> familiarity with YAML that I’d rather avoid.  (That’s why I want to
> rename “process:” and “workflow:”.)
> 
> The only reason why I know how to use “:” is because I know that I
> want
> the remainder to be wrapped in parentheses…  People who only know the
> sugary syntax would not have that knowledge and it would just seem
> like
> an arbitrary thing.
> 
> The confusion disappears in my opinion when the colon does not follow
> the first word.
> 
>     process list-file-template : filename
>       name …
>       inputs …
>       outputs …
> 
> or when the colon is avoided altogether:
> 
>     process list-file-template (filename)
>       name …
>       inputs …
>       outputs …
> 
> or in Lispy syntax
> 
>     (process list-file-template (filename)
>       (name …)
>       (inputs …)
>       (outputs …))
> 

Ha! This one is confusing me! :)

> Having a list of identifiers after the name of the procedure matches
> Common Lisp and C-style languages.  I think it looks less confusing
> as
> the difference between the “template case” and the “record case”
> becomes
> merely a parenthetical list of free variables.
> 
> What do you think?  This can be accomplished with a tiny change to
> the
> “process” macro in (gwl sugar).

I think the C(L)-style syntax looks good and clear.  It's also easy to
explain as you said by "merely adding a perenthetical list of free
variables".

May I suggest one other thing?  Maybe I don't grasp Wisp at all, but
why not:

  process: list-file-template (filename)
    name …
    inputs …
    outputs …

  process: list-some-file.txt
    inputs some-file.txt
    outputs …

Is this harder to implement due to the Wisp->Lisp reading?

Kind regards,
Roel Janssen

  reply	other threads:[~2020-02-03 12:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-02 10:20 Comments on process template syntax Ricardo Wurmus
2020-02-02 23:30 ` Kyle Meyer
2020-02-03  8:08   ` Ricardo Wurmus
2020-02-03 14:22     ` Kyle Meyer
2020-02-03 15:23       ` Ricardo Wurmus
2020-02-03 23:16         ` Kyle Meyer
2020-02-04  9:55           ` Ricardo Wurmus
2020-02-05  1:48             ` Kyle Meyer
2020-02-05 15:14               ` zimoun
2020-02-03  8:58 ` Roel Janssen
2020-02-03 12:07   ` Ricardo Wurmus
2020-02-03 12:56     ` Roel Janssen [this message]
2020-02-03 14:33       ` Ricardo Wurmus
2020-02-04 10:10         ` Ricardo Wurmus
2020-02-05  2:12           ` Kyle Meyer
2020-02-05 15:21           ` zimoun
2020-02-05 15:29             ` Kyle Meyer
2020-02-05 15:37               ` zimoun
2020-02-05 16:02                 ` Kyle Meyer
2020-02-05 16:23                   ` zimoun
2020-02-05 15:07     ` zimoun
2020-02-05 18:04       ` Ricardo Wurmus
2020-02-05 19:14         ` zimoun
2020-02-05 21:32           ` Ricardo Wurmus
2020-02-06 11:59             ` zimoun
2020-02-05 14:56   ` zimoun
2020-02-08 12:34     ` Ricardo Wurmus
2020-02-05 14:50 ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.guixwl.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6be1d411b6caab4e91b67fd24bde5095afb65bc5.camel@gnu.org \
    --to=roel@gnu.org \
    --cc=gwl-devel@gnu.org \
    --cc=rekado@elephly.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).