Scala also added string interpolation late. As a point of comparison on syntax and decoding https://docs.scala-lang.org/overviews/core/string-interpolation.html
I share the desire to introduce as little machinery as possible but I don’t think Show is an option, because it will just do the wrong thing far too often. You will easily end up with things like, say, “Hello, (Just “Jos\x0000e9”)” or “Your balance is (fromNumber 14.34)”. Show instances are almost always intended for use in the repl, whereas I suspect this feature would mostly be used in very different settings, eg for generating strings which are to be used in user interfaces. In fact I am struggling to think of any Show instances which will do what you want here other than Int and Number.
1 Like
IIRC Rust has a separate Debug display typeclass for that reason
Probably not worth going down this route, but if we were also trying to replicate JavaScript and its syntax (so that we can just compile to the same syntax, after transforming our variable names inside the literals), tagged template literals don’t necessarily need their expressions and result to be Strings, for eg:
"use strict";
function expression(strings, a, b) {
switch(strings[1]) {
case "+":
return a + b;
...
};
};
var a = 10;
var b = 20;
var c = expression`${a}+${b}`
// c === 30
exports.expression = expression;
// String.raw is the default tag for template literals
exports.raw = String.raw;
exports.mkTag = function (tag) {
return function (strings, ...args) {
return tag(strings, args);
};
};
As tags would now be first class, the user can just pick if they want the Show/Display etc abstraction or not. Biggest limitation of this is that now all expressions have to be the same type, as below I’m using Array a, and not some other ordered product representation. Might be possible to overcome that with a type class however
-- Can't use normal functions to type this, as it has var args
-- JS template implementation guarantees that num strings = num expr + 1
foreign import data Tag :: Type -> Type -> Type
foreign import expression :: Tag Int Int
foreign import raw :: Tag String String
foreign import mkTag :: forall a b
. (Array String -> Array a -> b)
-> Tag a b
class Display a where
display :: a -> String
displayTag :: forall a. Display a => Tag a String
displayTag =
mkTag \strings args -> someIntercalater (map display args) strings
sum = expression`${a}+${b'}`
where
a = 10
b' = 20 -- note this will require us parsing the template and swapping
-- b' for b$prime (or whatever we change it to)
helloWorld = raw`${hello}, ${world}!` -- displayTag`...` would also work if we had a String instance
where
hello = "Hello"
world = "world"
The point of this approach would be to avoid doing as much as possible in the compiler, only require renaming variables inside the template/checking they exist` and marking them as used (or whatever, just so we don’t optimise them away), and then emitting almost the same code as the source purs. Actually I suppose there’s more work than that, like all transformations such as 123 -> 123|0, but I imagine it’s not too difficult to do?
1 Like
as long as Display is a derivable typeclass I think it’s fine.
Tagged literals would also be cool. - it would make it easier to port something like polymer/lit-html into PS
1 Like
I’m not opposed to string interpolation syntax, but it’s a surprisingly complicated feature:
- We have almost no new syntax to give it aside from an escape code in “normal” string literals. Backticks are not an option since we use that for infix expressions. I’m going to assume
\{ ... }escape syntax (or something equivalent like\${ ... }or whatever sigil you choose). - The issue always comes down to how you lex and parse strings then.
- String interpolation must emit a series of delimiter tokens. It’s no longer a single token, but you must have things like
TokStringStart,TokStringMid,TokStringEndto represent the different boundaries because they can contain arbitrary expressions. - We already use
},], and)for other delimiters so this will require a stateful, context-sensitive lexer. It must know that it has emitted string “start” or “mid” token in order to decide how it should lex the delimiter. - Parsing literals is no longer a matter of casing on a single token, but now must consume an unbounded number of tokens.
All of these are surmountable of course, but are also very non-trivial.
I’m going to throw out an alternative using typeclases (and instance chains!):
class Interp a where
interp :: String -> a
instance interpString :: Interp String where
interp a = a
else instance interpFunction :: Interp a => Interp (String -> a) where
interp a b = interp (a <> b)
else instance interpShow :: (Show b, Interp a) => Interp (b -> a) where
interp a b = interp (a <> show b)
i = interp
test = i "foo" 42 "bar" true "baz"
There are a few things to note about this:
- It requires no language changes.
- You can write any interpolation function you want this way (for example, trimming and separating by spaces).
- You can add directives in the middle of interpolation (it can be an extensible DSL).
- It’s the same number characters typed as “normal” interpolation
- With a very simple inliner it will compile to the code you’d write by hand.
14 Likes
I love it 
. I am convinced.
I’m not sure about using Show for anything but basic types but that is now up to the implementor of the function you showed above.
2 Likes
@natefaubion Amazing!
Maybe something like some custom FormatDisplay class instead of Show with some default instances for basic types and some more configurable newtypes too could be packaged up?
@i-am-the-slime, @natefaubion what do you think? Do you have any plans related to packaging this solution?
2 Likes
I don’t have any plans to package this.
Would it be possible to use the proposed implementation as a library?
1 Like
The only issue with this implementation (which is pretty minor considering the brilliance of the solution and the minor inconvenience) is that the first argument must always be a String value.
For example, this code fails to compile:
interp 42 " apples and " 52 " oranges."
Could not match type
Int
with type
String
while checking that type Int
is at least as general as type String
while checking that expression 42
has type String
in value declaration main
I’m not yet sure whether it’s possible to get around that for the below reasons.
If I define a local binding that applies an empty String argument to interp, I can get around this:
main = do
let interp' = interp ""
log $ interp' 42 bar "baz" true
However, using the same binding in two different ways will produce problems:
main = do
let interp' = interp ""
log $ interp' 42 "baz" true
log $ interp' 42 true "baz" true
-- `Boolean` (from true) does not unify with String (from "baz")
This is because of interp :: String -> a, so the initial application is fixed to String. You could probably reformulate this with just interp :: a, or make interp :: a -> b with a multi-parameter typeclass.
I wasn’t sure how to encode the type class using a multi-parameter typeclass. Everything I’ve tried runs into a problem sooner or later. Your solution seems to work only because the first argument is hard-coded to String.
I think if you just change i to be
i = interp ""
you’re good.
1 Like
Right, this is due to (lack of) let generalization. You need a type signature if it’s in a let.
i :: forall a. Interp a => a
i = interp ""
This is generalized in a top-level declaration, but not in a let binding.
Ah… that’s why my original interp' = interp "" didn’t work.
Otherwise, yeah, this works:
i :: forall a. Interp a => a
i = interp ""
So, I’ve created purescript-interpolate to do this, but I’m getting stuck when publishing this library.
How do I fix the issue?
1 Like
Ah, that’s a problem. We will have to amend the instructions for publishing to Pursuit. Thanks for bringing this to my attention!
Library has been published. See its installation instructions. PR to the official package set builds and is awaiting review. If you have an idea for building off of this, see how to refer to it in your bower.json file
Also, don’t use this library when doing a fold (e.g. foldl i "" arrayOfInts) until the inliner optimization is done. See this benchmark, which I hope isn’t naive.
Edit: the above benchmark was implemented incorrectly. See this comment for an accurate one.
2 Likes