[erlang-questions] Strings as Lists

Matt Kangas kangas@REDACTED
Fri Feb 22 21:22:21 CET 2008

Taj -- thank you for the example of literal-string quoting from Lua!  
Seems an interesting yet simple approach.

Richard -- re: your last post on this subject, which I found quite  
illuminating as well...

A syntax for literal string declarations is, by definition, syntactic  
sugar. It's not making the core language more expressive. It's for  
improving the human-machine interface in specific situations. Since  
usability is really the goal, then your first-and-foremost requirement  
is to... make it usable in those situations. Syntactic power (nesting  
multiple syntaxes) is *very nice*, but should be a distinctly  
secondary goal.

As you said, no one quoting character sequence will suffice for _all_  
situations. In the case of multi-line strings, approaches we've seen  

1) Define a framework, have the framework know (and hide) the  
appropriate terminating char-sequence
2) Let the user define a terminating char sequence. (Perl/PHP/Ruby's  
3) Have one terminating multi-line char sequence. (Python's answer)
4) Have one char-sequence, but permit its length to vary to allow  
nesting, within reason. (Lua's answer)

Richard, from your last post:

> 	Literal_String = """
> 	Here is `'"\$^some literal text with an embedded
> 	but no trailing newline
> 	""",
> 	Another = ""!He said "Foo!" But that was not the end!!""

That example falls into camp (2), user-defined terminating char, yes?

I suppose the motivation for (3) or (4) could be, perhaps, a desire to  
make the string-enclosing syntax consistent, thus making it easier to  
read unfamiliar code. The reader doesn't have to guess (or look  
carefully for) what terminating-sequence the author chose. (4)  
encourages consistency while still permitting nesting.

As I said before, I think nesting is a nice, not necessary, property.  
I presume you won't consider anything a "solution" unless it _is_  
nestable. :)

Comparing (1) and (2), I believe the programmer who's writing the code  
is best-positioned to decide what's an appropriate terminating  
sequence. I think hiding the terminating sequence behind a name ("/ 
xml", "/latex", "/url") is likely to cause bugs, or at least weird  
compilation errors.

And.. we haven't discussed "raw" strings for regexes. Doh!

Joe's original proposal was:

> ~n"...."   turn off quoting
> ~r"...."    string is a regexp
> ~x"..."    string is xml
> ~x/FlunkyStuff ... FunkyStuff  (string is xml terminated by  
> FunkyStuff)
> ~myExpander/FunkyStuff .... FunckyStuff

Richard, which parts of this seem especially troublesome, and which  
are salvageable?

(IMO, seems like a combination of camps (1) and (2) per above...)


On Feb 20, 2008, at 7:38 PM, Taj Khattra wrote:

>> Perhaps if we
>> say that a literal string begins with n+2 quotation marks and a
>> single character
>> that is not a letter, digit, space, or tab, and then ends with
>> another copy of
>> that single character followed by n+2 quotation marks.
> here's an excerpt from http://www.lua.org/manual/5.1/manual.html#2.1
> specifying how literal strings can be defined in Lua:
> Literal strings can also be defined using a long format enclosed by
> long brackets. We define an opening long bracket of level n as an
> opening square bracket followed by n equal signs followed by another
> opening square bracket. So, an opening long bracket of level 0 is
> written as [[, an opening long bracket of level 1 is written as [=[,
> and so on. A closing long bracket is defined similarly; for instance,
> a closing long bracket of level 4 is written as ]====]. A long string
> starts with an opening long bracket of any level and ends at the first
> closing long bracket of the same level. Literals in this bracketed
> form may run for several lines, do not interpret any escape sequences,
> and ignore long brackets of any other level. They may contain anything
> except a closing bracket of the proper level.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

Matt Kangas
kangas@REDACTED – www.p16blog.com

More information about the erlang-questions mailing list