unofficial mirror of gwl-devel@gnu.org
 help / color / Atom feed
* Comments on process template syntax
@ 2020-02-02 10:20 Ricardo Wurmus
  2020-02-02 23:30 ` Kyle Meyer
                   ` (2 more replies)
  0 siblings, 3 replies; 28+ messages in thread
From: Ricardo Wurmus @ 2020-02-02 10:20 UTC (permalink / raw)
  To: gwl-devel

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?  (FWIW, I
intend to rename the “process:” macro to just “process” to remove
confusing syntactic noise, so anything about the first line may be
changed.)

--
Ricardo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  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  8:58 ` Roel Janssen
  2020-02-05 14:50 ` zimoun
  2 siblings, 1 reply; 28+ messages in thread
From: Kyle Meyer @ 2020-02-02 23:30 UTC (permalink / raw)
  To: Ricardo Wurmus, gwl-devel

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

> 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.  [...]

Yeah, I agree that first line could be the source of a good amount of
head scratching, though I can't think of a better alternative.  (Then
again, one of the more superficial reasons I like the idea of GWL is the
ability to write in lisp, so I'm probably lacking vision/motivation.)

> (FWIW, I intend to rename the “process:” macro to just “process” to
> remove confusing syntactic noise, so anything about the first line may
> be changed.)

Hmm, but wouldn't that conflict with the `process' constructor defined
in gwl/processes.scm?

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-02 23:30 ` Kyle Meyer
@ 2020-02-03  8:08   ` Ricardo Wurmus
  2020-02-03 14:22     ` Kyle Meyer
  0 siblings, 1 reply; 28+ messages in thread
From: Ricardo Wurmus @ 2020-02-03  8:08 UTC (permalink / raw)
  To: Kyle Meyer; +Cc: gwl-devel


Kyle Meyer <kyle@kyleam.com> writes:

>> (FWIW, I intend to rename the “process:” macro to just “process” to
>> remove confusing syntactic noise, so anything about the first line may
>> be changed.)
>
> Hmm, but wouldn't that conflict with the `process' constructor defined
> in gwl/processes.scm?

Yes, that would need to be renamed as well.

-- 
Ricardo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-02 10:20 Comments on process template syntax Ricardo Wurmus
  2020-02-02 23:30 ` Kyle Meyer
@ 2020-02-03  8:58 ` Roel Janssen
  2020-02-03 12:07   ` Ricardo Wurmus
  2020-02-05 14:56   ` zimoun
  2020-02-05 14:50 ` zimoun
  2 siblings, 2 replies; 28+ messages in thread
From: Roel Janssen @ 2020-02-03  8:58 UTC (permalink / raw)
  To: Ricardo Wurmus, gwl-devel

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!

Maybe we can just clarify the feature better in the documentation. 
Here's my initial thought:
---
When defining processes, they can be parameterized by turning the
process definition into a procedure, which will form a template for
processes to be defined later.  This is done by adding a name for the
template, and its parameters directly after "process:".
---

Kind regards,
Roel Janssen

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-03  8:58 ` Roel Janssen
@ 2020-02-03 12:07   ` Ricardo Wurmus
  2020-02-03 12:56     ` Roel Janssen
  2020-02-05 15:07     ` zimoun
  2020-02-05 14:56   ` zimoun
  1 sibling, 2 replies; 28+ messages in thread
From: Ricardo Wurmus @ 2020-02-03 12:07 UTC (permalink / raw)
  To: Roel Janssen; +Cc: gwl-devel


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 …))

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).

> Maybe we can just clarify the feature better in the documentation.
> Here's my initial thought:
> ---
> When defining processes, they can be parameterized by turning the
> process definition into a procedure, which will form a template for
> processes to be defined later.  This is done by adding a name for the
> template, and its parameters directly after "process:".
> ---

I agree that emphasizing this in the manual is a good idea.

--
Ricardo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-03 12:07   ` Ricardo Wurmus
@ 2020-02-03 12:56     ` Roel Janssen
  2020-02-03 14:33       ` Ricardo Wurmus
  2020-02-05 15:07     ` zimoun
  1 sibling, 1 reply; 28+ messages in thread
From: Roel Janssen @ 2020-02-03 12:56 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-03  8:08   ` Ricardo Wurmus
@ 2020-02-03 14:22     ` Kyle Meyer
  2020-02-03 15:23       ` Ricardo Wurmus
  0 siblings, 1 reply; 28+ messages in thread
From: Kyle Meyer @ 2020-02-03 14:22 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel

Ricardo Wurmus <rekado@elephly.net> writes:

> Kyle Meyer <kyle@kyleam.com> writes:
>
>>> (FWIW, I intend to rename the “process:” macro to just “process” to
>>> remove confusing syntactic noise, so anything about the first line may
>>> be changed.)
>>
>> Hmm, but wouldn't that conflict with the `process' constructor defined
>> in gwl/processes.scm?
>
> Yes, that would need to be renamed as well.

But then it's not just about syntactic sugar that helps the wisp end of
things.  The changes are affecting how things have to be written at the
scheme level.  While I understand your reasoning for offering the wisp
syntax as an alternative, it seems problematic to me if a desire to
improve readability of the wisp syntax requires changes to how things
are written on the scheme end.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-03 12:56     ` Roel Janssen
@ 2020-02-03 14:33       ` Ricardo Wurmus
  2020-02-04 10:10         ` Ricardo Wurmus
  0 siblings, 1 reply; 28+ messages in thread
From: Ricardo Wurmus @ 2020-02-03 14:33 UTC (permalink / raw)
  To: Roel Janssen; +Cc: gwl-devel


Roel Janssen <roel@gnu.org> writes:

> 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 …

I don’t see how this differs from what I suggested… other than the
renaming of “process:” to “process”.

Let’s ignore the name of that macro and go with “process:”.  Currently,
you’d write it as

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

or for the concrete case:

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

There’s little here that’s Wisp specific.  It translates to this Scheme
code:

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

and

  (process: list-some-file.txt
    (inputs "some-file.txt")
    (outputs …))

The macro “process:” just expands these things to

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

and

  (define-public list-some-file.txt
    (process
      (name "list-some-file.txt")
      (inputs "some-file.txt")
      (outputs …)))

[[
Now, “process” is actually a macro that performs a few more convenient
transformations, such as wrapping inputs in a list and all that, and it
then creates an instance of the GOOPS class <process> by doing

    (make <process> …)

where “…” stands for sanitized arguments.  Not important for this
discussion, though.
]]

I’m proposing two things:

1) get rid of the “:” in the macro name because it could be confused for
syntax — both for the Wisp “:” that means “wrap this in parens” and for
SRFI-88 style keywords.  Rename the lower level “process” and “workflow”
macros — those that are wrappers around “(make <process> …)” and “(make
<workflow> …)” — to “make-process” and “make-workflow”, respectively, to
avoid naming conflicts.

2) move the procedure name outside of the parentheses when using the
“process” (formerly “process:”) macro.

This means that the examples above would be written as

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

and

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

It’s a pretty small change, but I think it reduces the potential for
confusion and removes unnecessary characters (the colon).

--
Ricardo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-03 14:22     ` Kyle Meyer
@ 2020-02-03 15:23       ` Ricardo Wurmus
  2020-02-03 23:16         ` Kyle Meyer
  0 siblings, 1 reply; 28+ messages in thread
From: Ricardo Wurmus @ 2020-02-03 15:23 UTC (permalink / raw)
  To: Kyle Meyer; +Cc: gwl-devel


Kyle Meyer <kyle@kyleam.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Kyle Meyer <kyle@kyleam.com> writes:
>>
>>>> (FWIW, I intend to rename the “process:” macro to just “process” to
>>>> remove confusing syntactic noise, so anything about the first line may
>>>> be changed.)
>>>
>>> Hmm, but wouldn't that conflict with the `process' constructor defined
>>> in gwl/processes.scm?
>>
>> Yes, that would need to be renamed as well.
>
> But then it's not just about syntactic sugar that helps the wisp end of
> things.  The changes are affecting how things have to be written at the
> scheme level.  While I understand your reasoning for offering the wisp
> syntax as an alternative, it seems problematic to me if a desire to
> improve readability of the wisp syntax requires changes to how things
> are written on the scheme end.

I suppose the correct way would be to rename “process:” to
“define-process” and “workflow:” to “define-workflow” and to leave
“process” and “workflow” unchanged.  Because “process:” does define a
variable that’s bound to a “process” value.

I just find “define-process” and “define-workflow” really clunky :-/

It would be possible to use the very same macro name and simply rename
things when (gwl sugar) is imported, and perhaps to import (gwl sugar)
only by default when the workflow is written in Wisp.  Currently (gwl
sugar) is always imported in the evaluation environment of any workflow.

Does this sound better?

--
Ricardo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-03 15:23       ` Ricardo Wurmus
@ 2020-02-03 23:16         ` Kyle Meyer
  2020-02-04  9:55           ` Ricardo Wurmus
  0 siblings, 1 reply; 28+ messages in thread
From: Kyle Meyer @ 2020-02-03 23:16 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel

Ricardo Wurmus <rekado@elephly.net> writes:

> Kyle Meyer <kyle@kyleam.com> writes:

>> But then it's not just about syntactic sugar that helps the wisp end of
>> things.  The changes are affecting how things have to be written at the
>> scheme level.  While I understand your reasoning for offering the wisp
>> syntax as an alternative, it seems problematic to me if a desire to
>> improve readability of the wisp syntax requires changes to how things
>> are written on the scheme end.
>
> I suppose the correct way would be to rename “process:” to
> “define-process” and “workflow:” to “define-workflow” and to leave
> “process” and “workflow” unchanged.  Because “process:” does define a
> variable that’s bound to a “process” value.
>
> I just find “define-process” and “define-workflow” really clunky :-/

Ha, I was actually thinking those sounded pretty good.  Oh well :>

> It would be possible to use the very same macro name and simply rename
> things when (gwl sugar) is imported, and perhaps to import (gwl sugar)
> only by default when the workflow is written in Wisp.  Currently (gwl
> sugar) is always imported in the evaluation environment of any workflow.
>
> Does this sound better?

Hmm, I'm worried that using the same name could be the source of
confusion.

Anyway, thinking about this more, I suppose the issue I raised about
renaming `process' shouldn't really be a concern (at this point in GWL's
development) and the s/process/make-process/, s/process:/process/
suggestion you made elsewhere in this thread sounds fine.

Thanks for thinking about how to make the Wisp syntax clearer here (and
for considering my objection).

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-03 23:16         ` Kyle Meyer
@ 2020-02-04  9:55           ` Ricardo Wurmus
  2020-02-05  1:48             ` Kyle Meyer
  0 siblings, 1 reply; 28+ messages in thread
From: Ricardo Wurmus @ 2020-02-04  9:55 UTC (permalink / raw)
  To: Kyle Meyer; +Cc: gwl-devel


Kyle Meyer <kyle@kyleam.com> writes:

>> It would be possible to use the very same macro name and simply rename
>> things when (gwl sugar) is imported, and perhaps to import (gwl sugar)
>> only by default when the workflow is written in Wisp.  Currently (gwl
>> sugar) is always imported in the evaluation environment of any workflow.
>>
>> Does this sound better?
>
> Hmm, I'm worried that using the same name could be the source of
> confusion.

It should not cause confusion because the sugary syntax is used to
replace the lower level syntax.  When using Wisp the syntax is made a
little slimmer so that no definitions are required.  The audience for
whom Wisp support is provided probably prefers simpler syntax, whereas
those who are okay with S-expressions would not mind to use (define this
(process …)).  …and if they do they can load up a replacement with
(import (gwl sugar process)).

I also think it’s a good idea generally to break up the (gwl sugar)
module, so that Scheme users can pick those syntactic features that they
want with more granularity (and without having to select individual
definitions from a single (gwl sugar) module).

--
Ricardo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  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
  0 siblings, 2 replies; 28+ messages in thread
From: Ricardo Wurmus @ 2020-02-04 10:10 UTC (permalink / raw)
  To: Roel Janssen; +Cc: gwl-devel


Ricardo Wurmus <rekado@elephly.net> writes:

> This means that the examples above would be written as
>
>   process list-file-template (filename)
>     name …
>     inputs …
>     outputs …
[…]

I just realized that this is not easily accomplished without warts.  The
reason is that we have no way of distinguishing this

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

from that

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

or worse

   (process list-file-template
     (name foo bar)
     (name …)
     (inputs …)
     (outputs …))

Is this a process definition with two “name” fields?

Or what about this:

   (process list-file-template
     (name some-variable-name)
     (inputs …)
     (outputs …))

Is this a process template with two arguments “name” and
“some-variable-name”, or is this a process with a name field whose value
is whatever “some-variable-name” evaluates to?  The power of macros only
gets us that far.  Sure we could add even more heuristics and check
whether things in the first position are identifiers and such, but this
sounds terribly complex.

This can all be avoided with a tad more syntax, but it’s slightly less
elegant:

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

This is obviously a template because it uses “with” followed by a list
of arguments.

Other ways of writing this in Wisp:

   process list-file-template
     with filename
     name …
     inputs …
     outputs …

or

   process list-file-template : with filename
     name …
     inputs …
     outputs …

Without (gwl sugar process) you can, of course, still write good ol’
procedures explicitly if you prefer, so all of this is optional:

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

Thoughts?

--
Ricardo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-04  9:55           ` Ricardo Wurmus
@ 2020-02-05  1:48             ` Kyle Meyer
  2020-02-05 15:14               ` zimoun
  0 siblings, 1 reply; 28+ messages in thread
From: Kyle Meyer @ 2020-02-05  1:48 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel

Ricardo Wurmus <rekado@elephly.net> writes:

> Kyle Meyer <kyle@kyleam.com> writes:
>
>>> It would be possible to use the very same macro name and simply rename
>>> things when (gwl sugar) is imported, and perhaps to import (gwl sugar)
>>> only by default when the workflow is written in Wisp.  Currently (gwl
>>> sugar) is always imported in the evaluation environment of any workflow.
>>>
>>> Does this sound better?
>>
>> Hmm, I'm worried that using the same name could be the source of
>> confusion.
>
> It should not cause confusion because the sugary syntax is used to
> replace the lower level syntax.  When using Wisp the syntax is made a
> little slimmer so that no definitions are required.  The audience for
> whom Wisp support is provided probably prefers simpler syntax, whereas
> those who are okay with S-expressions would not mind to use (define this
> (process …)).  …and if they do they can load up a replacement with
> (import (gwl sugar process)).

Perhaps.  I still have the feeling that sharing the same name is risking
confusion.  In particular, the fact that how 'process' should be used
depends on an import could make it harder for (1) those trying to learn
the workflow language by looking at and comparing Scheme examples from
various sources and (2) those trying to understand how Wisp maps to
Scheme.

> I also think it’s a good idea generally to break up the (gwl sugar)
> module, so that Scheme users can pick those syntactic features that they
> want with more granularity (and without having to select individual
> definitions from a single (gwl sugar) module).

Yes, sounds like a good idea to me too.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-04 10:10         ` Ricardo Wurmus
@ 2020-02-05  2:12           ` Kyle Meyer
  2020-02-05 15:21           ` zimoun
  1 sibling, 0 replies; 28+ messages in thread
From: Kyle Meyer @ 2020-02-05  2:12 UTC (permalink / raw)
  To: Ricardo Wurmus, Roel Janssen; +Cc: gwl-devel

Ricardo Wurmus <rekado@elephly.net> writes:

> I just realized that this is not easily accomplished without warts.  The
> reason is that we have no way of distinguishing this
> [...]
> Or what about this:
>
>    (process list-file-template
>      (name some-variable-name)
>      (inputs …)
>      (outputs …))
>
> Is this a process template with two arguments “name” and
> “some-variable-name”, or is this a process with a name field whose value
> is whatever “some-variable-name” evaluates to?  The power of macros only
> gets us that far.  Sure we could add even more heuristics and check
> whether things in the first position are identifiers and such, but this
> sounds terribly complex.
>
> This can all be avoided with a tad more syntax, but it’s slightly less
> elegant:
>
>    process list-file-template (with filename)
>      name …
>      inputs …
>      outputs …
>
> [...]
>
> Thoughts?

I agree that using an identifier seems like the best solution.  I
suppose there's also the question of which word to use.  "with" seems
like a good choice to me.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-02 10:20 Comments on process template syntax Ricardo Wurmus
  2020-02-02 23:30 ` Kyle Meyer
  2020-02-03  8:58 ` Roel Janssen
@ 2020-02-05 14:50 ` zimoun
  2 siblings, 0 replies; 28+ messages in thread
From: zimoun @ 2020-02-05 14:50 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel

Hi Ricardo,

On Sun, 2 Feb 2020 at 11:20, Ricardo Wurmus <rekado@elephly.net> wrote:

> process: (list-file-template filename)

[...]

> 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”.

As you probably know, I am working in a Core Facilities Lab so I am
talking with different profiles of potential users. Based on that it
does not appear to me "weird" because it is "syntax". I mean using
Snakemake, the user has to put <tab>, or semi-colon after 'rule', etc.


> Can we make the common case simpler and easier to understand?  (FWIW, I
> intend to rename the “process:” macro to just “process” to remove
> confusing syntactic noise, so anything about the first line may be
> changed.)

I do not have a strong opinion on the subject. :-)


All the best,
simon

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-03  8:58 ` Roel Janssen
  2020-02-03 12:07   ` Ricardo Wurmus
@ 2020-02-05 14:56   ` zimoun
  2020-02-08 12:34     ` Ricardo Wurmus
  1 sibling, 1 reply; 28+ messages in thread
From: zimoun @ 2020-02-05 14:56 UTC (permalink / raw)
  To: Roel Janssen; +Cc: gwl-devel

Hi,

On Mon, 3 Feb 2020 at 09:58, Roel Janssen <roel@gnu.org> wrote:

> 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!

It is one of the feature I was interested in when I started to look at
GWL: be able to define procedure. For example, it is possible with
Snakemake because it is Python; but it is not convenient to define a
function that returns a 'rule'. Well, when I write "workflow", I am
always tempted to do "(map proc list)" with 'proc' generating (or
manipulating) "processes" (or other).


> Maybe we can just clarify the feature better in the documentation.
> Here's my initial thought:
> ---
> When defining processes, they can be parameterized by turning the
> process definition into a procedure, which will form a template for
> processes to be defined later.  This is done by adding a name for the
> template, and its parameters directly after "process:".
> ---

I agree.


All the best,
simon

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-03 12:07   ` Ricardo Wurmus
  2020-02-03 12:56     ` Roel Janssen
@ 2020-02-05 15:07     ` zimoun
  2020-02-05 18:04       ` Ricardo Wurmus
  1 sibling, 1 reply; 28+ messages in thread
From: zimoun @ 2020-02-05 15:07 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel

Hi Ricardo,

On Mon, 3 Feb 2020 at 13:08, Ricardo Wurmus <rekado@elephly.net> wrote:

> 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:”.)

Does it make sense to expand "process: proc arg" as "process : proc arg"?
Well, disallow the colon ':' in all the name (symbol) and then expand.

Because this space is a drawback of Wisp, I mean at least to me.
Especially coming from Python where the standard is to have "def
proc(arg):" and not "def proc(arg) :".


> 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.

Yes exactly.
To place the Wisp sugary syntax, each time I am going back to Scheme,
think where are the opening/closing parenthesis and then adapt the
sugar.


>     process list-file-template : filename

I would be tempted to write without the space.

     process list-file-template: filename


>     process list-file-template (filename)

I find this one the clearer.



All the best,
simon

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-05  1:48             ` Kyle Meyer
@ 2020-02-05 15:14               ` zimoun
  0 siblings, 0 replies; 28+ messages in thread
From: zimoun @ 2020-02-05 15:14 UTC (permalink / raw)
  To: Kyle Meyer; +Cc: Ricardo Wurmus, gwl-devel

Hi,

On Wed, 5 Feb 2020 at 02:48, Kyle Meyer <kyle@kyleam.com> wrote:
>
> Ricardo Wurmus <rekado@elephly.net> writes:
>
> > Kyle Meyer <kyle@kyleam.com> writes:
> >
> >>> It would be possible to use the very same macro name and simply rename
> >>> things when (gwl sugar) is imported, and perhaps to import (gwl sugar)
> >>> only by default when the workflow is written in Wisp.  Currently (gwl
> >>> sugar) is always imported in the evaluation environment of any workflow.
> >>>
> >>> Does this sound better?
> >>
> >> Hmm, I'm worried that using the same name could be the source of
> >> confusion.
> >
> > It should not cause confusion because the sugary syntax is used to
> > replace the lower level syntax.  When using Wisp the syntax is made a
> > little slimmer so that no definitions are required.  The audience for
> > whom Wisp support is provided probably prefers simpler syntax, whereas
> > those who are okay with S-expressions would not mind to use (define this
> > (process …)).  …and if they do they can load up a replacement with
> > (import (gwl sugar process)).
>
> Perhaps.  I still have the feeling that sharing the same name is risking
> confusion.  In particular, the fact that how 'process' should be used
> depends on an import could make it harder for (1) those trying to learn
> the workflow language by looking at and comparing Scheme examples from
> various sources and (2) those trying to understand how Wisp maps to
> Scheme.

I agree with Kyle.

The first step from Wisp to Scheme should be only learn where to place
the parenthesis, IMHO.


All the best,
simon

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  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
  1 sibling, 1 reply; 28+ messages in thread
From: zimoun @ 2020-02-05 15:21 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel

Hi Ricardo,

On Tue, 4 Feb 2020 at 11:12, Ricardo Wurmus <rekado@elephly.net> wrote:

If I understand correctly, you are proposing this sugar:

1.
>    process list-file-template (with filename)

2.
>    process list-file-template
>      with filename

3.
>    process list-file-template : with filename


The 1. and 2. appear to me nicer that the 3..

As I said, I am not a fan of colon ':' extra space.
And it is counterintuitive with plain regular English: the rule is
"word: space" and not "word space : space".
(Note that it is not the case in French where the rule is "word
half-space : space".)


Cheers,
simon

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-05 15:21           ` zimoun
@ 2020-02-05 15:29             ` Kyle Meyer
  2020-02-05 15:37               ` zimoun
  0 siblings, 1 reply; 28+ messages in thread
From: Kyle Meyer @ 2020-02-05 15:29 UTC (permalink / raw)
  To: zimoun, Ricardo Wurmus; +Cc: gwl-devel

zimoun <zimon.toutoune@gmail.com> writes:

> Hi Ricardo,
>
> On Tue, 4 Feb 2020 at 11:12, Ricardo Wurmus <rekado@elephly.net> wrote:
>
> If I understand correctly, you are proposing this sugar:
>
> 1.
>>    process list-file-template (with filename)
>
> 2.
>>    process list-file-template
>>      with filename
>
> 3.
>>    process list-file-template : with filename
>
>
> The 1. and 2. appear to me nicer that the 3..
>
> As I said, I am not a fan of colon ':' extra space.
> And it is counterintuitive with plain regular English: the rule is
> "word: space" and not "word space : space".
> (Note that it is not the case in French where the rule is "word
> half-space : space".)

Those are just different ways you can write the same thing in Wisp:

Feeding this

--8<---------------cut here---------------start------------->8---
process list-file-template (with filename)

process list-file-template
  with filename

process list-file-template : with filename
--8<---------------cut here---------------end--------------->8---

to wisp2lisp gives:

  (process list-file-template (with filename))
  
  (process list-file-template
    (with filename))
  
  (process list-file-template (with filename))

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-05 15:29             ` Kyle Meyer
@ 2020-02-05 15:37               ` zimoun
  2020-02-05 16:02                 ` Kyle Meyer
  0 siblings, 1 reply; 28+ messages in thread
From: zimoun @ 2020-02-05 15:37 UTC (permalink / raw)
  To: Kyle Meyer; +Cc: Ricardo Wurmus, gwl-devel

Hi Kyle,

On Wed, 5 Feb 2020 at 16:29, Kyle Meyer <kyle@kyleam.com> wrote:

> > 1.
> >>    process list-file-template (with filename)
> >
> > 2.
> >>    process list-file-template
> >>      with filename
> >
> > 3.
> >>    process list-file-template : with filename

> Those are just different ways you can write the same thing in Wisp:

I agree.

(aside the fact that I personally do not like the colon ':')

But the macrology sugar will not expand as Wisp does, if I have
understood correctly, i.e., the expansion will be

>   (process list-file-template (filename))

The 'with' is sugar to specify the arguments and avoid all the
ambiguous examples.


All the best,
simon

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-05 15:37               ` zimoun
@ 2020-02-05 16:02                 ` Kyle Meyer
  2020-02-05 16:23                   ` zimoun
  0 siblings, 1 reply; 28+ messages in thread
From: Kyle Meyer @ 2020-02-05 16:02 UTC (permalink / raw)
  To: zimoun; +Cc: Ricardo Wurmus, gwl-devel

zimoun <zimon.toutoune@gmail.com> writes:

> On Wed, 5 Feb 2020 at 16:29, Kyle Meyer <kyle@kyleam.com> wrote:
>> Those are just different ways you can write the same thing in Wisp:
>
> I agree.
>
> (aside the fact that I personally do not like the colon ':')
>
> But the macrology sugar will not expand as Wisp does, if I have
> understood correctly, i.e., the expansion will be
>
>>   (process list-file-template (filename))
>
> The 'with' is sugar to specify the arguments and avoid all the
> ambiguous examples.

The macro works on the Scheme representation; it doesn't influence the
Wisp to Scheme conversion.  Any of those three Wisp variants would be
converted to the equivalent of

    (process list-file-template (with filename) ...)

where `process' above is a macro from sugar.scm (currently named
`process:').  And then the macro would expand that into something like

   (define-public list-file-template
     (lambda (filename)
       (process  ; <- process constructor from processes.scm, not sugar macro
        ...)))

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-05 16:02                 ` Kyle Meyer
@ 2020-02-05 16:23                   ` zimoun
  0 siblings, 0 replies; 28+ messages in thread
From: zimoun @ 2020-02-05 16:23 UTC (permalink / raw)
  To: Kyle Meyer; +Cc: Ricardo Wurmus, gwl-devel

Hi Kyle,

On Wed, 5 Feb 2020 at 17:02, Kyle Meyer <kyle@kyleam.com> wrote:

> The macro works on the Scheme representation; it doesn't influence the
> Wisp to Scheme conversion.  Any of those three Wisp variants would be
> converted to the equivalent of
>
>     (process list-file-template (with filename) ...)

Maybe I miss a point. :-)

Here [1] Ricardo described the goal: at the end of the process there
is something like you write.

[1] https://lists.gnu.org/archive/html/gwl-devel/2020-02/msg00016.html


The question is: what should be the "nice" syntax using the "Wisp
reader"? Do I misread something?

Maybe the confusion comes from that the same term is used for the
constructor and for the macro:

    process-the-macro list-file-template (with filename)

will expand to:

    (define-public list-file-template
      (lambda (filename)
        (process-the-constructor
         ...)))


I agree with you and you mentioned the confusion here [2], quoting you ;-)

<<
Perhaps.  I still have the feeling that sharing the same name is risking
confusion.  In particular, the fact that how 'process' should be used
depends on an import could make it harder for (1) those trying to learn
the workflow language by looking at and comparing Scheme examples from
various sources and (2) those trying to understand how Wisp maps to
Scheme.
>>

[2] https://lists.gnu.org/archive/html/gwl-devel/2020-02/msg00019.html


All the best,
simon

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-05 15:07     ` zimoun
@ 2020-02-05 18:04       ` Ricardo Wurmus
  2020-02-05 19:14         ` zimoun
  0 siblings, 1 reply; 28+ messages in thread
From: Ricardo Wurmus @ 2020-02-05 18:04 UTC (permalink / raw)
  To: zimoun; +Cc: gwl-devel


zimoun <zimon.toutoune@gmail.com> writes:

> Does it make sense to expand "process: proc arg" as "process : proc arg"?
> Well, disallow the colon ':' in all the name (symbol) and then expand.

This is not easily accomplished because “:” is a valid character in a
symbol.  So I’d have to replace the reader to disallow “:” in symbols.
That’s a very big intervention.

> Because this space is a drawback of Wisp, I mean at least to me.
> Especially coming from Python where the standard is to have "def
> proc(arg):" and not "def proc(arg) :".

I see what you mean.  The “:” on its own is just the Wisp way of saying
“wrap the rest of this line in parentheses”.  In Haskell that’s “$”.  In
both cases it’s separate from any identifiers.

In the Python case the “:” serves no real purpose as far as I can tell.

>>     process list-file-template (filename)
>
> I find this one the clearer.

Unfortunately, this one is not possible due to ambiguity in the process
macro as I explained in an earlier email.  We can avoid this ambiguity
by adding “with” as extra syntax:

  process list-file-template (with filename)

It’s not perfect, but I don’t see another way that would be any clearer.
An (untested) alternative is

  process list-file-template this that anything whatever
    …

or

  process list-file-template with this that anything whatever
    …

i.e. just list the arguments after the process name.  What’s not so nice
about this is the lack of visual separation (you will need editor
support to visually set the arguments apart from the first two tokens),
and the fact that you’ll probably have to use a leading period to
continue the line.

I honestly can’t tell which of the options is better.  It’s like saying
the word “table” 50 times in a row and wondering what these odd sounds
really mean…

--
Ricardo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-05 18:04       ` Ricardo Wurmus
@ 2020-02-05 19:14         ` zimoun
  2020-02-05 21:32           ` Ricardo Wurmus
  0 siblings, 1 reply; 28+ messages in thread
From: zimoun @ 2020-02-05 19:14 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel

Hi Ricardo

On Wed, 5 Feb 2020 at 19:04, Ricardo Wurmus <rekado@elephly.net> wrote:

> > Does it make sense to expand "process: proc arg" as "process : proc arg"?
> > Well, disallow the colon ':' in all the name (symbol) and then expand.
>
> This is not easily accomplished because “:” is a valid character in a
> symbol.  So I’d have to replace the reader to disallow “:” in symbols.
> That’s a very big intervention.

Ok.
It was just an idea. :-)


> > Because this space is a drawback of Wisp, I mean at least to me.
> > Especially coming from Python where the standard is to have "def
> > proc(arg):" and not "def proc(arg) :".
>
> I see what you mean.  The “:” on its own is just the Wisp way of saying
> “wrap the rest of this line in parentheses”.  In Haskell that’s “$”.  In
> both cases it’s separate from any identifiers.

The dollar '$' appears to me a better choice than the colon ':'.
Because the colon is used in plain English and often used elsewhere
without space (YAML, python, etc.). It is about habits.
Well, that's another story. :-)


> In the Python case the “:” serves no real purpose as far as I can tell.

Hum? The colon ':' serves as separator used by the parser, AFAIU.
I mean the colon ':' is part of the Python grammar.

https://docs.python.org/3/reference/grammar.html

Well, that's another story again. ;-)


> >>     process list-file-template (filename)
> >
> > I find this one the clearer.
>
> Unfortunately, this one is not possible due to ambiguity in the process
> macro as I explained in an earlier email.  We can avoid this ambiguity
> by adding “with” as extra syntax:

Sorry I unqueued my emails in order. :-)


>   process list-file-template (with filename)
>
> It’s not perfect, but I don’t see another way that would be any clearer.

I am fine with the 'with' keyword.

>   process list-file-template with this that anything whatever

As I said elsewhere, I am not bothered by the previous syntax.

And I find equivalently nice the both using 'with'; without or with parenthesis.


> I honestly can’t tell which of the options is better.  It’s like saying
> the word “table” 50 times in a row and wondering what these odd sounds
> really mean…

:-D


Aside, the 'process' macro should be renamed as Kyle mentioned it.
Because it is confusing, IMHO.


Thank you for all these new inputs on GWL.

Cheers,
simon

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-05 19:14         ` zimoun
@ 2020-02-05 21:32           ` Ricardo Wurmus
  2020-02-06 11:59             ` zimoun
  0 siblings, 1 reply; 28+ messages in thread
From: Ricardo Wurmus @ 2020-02-05 21:32 UTC (permalink / raw)
  To: zimoun; +Cc: Roel Janssen, Kyle Meyer, gwl-devel


zimoun <zimon.toutoune@gmail.com> writes:

>> In the Python case the “:” serves no real purpose as far as I can tell.
>
> Hum? The colon ':' serves as separator used by the parser, AFAIU.
> I mean the colon ':' is part of the Python grammar.
>
> https://docs.python.org/3/reference/grammar.html

Yeah, I just mean that it’s “noise”.  It doesn’t represent anything
(unlike the $ in Haskell).

> Aside, the 'process' macro should be renamed as Kyle mentioned it.
> Because it is confusing, IMHO.

Yes, I’m considering a rename, but I’m not sure which is the best
option.  We could either have (1) “define-process” (for value +
definition) and “process” (for just the value), or we could have (2)
“process” (for value + definition) and “make-process” (for just the
value).

I’m torn on this because option 1 seems correct, but option 2 results in
less boilerplate as users need to bind processes to variables in order
to reference them in a workflow definition.

I’ll likely go with option 2.

We only need to decide whether the “process” macro (for value +
definition) should also be available by default in Scheme workflows or
if it should only be enabled by default in Wisp workflows.

--
Ricardo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-05 21:32           ` Ricardo Wurmus
@ 2020-02-06 11:59             ` zimoun
  0 siblings, 0 replies; 28+ messages in thread
From: zimoun @ 2020-02-06 11:59 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: Roel Janssen, Kyle Meyer, gwl-devel

Hi,

On Wed, 5 Feb 2020 at 22:33, Ricardo Wurmus <rekado@elephly.net> wrote:

> > Aside, the 'process' macro should be renamed as Kyle mentioned it.
> > Because it is confusing, IMHO.
>
> Yes, I’m considering a rename, but I’m not sure which is the best
> option.  We could either have (1) “define-process” (for value +
> definition) and “process” (for just the value), or we could have (2)
> “process” (for value + definition) and “make-process” (for just the
> value).

Just to be sure to well understand.

Option 1.

    define-process list-file-template (with filename)

will expand to:

     (define-public list-file-template
       (lambda (filename)
         (process
          ...)))

and option 2.

     process list-file-template (with filename)

will expand to:

     (define-public list-file-template
       (lambda (filename)
         (make-process
          ...)))


Right?


> I’m torn on this because option 1 seems correct, but option 2 results in
> less boilerplate as users need to bind processes to variables in order
> to reference them in a workflow definition.
>
> I’ll likely go with option 2.

Instead of 'make-process', why not 'processor'?


> We only need to decide whether the “process” macro (for value +
> definition) should also be available by default in Scheme workflows or
> if it should only be enabled by default in Wisp workflows.

You mean:

  (process list-template
     (with filename)
     (name ...)
     ...)

right?

I think, it is a good idea because it eases the learning process from
high-level Wisp to more Scheme plumbings.




Cheers,
simon

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Comments on process template syntax
  2020-02-05 14:56   ` zimoun
@ 2020-02-08 12:34     ` Ricardo Wurmus
  0 siblings, 0 replies; 28+ messages in thread
From: Ricardo Wurmus @ 2020-02-08 12:34 UTC (permalink / raw)
  To: zimoun; +Cc: gwl-devel


zimoun <zimon.toutoune@gmail.com> writes:

>> Maybe we can just clarify the feature better in the documentation.
>> Here's my initial thought:
>> ---
>> When defining processes, they can be parameterized by turning the
>> process definition into a procedure, which will form a template for
>> processes to be defined later.  This is done by adding a name for the
>> template, and its parameters directly after "process:".
>> ---
>
> I agree.

The documentation now has a dedicated section about process templates.

-- 
Ricardo

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, back to index

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

unofficial mirror of gwl-devel@gnu.org

Archives are clonable:
	git clone --mirror https://yhetil.org/gwl/0 gwl/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 gwl gwl/ https://yhetil.org/gwl \
		gwl-devel@gnu.org
	public-inbox-index gwl

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.gwl


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git