Back quote within raw string literals

[Huan Du]

I'm working on a template parser that converts a template language similar to .rhtml into go source file.

Raw string literals are convenient for long paragraphs, expect representing back quotes itself. I have to break down long string and use a standalone "`" to output back quote. It's not efficient.

Is it possible to introduce a new literal to cover this case in go?

Solutions can be

- "here document" in other languages, or

-  a special char sequence to represent back quote, e.g. `a```b` means "a`b"

Brs,
- Huan

[David Symonds]

On Thu, Jan 12, 2012 at 2:24 PM, Huan Du <reald...@gmail.com> wrote:

> Raw string literals are convenient for long paragraphs, expect representing
> back quotes itself. I have to break down long string and use a
> standalone "`" to output back quote. It's not efficient.

Why isn't it efficient? Replacing ` with `+"`"+` seems fine to me.

Dave.

[Florian Weimer]

* Huan Du:

> - a special char sequence to represent back quote, e.g. `a```b` means "a`b"

Two `` are actually enough, as in SQL an Ada.

(I assumed that this quoting was in the language already, but purely
for lexing, it does not matter.)

[André Moraes]

> I'm working on a template parser that converts a template
> language similar to .rhtml into go source file.

Since, AFAIK rhtml, is a format for ruby template, I should just point that,
in case your rhtml file change you will need to recompile your entire
source code to
update with that.

Maybe, and this is a big maybe, instead of generating .go files you
could generate files for the
go html/template or text/template.

This solves the quoting problem and allow for template change without
code recompiling.

--
André Moraes
http://andredevchannel.blogspot.com/

[Jan Mercl]

A Go backquoted string never requires any [un]escaping. Not by any tool neither by a programmer reading it. Please keep this nice property even though some strings don't fit the limitation of not having the backquote character embedded.

[Jan Mercl]

[Florian Weimer]

* Jan Mercl:

If you escape the quote character by duplication, the set of
expressible strings becomes larger, without having to alter strings
which you could write before.

[Huan Du]

If there are lots of back quotes in html, I have to break strings lots of times. I guess there should be some extra memory cost using string concatenation, which it's unnecessary.

With here doc or special quote sequence, this case can be perfectly resolved. However, it's not a blocking issue right now.

I just want go-lang dev team to see this case and consider to add the fix to go in the future - if possible.

Brs,

- Huan

[Volker Dobler]

On 12 Jan., 04:24, Huan Du <realdod...@gmail.com> wrote:
> Is it possible to introduce a new literal to cover this case in go?
>
> Solutions can be
> - "here document" in other languages, or

Raw Strings are a kind of here documents, a very simple one
indeed without any user choice (the EOF in cat << EOF).

> -  a special char sequence to represent back quote, e.g. `a```b` means "a`b"

This just shift the problem "one up": If you like to write a text
which contains large amount of tripple backquotes you are
forced to write stuf like `f`````````(x)` to get "f```(x)" which is
needs counting to find out what you are trying to write.

Any "solution" to your special problem (backquotes in larger
texts) would just shift the problem and introduce an inconvenience
for someone else (who would then complain and ask for
a solution to his issue, ad ifinitum).

Backquotes are used for raw strings and raw cannot contain
backquotes. It is dead simple and will stay that way most probably.

Regards, Volker

[DisposaBoy]

correct me if I'm missing something but, why fight the language?

backtick in html is:

    &#96;

[Reinhard Wobst]

... just to remember how simple Python solved this problem: r"..." is
the raw string, and the only problem is a final backslash; in this
case you can add it as above (very rare). I am not going to propose
language changes here, but I would be happy with such a solution since
I *hate* backtics - there are fonts which have a very similar picture
of apostrophe and backtic. At least, on screens this happened to me.
The multiline-strings in Python starting and ending with """ or '''
are also a very good idea ... OK, we are in Go, but at least for
backtics I wished we had some replacement ...

Greetings, Reinhard

[Andrew Gerrand]

On 16 January 2012 10:42, Reinhard Wobst <zwi...@gmx.de> wrote:
> I *hate* backtics - there are fonts which have a very similar picture
> of apostrophe and backtic.

Then the solution is easy: don't use those fonts.

Andrew

[Rodrigo Moraes]

On Jan 15, 9:42 pm, Reinhard Wobst wrote:
> ... just to remember how simple Python solved this problem: r"..." is
> the raw string

The solution in Dart is rather weird: @"..." or @'...' are raw
strings. I prefer backticks.

-- rodrigo

[Reinhard Wobst]

> The solution in Dart is rather weird: @"..." or @'...' are raw
> strings. I prefer backticks.

Well, there are some misunderstandings:

- @Andrew: When you work as a contractor and no "good fonts" are
available (or there is simply no occasion to install others), the
problem persists. This was my experience. Moreover, when you have to
print a listing (or part of it :-), you often don´t know about the
output before. And if you mail somebody a listing ... I hope, you see
the problem.
- @Rodrigo: Whether "r" or "@" in front, does not matter, but in this
case you have only one problem, namely the closing backslash. In Go,
every backtic is a problem, a rather clumsy solution ... So we should
think about a better solution.

The UNIX shell also still allows backtics (and I still see them), but
the $(...) solution is much more readable and more powerful. So, we
speak about an extension, not a change of the syntax.

Greetings, Reinhard