Re: objections to short syntax for code snippets?

[Roel Janssen]

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