objections to short syntax for code snippets?

[Ricardo Wurmus <rekado@elephly.net>]

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