REBOL3 tracker
  0.9.12 beta
Ticket #0001194 User: anonymous

Project:

Previous Next
rss
TypeWish Statusreviewed Date12-Aug-2009 10:53
Versionalpha 76 CategorySyntax Submitted byoldes
PlatformAll Severityminor Prioritynormal

Summary "heredoc" like notation to specifying a string literal
Description Would it be possible to add a new way how to specifying a string literal without need to escape unmatched {} pairs, so it would be more friendly to work with other C-ish like languages (which are heavily using curly brackets) from REBOL code?

Here is how it's used in some other languages: http://en.wikipedia.org/wiki/Heredoc
Example code

			

Assigned ton/a Fixed in- Last Update23-Nov-2013 15:51


Comments
(0001480)
BrianH
12-Aug-2009 17:40

This would need to be a syntax feature, and some trick with serialized syntax probably wouldn't help.

If some multi-character delimiter is used, it would be best if the leading delimiter ended with a newline, and the trailing delimiter started with a newline, said newlines not appearing in the resulting string. The data should continue to be UTF-8 encoded in the source, rather than binary. A missing trailing delimiter would be a syntax error.

I'm neutral on whether we need this feature. All the other kids have it though.
(0001484)
Carl
14-Aug-2009 06:08

If you look at the actual definition of a heredoc on that page, we do it quite nicely in REBOL!

Of course, if you want to enclose any char, including an unmatched brace terminator, then you need to have some method of knowing what the terminating sequence would be. Some shells/langs use "a variable" to indicate that (follows the opening quote and the ending quote) -- which mainly allows a heredoc to include another heredoc, to whatever extent desired.

LOAD (TRANSCODE) would be the easy part for supporting this. The hard part would be MOLD, which, I assume would need to return to the original format. This means that such strings would require some kind of flag to know that they should be molded back into that format.
(0001486)
BrianH
14-Aug-2009 09:16

Don't bother to MOLD back to that format - this is just a way for a programmer to keep from having to type escape characters. It doesn't need to be preserved, since MOLD doesn't mind typing escape characters where needed.
(0002579)
Ladislav
15-Oct-2010 22:10

A syntax idea:

#[[my-heredoc
this is my {"([#[ heredoc string
my-heredoc]]

, the my-heredoc part is the variable part Carl mentioned above. The simplest variant, having the variable part of the delimiters empty would be:

#[[
this is my heredoc string
]]

The main property of the proposed heredoc syntax is, that no escaping is used inside the heredoc string.
(0002580)
oldes
16-Oct-2010 01:25

I think that to have the "easy LOAD" part with syntax mentioned by Ladislav would be good start. I'm not sure if MOLD must use the heredoc again. This syntax is useful mainly for building HTML pages including JavaScript, which is very "curly". I don't see a reason why cgi scripts should be MOLDed. At least now.

And if molding to heredoc format would be required, isn't adding a refinement to MOLD function enough?

>> mold/heredoc "{b" "my-heredoc"
== {#[[my-heredoc
{b
my-heredoc]]}
(0002581)
Ladislav
16-Oct-2010 11:33

I do agree, that "MOLD does not mind escaping characters".

Currently, REBOL has three alternatives how a string can be defined:

* using double quotes

* using curly brackets

* not using a syntactic construct (e.g. reading a string from a file)

Since REBOL does not maintain any information how the string was originally defined (with users being used to it), this situation should not change and REBOL should continue not maintaining this information even when the fourth alternative of defining strings will be used.
(0002583)
BrianH
16-Oct-2010 19:03

Don't bother with a MOLD refinement. It is easy enough to make a heredoc formatter as a separate function:
mold-heredoc: func [value tag [string!]] [
ajoin ["#[[" tag "^/" either string? :value [value] [mold :value] "^/" tag "]]"]
]
(0002584)
oldes
16-Oct-2010 21:17

Correct, I agree that the separate function is enough. Just the tag should not be string but word. But again.. I think that molding is not important at all.
(0002585)
BrianH
17-Oct-2010 03:03

Agreed, both word and string tags should be supported by the function, though limiting to the word character set isn't bad. And the MOLD is presumptuous - let people generate their own strings.

heredoc: func [value [string!] tag [string! word!]] [
ajoin ["#[[" tag: to-word tag "^/" value "^/" tag "]]"]
]
(0002586)
Ladislav
17-Oct-2010 08:48

Advantages of the proposed heredoc syntax:

* it is backwards compatible, not occupying any existing syntactic construct

* it visibly separates "outside", the delimiters, and "inside" even better than other heredoc implementations do

* the construct was proposed with respect to "good writability" of the separators

* since no escaping is used between the heredoc delimiters, this syntax will be the most human readable syntax defining REBOL strings; readability, writability, and in general, handleability for humans are the main goal of it

* the construct can work well with the COMMENT function, allowing the comment contents to remain "unescaped" similarly as the contents of the ; comments are

* the construct is "transparent" meaning, that for the users not wanting to use it, nothing changes
(0002588)
Ladislav
17-Oct-2010 10:33

Regarding the syntax name - if we want to use a scientific one, we can call the syntaxes "single-line syntax with escaping", "multi-line syntax with escaping", and "multi-line syntax without escaping". The newly proposed heredoc syntax is the last one.
(0004209)
Ladislav
23-Nov-2013 15:51

See also #2094 where a different syntax (better suited for short strings) is mentioned:

my-heredoc-string{}my-heredoc-string

Date User Field Action Change
23-Nov-2013 15:51 Ladislav Comment : 0004209 Added -
17-Oct-2010 20:11 Ladislav Comment : 0002588 Modified -
17-Oct-2010 10:33 Ladislav Comment : 0002588 Added -
17-Oct-2010 09:33 Ladislav Comment : 0002581 Modified -
17-Oct-2010 09:22 Ladislav Comment : 0002586 Modified -
17-Oct-2010 09:13 Ladislav Comment : 0002586 Modified -
17-Oct-2010 09:13 Ladislav Comment : 0002586 Modified -
17-Oct-2010 09:11 Ladislav Comment : 0002586 Modified -
17-Oct-2010 09:10 Ladislav Comment : 0002586 Modified -
17-Oct-2010 09:10 Ladislav Comment : 0002586 Modified -
17-Oct-2010 08:48 Ladislav Comment : 0002586 Added -
17-Oct-2010 08:46 Ladislav Comment : 0002579 Modified -
17-Oct-2010 08:46 Ladislav Comment : 0002581 Modified -
17-Oct-2010 08:38 Ladislav Comment : 0002579 Modified -
17-Oct-2010 03:03 BrianH Comment : 0002585 Added -
16-Oct-2010 21:17 oldes Comment : 0002584 Added -
16-Oct-2010 19:57 Ladislav Comment : 0002579 Modified -
16-Oct-2010 19:56 Ladislav Comment : 0002579 Modified -
16-Oct-2010 19:52 Ladislav Comment : 0002579 Modified -
16-Oct-2010 19:46 Ladislav Comment : 0002581 Modified -
16-Oct-2010 19:03 BrianH Comment : 0002583 Added -
16-Oct-2010 11:43 Ladislav Comment : 0002581 Modified -
16-Oct-2010 11:42 Ladislav Comment : 0002581 Modified -
16-Oct-2010 11:42 Ladislav Comment : 0002581 Modified -
16-Oct-2010 11:33 Ladislav Comment : 0002581 Modified -
16-Oct-2010 11:33 Ladislav Comment : 0002581 Added -
16-Oct-2010 11:30 Ladislav Comment : 0002579 Modified -
16-Oct-2010 11:28 Ladislav Comment : 0002579 Modified -
16-Oct-2010 01:35 oldes Comment : 0002580 Modified -
16-Oct-2010 01:25 Ladislav Comment : 0002579 Modified -
16-Oct-2010 01:25 oldes Comment : 0002580 Added -
16-Oct-2010 00:55 Ladislav Comment : 0002579 Modified -
16-Oct-2010 00:52 Ladislav Comment : 0002579 Modified -
16-Oct-2010 00:50 Ladislav Comment : 0002579 Modified -
16-Oct-2010 00:46 Ladislav Comment : 0002579 Modified -
16-Oct-2010 00:37 Ladislav Comment : 0002579 Modified -
16-Oct-2010 00:34 Ladislav Comment : 0002579 Modified -
16-Oct-2010 00:06 Ladislav Comment : 0002579 Modified -
15-Oct-2010 23:52 Ladislav Comment : 0002579 Modified -
15-Oct-2010 23:17 Ladislav Comment : 0002579 Modified -
15-Oct-2010 22:48 Ladislav Comment : 0002579 Modified -
15-Oct-2010 22:17 Ladislav Comment : 0002579 Modified -
15-Oct-2010 22:16 Ladislav Comment : 0002579 Modified -
15-Oct-2010 22:10 Ladislav Comment : 0002579 Added -
14-Aug-2009 09:19 BrianH Comment : 0001486 Modified -
14-Aug-2009 09:16 BrianH Comment : 0001486 Added -
14-Aug-2009 06:08 carl Comment : 0001484 Added -
12-Aug-2009 17:40 BrianH Comment : 0001480 Added -
12-Aug-2009 17:26 BrianH Status Modified submitted => reviewed
12-Aug-2009 17:26 BrianH Category Modified Unspecified => Syntax
12-Aug-2009 17:26 BrianH Description Modified -
12-Aug-2009 10:53 oldes Ticket Added -