Figure out what string interpolation syntax should be

[toroidal-code]

We really need this
I don't want c/c++

"thing: " + var + " is still here"

[zellio]

str = "#{Variable} not variable"

my $str = "This is $interpolated";

str = "Python's is dumb %(name)s." % variable

[zellio]

More importantly, there should be literal string and interpolated string. Either we need to use an inline glif or a format function. It's really up to which way we fall in that case.

[weswigham]

"Using a widely adopted {{thing}}" `context` {thing: "standard"}

Mustache/Handlebars-style interpolation as a language feature.
It goes so well with any system with objects or structures.
It would be so nice. Especially if, like, it was a method on the String object...

"This literal can be {{made}}".context {made: "interpolated."}

[weswigham]

One moment, let me summon my knowledge thus far... implementation of mustache w/o iterating over array/list structures...

String -> HashTable<String, T> -> String
fn context(str, tbl)
    tbl.each -> |k, v|
        str = context_internal(k, str, v)
    str

String -> String -> HashMap<String, T> -> String 
fn context_internal(prefix, str, table)
    table.each -> |k, v|
        str = context_internal(prefix+"."+k, str, v)
    str

String -> String -> String -> String
fn context_internal(prefix, str, rep)
    str.gsub("{{"+prefix+}}", rep)

And let me tell you about how much I love language features implemented in the language itself.

[toroidal-code]

@zellio's right. We're going to need some sort of distinction between interpolated strings and string literals. At least in the first round of the compiler, we (probably) won't be able to handle unicode in interpolated strings, since the compiler will have to do string manipulation on them, and OCaml has pretty bad unicode support.

I really like the ability to just format strings without any sort of format function, because it's pretty, but that will require we have something special like $"some string {{var}} " to denote interpolated strings. This will also require that we have a special AST pass that traverses the tree and grabs the variable's references when compiling.

On the other hand, a format function could be part of the String class, and reduce this to a simple function call such as "some string {{var1}} {{var2}}".fmt(var1, var2) that occurs at run-time.

Opinions?

[nickserv]

We could do what Ruby does, and have single- and double-quoted strings, where only double quoted strings support interpolation and character escapes.

[weswigham]

I like my option (with a function on String). Explicit interpolation all the way~

[toroidal-code]

@nicolasmccurdy right now 'c' and "c" are considered of type Char and String respectively. It's the only really way to differentiate for the type system

[zellio]

I like the ruby style of explicit interpolation via the quoting character. (Which, we could implement by calling an internal function of the String object). It should search it's current scope for variables though. I strongly dislike

"string {{var}}" format var

[zellio]

We can do characters as #\C

[toroidal-code]

@zellio Lol, no Lisp chars plz

[toroidal-code]

If we have macros (as I'm really really hoping we can do) the $"some string {{var}} " could become a macro-transformation on the AST. I'd prefer to have this at either a higher (function) or lower (compiler) level though.

[weswigham]

@zellio I don't like doing automatic binding to scope variables, as it makes it so I can't pass around partially formatted strings, since the formatting is coupled to the scope the format literal was created in.

@toroidal-code If you want to support unicode at some point in the future, you can save work now by nixxing the concept of a 'Char' entirely and acknowledging it as a single length string. A 'Character' is vague and character-set dependent. Character set information can be included with a String - a string is a heavyweight thing. you use chars when you want something lightweight, but once you start including charset meta-information it becomes just as heavy.

[toroidal-code]

@weswigham Brick's Chars can handle unicode just fine, it's OCaml's char type that's ascii-only. I'm going to reference Rust on this one: http://static.rust-lang.org/doc/0.9/std/char/index.html

[weswigham]

Meh, refer to following. Old information is old.