Ticket #0002185

Type	Wish	Status	submitted	Date	4-Nov-2014 01:46
Version	r3 master	Category	Datatype	Submitted by	fork
Platform	All	Severity	minor	Priority	normal

Summary	Nestable and multi-line-capable TAG!
Description	There is a tremendous win in Rebol by having an asymmetric delimiter available for string, that can span multiple lines. The benefits of this seemingly small design decision are felt far and wide. URL! and FILE! do not have asymmetric delimiters. I would suggest that their construction syntax should allow it (by piggy-backing on square bracket) But in a world of finite availability of matched pairs in ASCII, TAG! isn't as flexible as it could be. In Draem {Ordinary strings [are markdown](http://draem.hostilefork.com/)} so I wondered how to have a string that should be treated as raw HTML. Why not TAG!? <<p>What is wrong with <b>this</b> being a tag?</p>> Right now that gives you: ** Syntax error: invalid "word" -- "<<p>What" But couldn't TAG! use similar rules to how STRING! manages embedded braces, and even go as far as to support multi-line TAG! literals? If TAG! is truly a tinkertoy and usable for dialect purposes, shouldn't it be using the asymmetric delimiters to at least the same advantage as STRING!? Particular to the domain of TAG! applications is the question of how to manage > or < symbols that appear alone inside of quotes. If the analogy to STRING! were held up, these would have to be escaped (by caret, we assume). Currently they do not have to be if they appear in double quotes. >> load {<div title="1 < 2">} == <div title="1 < 2"> >> load {<div title="1 > 2">} == <div title="1 > 2"> The same leeway is not granted to single quotes, which it would seem it should be if this feature is there for tags-with-attributes...because single quotes are legal there too: >> load {<div title='1 > 2'>} * ERROR Syntax error: invalid "integer" -- "2'>" Yet rather than delve deeper into this peculiarity, I'd suggest that escaping with a caret would be fine, as I don't really think this comes up so often. It would also hopefully just allow one to reuse the scanning code for curly braces for tags; just have that code process them with a different delimiter. It is regrettable that comparison operators interfere with TAG!, which could have provided a full second asymmetrically-delimited string class. For instance, if <> was available it could mean "empty tag". As it stands there are some tough spots with comparison operators that interfere with making that a slam dunk. Perhaps the relatively limited scope of application of TAG! made it favorable to go with the cultural definitions of `>` and `<` rather than ask people to compromise with greater? and less?. Regardless, it seems that getting more bang-for-the-buck out of TAG!s asymmetry could lead to more applications to TAG! than previously thought. Just as PAREN! gives opportunities by being a different flavor of BLOCK! with the same flexibility, so could TAG! be a contender for being just as versatile as STRING!. (Minus the caveats about <> vs {}, etc.)
Example code

Assigned to	n/a	Fixed in	-	Last Update	5-Nov-2014 12:22

Date	User	Field	Action	Change
5-Nov-2014 12:22	maxim	Comment : 0004542	Added	-
4-Nov-2014 04:25	fork	Description	Modified	-
4-Nov-2014 01:46	fork	Ticket	Added	-