Lambda the Ultimate

but ruby is a perl in the end ;)

so it uses 'string' , "string" and heredocuments, and even charater delimited strings:
%somecharacter blabla somecharacter

Not that I find the usage of % or q/qq reasonable.. why can't this just be named 'string' :)

Python's three ways of quoting is extremely programmer friendly, because I can usually get around quoting problems by adopting a different set of quotes.

str1 = '<a href="http://test.com">Hyper Link</a>'
str2 = "Tom's Thumb"
str3 = '''
This is how you do a 
triple quotes in python:
  """Triple quote"""
'''

Python is the only language I've ever used that made working with string literals reasonably painless. I've never understood why more people haven't followed the Python approach. Yes, there are a lot of options, but in this case, they really are all useful. And it's not like it's a hard change to make in a language... only the lexer needs to change, in many cases...

Particularly for languages aspiring to compete in the Python/perl space (some Schemes, for instance), more options for string literals is just essential.

I've never understood why more people haven't followed the Python approach.

I can think of two reasons.

First, next to integers (and maybe lists), strings are probably the most overused data type. People use strings when they are too lazy or inept to define a more structured representation for something. For example, when you manipulate XML or HTML, you should not be using a string type; you should be using at least a tree type, and preferably a set of tree types which correspond to the Schema in question, so you can read only well-typed documents and write only well-typed documents. It is really appalling to see how many webpage-producing applications don't do this. Adding all sorts of bells and whistles to string literals encourages this sort of misuse.

Second, many people (not necessarily me, though) are of the opinion that program source should not be littered with constants. For example, if you are developing an application, it is better to put message text in an external resource file, or database, or whatever, which helps for example with localization. Here again, adding features to string literals would be sending the wrong, er, message.

Personally, I am not opposed to adding a few more bells and whistles to string literals, but IMO it is generally the poorest languages that spend the most effort on those sorts of trivialities. It's the language-design equivalent of bit-twiddling. Perl is a perfect example.

While I don't like Perl very much, I think you are being somewhat unfair to its designers. Their focus on string manipulation really has led them in the direction of higher-level abstractions -- for example, Perl 6's string manipulation facilities are basically a nice syntax for parser combinators. This seems like fundamentally the right way to go to me, and they should be praised for adopting it.

I also think that there's some fairly interesting research questions about what the best way to print data is! All I know of in this regard is Olivier Danvy's paper on functional unparsing and Hughes's famous paper on pretty-printing, and I don't think that's the end of the story. A format string can be seen as sugar for these kinds of APIs, and as long as the language designers are thinking about this sort of issue when they are designing their literal syntax I don't think it's bit-twiddling.

Perl 6's string manipulation facilities are basically a nice syntax for parser combinators

You are far too generous. If what you say were true and Perl's designers actually had that much insight into what they were doing, then 1) those facilities would not be limited to strings, which are after all merely sequences of characters, 2) the facilities could handle other sorts of monads, and 3) they would be described via a source-to-source translation, like derived forms in Scheme or do-syntax in Haskell.

I've looked at the Perl apocalypses and they are hardly more than a scatter-brained enumeration of trivia and faux pas; it reads like a blind man's account of constructing a puzzle. It doesn't solve problems by solving problems; it's a misadventure in stochastic symbol-pushing. Perl 6 is just another iteration in that language's interminable and drunken meandering. Occasionally it stumbles across a good idea, in the same way that a construction worker might unearth a fossil when drives his pickaxe through it. According to you, I guess "we can regard him as" a paleontologist, then.

A format string can be seen as sugar for these kinds of APIs

It can also be seen as a format string, that is, as a hack.

No reasonable designer would represent formats as strings by choice. Hell, we can represent anything as a string, right? That's not a brilliant observation: it's why we use text editors to write programs. Brilliant observations arise from revealing the structure of an object, not burying it. To say that the integers form a monoid is more insightful than to say they form a set. To say they form a group is more insightful than to say they form a monoid. To say they form a ring is more insightful than to say they form a group.

Hell, why stop at formats? Why not represent a numbers as strings too? And characters? And arrays? And records? Or functions? Oh wait, I'm starting to get a brilliant idea... why don't we shove every data type into one universal data type! Yeah, that will solve all our problems.

Gee, how many other hacks "can be seen as sugar for" rationally-designed language features? Let's see: XML is just sugar for algebraic datatypes; goto, break and continue are just sugar for first-class continuations; const and final are just sugar for referential transparency; operator overloading is just sugar for type classes; C++ templates are just sugar for bounded polymorphism and MetaML.

Yeah, I guess you're right. PLT is superfluous—it's all been done before!

Well, I'm sorry for being so caustic, but I'm really sick of this "it's not a bug, it's a feature!" attitude. Even if "worse" is "better", that doesn't mean that the people who design the "worse" actually know they are doing it. In fact, in my experience, they often think they are designing the "better".

Frank,

I've been reading with interest. How about some concrete examples of what you mean? and what alternatives are available? At the bottom of this discussion I suggested that if programs can be represented by Non-ASCII characters, some of these problems can be avoided.

What are your thoughts?

In the end, the problem of escaping escapes arise because ASCII is being used to represent ASCII + 1.

In templating languages, ASCII is used to represent different data structures and it fails to varying degrees.

Changing quotes will work only if the change quote command itself is immune to the structural change.

Here's an imaginary language which uses [] and a command called changequote.

The quick brown fox jumps over the [username]

changequote()

The quick brown fox jumps over the (username).

But I'm stuck because I can't show you how to
changequote in this language, unless I intentionally break the command. eg.

changequote-`' (ignore the dash between the word "changequote" and the back tick)

In the end, this kind of problems are solved by View source in HTML, or Edit in a wiki... because it allows users to actually learn what the correct representation is.

There's been some debate that source code shouldn't be represented as ASCII anymore than building plans should be represented by words. The case of the escaping escape is a damning example of how software development is still stuck in the days of the teletype terminals.

From the section you linked to:

Other languages are designed by piling feature upon feature. BRL is designed by removing the restrictions on existing features that make additional features appear necessary.

From R5RS:

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.

:)

[ [literal string] ]

 <%= lt;% literal string %> %> 

/* /* this style of comment is illegal */ */

How does BRL resolve the bracket's though? If I wanted to represent a right square bracket, how would it be done?

[ ] ] 

Does BRL have some precedence rules to resolve the ambiguity above?

For more on this topic, search for "intentional programming".

Also have a look at Interactive Source Code (Caution: powerpoint viewer required) by Lutz Roeder. The focus here is not on editing source code visually but browsing source code visually.

Current IDEs for JSPs and other embedded templating languages just don't recognize the existing embelishments and tags. Which of the following would you consider more readable?

<div class="header"><b>User Names </b><br/>
<% for user in users
 response.write("<i>" + user + </i>")
%>
<B>Done.</B>

or

 <% for user in users
   response.write(user)
%>

In terms of readability, the latter wins hands down, and is more likely able to point out errors. Let us not forget when VI was first invented, doubters would say that it's not as portable as "ed" and they'd be right.