unofficial mirror of gwl-devel@gnu.org
 help / color / mirror / Atom feed
* objections to short syntax for code snippets?
@ 2020-02-04 13:05 Ricardo Wurmus
  2020-02-04 13:31 ` Roel Janssen
  2020-02-05 14:40 ` zimoun
  0 siblings, 2 replies; 6+ messages in thread
From: Ricardo Wurmus @ 2020-02-04 13:05 UTC (permalink / raw)
  To: gwl-devel

Hello there!

I’d like to prepare a new release for the GWL soon to more officially
commit to the changes that happened in the past year.  So I think now is
a good time for some last minute objections :)

For some time now we have a reader extension that provides support for
embedded code snippets like this:

--8<---------------cut here---------------start------------->8---
process run-sh
  inputs
    . "a"
    . mine: "b"
    . "c"
    . yours: "d"
  # {
    echo "This is mine: {{inputs:mine}}, and this is yours: {{inputs:yours}}."
  }
--8<---------------cut here---------------end--------------->8---

Here we’ve got a process with four inputs, two of them tagged, and a
shell snippet that refers to the inputs.

The snippet is introduced with “# {” and ends on “}”.  Within the
snippet {{…}} is used to embed variable references.  {{variable:tag}} is
used to refer to tagged variables, so that in the example above
{{inputs:mine}} is replaced with the input tagged with the keyword
“#:mine” (or “mine:” due to SRFI-88), i.e. the string “b”.

“# {” is the easiest way of declaring a code snippet; optionally, a user
may provide an interpreter, so that

  # /bin/foo { … }

runs /bin/foo in the process environment and uses it to interpret the
snippet between the curly braces.

I think this syntax is pretty okay and avoids all sorts of conflicts,
such as conflicts with curly braces in the code snippet.  It is flexible
as you can specify any interpreter as long as it is provided by a
declared package.

It has two minor downsides, though:

1) it installs a reader extension, a token reader, on the space after #.
That’s okay, but some people think that transforming the read text so
radically is excessive and not what reader macros should be used for.
Oh well.

2) the simplest case of a shell snippet is very close to Guile’s syntax
for extended symbols.  The syntax for extended symbols is “#{the symbol
name}#”.  I don’t think it is very common to use this syntax in day to
day Scheme code — the Guile manual discourages its use in the diabolical
section 6.6.6.6.  But this means that it’s possible for inexperienced
users to accidentally specify an extended symbol when they want to
specify a shell snippet.

Consider this:

--8<---------------cut here---------------start------------->8---
process run-sh
  inputs "hello"
  #{ echo "I just want to say: {{inputs}}." }
--8<---------------cut here---------------end--------------->8---

This is a syntax error because “#{” is not terminated with “}#”.  We can
catch this error and suggest a fix.  Easy.

But what about this?

--8<---------------cut here---------------start------------->8---
process run-sh
  inputs "hello"
  #{
    function {
      echo "I just want to say something."
    }# this is not a comment
  }
--8<---------------cut here---------------end--------------->8---

This would print this confusing error message:

    In procedure read_inner_expression: /home/rekado/dev/gx/gwl/doc/examples/run-sh.w:7:4: unexpected "}"

This is the only case where this would be problematic.  In this very
similar case we can catch the error and suggest a fix:

--8<---------------cut here---------------start------------->8---
process run-sh
  inputs "hello"
  #{
    function {
      echo "I just want to say something."
    } # this is not a comment
  }
--8<---------------cut here---------------end--------------->8---

This prints:

    /home/rekado/dev/gx/gwl/doc/examples/run-sh.w:11:1: Unterminated extended symbol. Did you mean to use "# {" instead of "#{"?

(Annoyingly, the error location here is still wrong.)


Anyway, do you have any objections to this optional syntax?  Any
requests for changing it?  Note that it will always start with “#” as
that’s the only character where we can register reader macros.  I don’t
see a way to achieve any of this without a reader macro.  Maybe there’s
a way to do something smart with the Guile Reader library…?

Your comments are welcome!

--
Ricardo

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

* Re: objections to short syntax for code snippets?
  2020-02-04 13:05 objections to short syntax for code snippets? Ricardo Wurmus
@ 2020-02-04 13:31 ` Roel Janssen
  2020-02-05 14:40 ` zimoun
  1 sibling, 0 replies; 6+ messages in thread
From: Roel Janssen @ 2020-02-04 13:31 UTC (permalink / raw)
  To: Ricardo Wurmus, gwl-devel

On Tue, 2020-02-04 at 14:05 +0100, Ricardo Wurmus wrote:
> Hello there!
> 
> I’d like to prepare a new release for the GWL soon to more officially
> commit to the changes that happened in the past year.  So I think now
> is
> a good time for some last minute objections :)
> 
> For some time now we have a reader extension that provides support
> for
> embedded code snippets like this:
> 
> --8<---------------cut here---------------start------------->8---
> process run-sh
>   inputs
>     . "a"
>     . mine: "b"
>     . "c"
>     . yours: "d"
>   # {
>     echo "This is mine: {{inputs:mine}}, and this is yours:
> {{inputs:yours}}."
>   }
> --8<---------------cut here---------------end--------------->8---
> 
> Here we’ve got a process with four inputs, two of them tagged, and a
> shell snippet that refers to the inputs.
> 
> The snippet is introduced with “# {” and ends on “}”.  Within the
> snippet {{…}} is used to embed variable references.  {{variable:tag}}
> is
> used to refer to tagged variables, so that in the example above
> {{inputs:mine}} is replaced with the input tagged with the keyword
> “#:mine” (or “mine:” due to SRFI-88), i.e. the string “b”.
> 
> “# {” is the easiest way of declaring a code snippet; optionally, a
> user
> may provide an interpreter, so that
> 
>   # /bin/foo { … }
> 
> runs /bin/foo in the process environment and uses it to interpret the
> snippet between the curly braces.
> 
> I think this syntax is pretty okay and avoids all sorts of conflicts,
> such as conflicts with curly braces in the code snippet.  It is
> flexible
> as you can specify any interpreter as long as it is provided by a
> declared package.
> 
> It has two minor downsides, though:
> 
> 1) it installs a reader extension, a token reader, on the space after
> #.
> That’s okay, but some people think that transforming the read text so
> radically is excessive and not what reader macros should be used for.
> Oh well.
> 
> 2) the simplest case of a shell snippet is very close to Guile’s
> syntax
> for extended symbols.  The syntax for extended symbols is “#{the
> symbol
> name}#”.  I don’t think it is very common to use this syntax in day
> to
> day Scheme code — the Guile manual discourages its use in the
> diabolical
> section 6.6.6.6.  But this means that it’s possible for inexperienced
> users to accidentally specify an extended symbol when they want to
> specify a shell snippet.
> 
> Consider this:
> 
> --8<---------------cut here---------------start------------->8---
> process run-sh
>   inputs "hello"
>   #{ echo "I just want to say: {{inputs}}." }
> --8<---------------cut here---------------end--------------->8---
> 
> This is a syntax error because “#{” is not terminated with “}#”.  We
> can
> catch this error and suggest a fix.  Easy.
> 
> But what about this?
> 
> --8<---------------cut here---------------start------------->8---
> process run-sh
>   inputs "hello"
>   #{
>     function {
>       echo "I just want to say something."
>     }# this is not a comment
>   }
> --8<---------------cut here---------------end--------------->8---
> 
> This would print this confusing error message:
> 
>     In procedure read_inner_expression:
> /home/rekado/dev/gx/gwl/doc/examples/run-sh.w:7:4: unexpected "}"
> 
> This is the only case where this would be problematic.  In this very
> similar case we can catch the error and suggest a fix:
> 
> --8<---------------cut here---------------start------------->8---
> process run-sh
>   inputs "hello"
>   #{
>     function {
>       echo "I just want to say something."
>     } # this is not a comment
>   }
> --8<---------------cut here---------------end--------------->8---
> 
> This prints:
> 
>     /home/rekado/dev/gx/gwl/doc/examples/run-sh.w:11:1: Unterminated
> extended symbol. Did you mean to use "# {" instead of "#{"?
> 
> (Annoyingly, the error location here is still wrong.)

It's good to have this specific error message though.  So I'd like to
have that included.

> 
> Anyway, do you have any objections to this optional syntax?  Any
> requests for changing it?  Note that it will always start with “#” as
> that’s the only character where we can register reader macros.  I
> don’t
> see a way to achieve any of this without a reader macro.  Maybe
> there’s
> a way to do something smart with the Guile Reader library…?
> 
> Your comments are welcome!
> 

I don't have any objections.  The reader macro is not a big problem I
think.

Kind regards,
Roel Janssen

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

* Re: objections to short syntax for code snippets?
  2020-02-04 13:05 objections to short syntax for code snippets? Ricardo Wurmus
  2020-02-04 13:31 ` Roel Janssen
@ 2020-02-05 14:40 ` zimoun
  2020-02-05 15:10   ` Ricardo Wurmus
  1 sibling, 1 reply; 6+ messages in thread
From: zimoun @ 2020-02-05 14:40 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel

Hi Ricardo,

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


> --8<---------------cut here---------------start------------->8---
> process run-sh
>   inputs
>     . "a"
>     . mine: "b"
>     . "c"
>     . yours: "d"
>   # {
>     echo "This is mine: {{inputs:mine}}, and this is yours: {{inputs:yours}}."
>   }
> --8<---------------cut here---------------end--------------->8---


This is cool!

Aside your question, I am thinking if WISP could be adapted to use
dash '-' instead of dot '.' in the field 'inputs'.



> --8<---------------cut here---------------start------------->8---
> process run-sh
>   inputs "hello"
>   #{
>     function {
>       echo "I just want to say something."
>     } # this is not a comment

Annoying but I can live with. :-)

>   }
> --8<---------------cut here---------------end--------------->8---





> Anyway, do you have any objections to this optional syntax?  Any

No objections.


Thank you for all the improvements.

All the best,
simon

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

* Re: objections to short syntax for code snippets?
  2020-02-05 14:40 ` zimoun
@ 2020-02-05 15:10   ` Ricardo Wurmus
  2020-02-05 15:21     ` Pjotr Prins
  2020-02-05 15:31     ` zimoun
  0 siblings, 2 replies; 6+ messages in thread
From: Ricardo Wurmus @ 2020-02-05 15:10 UTC (permalink / raw)
  To: zimoun; +Cc: gwl-devel


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

>> --8<---------------cut here---------------start------------->8---
>> process run-sh
>>   inputs
>>     . "a"
>>     . mine: "b"
>>     . "c"
>>     . yours: "d"
>>   # {
>>     echo "This is mine: {{inputs:mine}}, and this is yours: {{inputs:yours}}."
>>   }
>> --8<---------------cut here---------------end--------------->8---
>
>
> This is cool!
>
> Aside your question, I am thinking if WISP could be adapted to use
> dash '-' instead of dot '.' in the field 'inputs'.

Tricky!  The “.” in Wisp just means “continue the previous line”.  In
this example it just looks really similar to a dash that’s used in YAML
to mark individual list items.

We don’t need any of these dots.  We could also just write this all on
one line (or any number of broken lines):

    process run-sh
      inputs "a"
        . mine: "b" "c" yours:
        . "d"
      # {
        echo "This is mine: {{inputs:mine}}, and this is yours: {{inputs:yours}}."
      }

This is equivalent, no difference whatsoever.

So my use of the dot is very suggestive, but there’s no way we can turn
it into a dash.

That said … macrology can be used to assign the dash special meaning (or
no meaning at all), but I’m not convinced that this would be a good
idea.  Lists are easier in Lisp compared to YAML — and thanks to what I
call “implicit lists” for the “inputs” and “outputs” fields you don’t
even need to start them with “list”.  It seems futile to try to make
lists more complicated by requiring that items begin with a dash.

--
Ricardo

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

* Re: objections to short syntax for code snippets?
  2020-02-05 15:10   ` Ricardo Wurmus
@ 2020-02-05 15:21     ` Pjotr Prins
  2020-02-05 15:31     ` zimoun
  1 sibling, 0 replies; 6+ messages in thread
From: Pjotr Prins @ 2020-02-05 15:21 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel

It is great to see these examples!

On Wed, Feb 05, 2020 at 04:10:36PM +0100, Ricardo Wurmus wrote:
> 
> zimoun <zimon.toutoune@gmail.com> writes:
> 
> >> --8<---------------cut here---------------start------------->8---
> >> process run-sh
> >>   inputs
> >>     . "a"
> >>     . mine: "b"
> >>     . "c"
> >>     . yours: "d"
> >>   # {
> >>     echo "This is mine: {{inputs:mine}}, and this is yours: {{inputs:yours}}."
> >>   }
> >> --8<---------------cut here---------------end--------------->8---

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

* Re: objections to short syntax for code snippets?
  2020-02-05 15:10   ` Ricardo Wurmus
  2020-02-05 15:21     ` Pjotr Prins
@ 2020-02-05 15:31     ` zimoun
  1 sibling, 0 replies; 6+ messages in thread
From: zimoun @ 2020-02-05 15:31 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel

Hi Ricardo,

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

> So my use of the dot is very suggestive, but there’s no way we can turn
> it into a dash.

I find your suggestion really appealing. :-)
Because it clarifies the description. And I read workflows more often
than I write them.


> That said … macrology can be used to assign the dash special meaning (or
> no meaning at all), but I’m not convinced that this would be a good
> idea.  Lists are easier in Lisp compared to YAML — and thanks to what I
> call “implicit lists” for the “inputs” and “outputs” fields you don’t
> even need to start them with “list”.  It seems futile to try to make
> lists more complicated by requiring that items begin with a dash.

I understand. I was just a random comment when dequeueing all your
cool proposals.
Thank you for improving.

Cheers,
simon

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

end of thread, other threads:[~2020-02-05 15:31 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-04 13:05 objections to short syntax for code snippets? Ricardo Wurmus
2020-02-04 13:31 ` Roel Janssen
2020-02-05 14:40 ` zimoun
2020-02-05 15:10   ` Ricardo Wurmus
2020-02-05 15:21     ` Pjotr Prins
2020-02-05 15:31     ` zimoun

unofficial mirror of gwl-devel@gnu.org

This inbox may be cloned and mirrored by anyone:

	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