unofficial mirror of gwl-devel@gnu.org
 help / color / mirror / Atom feed
From: Roel Janssen <roel@gnu.org>
To: Ricardo Wurmus <rekado@elephly.net>, gwl-devel@gnu.org
Subject: Re: objections to short syntax for code snippets?
Date: Tue, 04 Feb 2020 14:31:23 +0100	[thread overview]
Message-ID: <aee0f6c3a54b3b63e8ed6750a8a9076e806bba77.camel@gnu.org> (raw)
In-Reply-To: <871rrasdsl.fsf@elephly.net>

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

  reply	other threads:[~2020-02-04 13:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-04 13:05 objections to short syntax for code snippets? Ricardo Wurmus
2020-02-04 13:31 ` Roel Janssen [this message]
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

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