Re: [sc-users] string formatting notation

[i@xxxxxxxxxxxxxx]

On 22 Dec 2017, at 15:10, brianlheim@xxxxxxxxx wrote:

> … as we’re not doing it from scratch, the problems created by duplication outweigh the benefits of any change I can think of, at least in my opinion.

OK. Well, there is currently no solution for string interpolation in SC – `"Value is " ++ value ++ "."` is just concatenation – so it would in fact be from scratch. What are your thoughts there?

Well, not sure I have a good solution to offer, just a query and a problem. Query: In many languages String interpolation is provided by formatting anyway. e.g in Python

"{} foo".format(“bar") # or

"% foo" % “bar" # isn’t % actually deprecated in Python 3+? Anyway this is formatting.

is pretty much equivalent to SC:

"% foo".format("bar”)

So I’m not sure why you think there’s no solution in SC. Unless you want this sort of thing (which you can do in some languages):

var barString = "bar";

~interpolated = "${barString} foo"; // if shell script style worked in SC

You can probably guess the problem: If that happens automatically it hoses any existing code that happens to use that character pattern. (e.g. to create a shell script).

So you’d need to trigger it with a message anyway. Interpolate from the current environment would be cool and useful I think. (Maybe already exists)

~barString = “bar”;

~interpolated = “~barString foo”.interpEnvir; // working name

Or have I misunderstood?

S.

> or (more importantly) come up with some coherent design guidelines that would apply

Feel free to propose some. It would be great if we could have some guiding principles for language evolution. I don't suggest these sorts of language changes very often so I don't have strong opinions yet.

-Brian

On Fri, Dec 22, 2017 at 9:04 AM, brian heim <brianlheim@xxxxxxxxx> wrote:

> Note that also python added .format after they had
> % for a long time (why? because % is less flexible:

This comparison is not accurate. The notation is similar, but unlike Python, SC `%` would have all the capability of .format. That is to say it (a) wouldn't fail on attempting to format a collection type and (b) would support all the types format does.

The problem of the variable name being far from the point of insertion is definitely valid though.

I actually wasn't aware of f-strings until now actually, that seems like a great feature and clever solution. Kind of like C++'s raw string literals. (http://en.cppreference.com/w/cpp/language/string_literal)

On Fri, Dec 22, 2017 at 9:03 AM, <i@xxxxxxxxxxxxxx> wrote:

> On 22 Dec 2017, at 13:30, <brianlheim@xxxxxxxxx> <brianlheim@xxxxxxxxx> wrote:
>
> Ok, you bring up some good points! Rather than respond directly, I think I'll take a step back and ask:
>
> 1. Do you agree string formatting and/or string interpolation could be done better in SC?

Well, I’ve not given it a lot of thought, but I’m sure if we were doing this from scratch, we could come up with some method that was better according to some criterion, or (more importantly) come up with some coherent design guidelines that would apply. But...

> 2. What are some ways we could make it better that would be less harmful than the % approach?

… as we’re not doing it from scratch, the problems created by duplication outweigh the benefits of any change I can think of, at least in my opinion.

S.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/