Convert a List to a String

Is there a function to (elegantly) convert a list to a string, possibly with a specific delimiter?

{“a”, “b”, “c”}


a, b, c

I tried this ASOC sub-routine but it doesn’t work.

Hi there,
Is this any good?

set theList to {"a", "b", "c"}

set {TID, text item delimiters} to {text item delimiters, ","}
set theListAsString to theList as text
set text item delimiters to TID

theListAsString  --> a,b,c

Thanks TecNik.

So I guess there’s no native function or one-liner for this.


Here is a handler that does the conversion for you.

set theList to {"a", "b", "c"}

set aString to newString for theList against ", "

log aString
--> "a, b, c"
on newString for someList against Delimiters
	set astid to AppleScript's text item delimiters
	set AppleScript's text item delimiters to Delimiters
	set newText to items of someList as text
	set AppleScript's text item delimiters to astid
	return newText
end newString

Yeah, I don’t think there is a single liner unless you use some sort of scripting addition.
I’m sure someone will point us in the right direction if I’m wrong.

There is most certainly a one-liner:

set theList to {“a”, “b”, “c”}

theList as text → “abc”

Calls to the handler McUsrII posted would be one-liners.

By the way, I’ve always been curious as to why people who use the list method to store and set text item delimiters only use it at the beginning. It’s often possible to use it at other stages of the process too:

set theList to {"a", "b", "c"}

set {TID, text item delimiters} to {text item delimiters, ","}
set {theListAsString, text item delimiters} to {theList as text, TID}

theListAsString --> a,b,c

Hi Craig. You’re forgetting the delimiters.

There must be something deeper than this.

set the_list to {"a", "b", "c"}
the_list as string

As stated above which I didn’t see earlier.

What Craig uses is coercion which is built in to AppleScript. But this is too easy. There’s something missing maybe.


Yeah, I did not read the whole post. Sorry.

Thanks everybody. For now the prize goes to Nigel’s 2-liner :slight_smile:

One more question. Is there an actual difference between ‘AppleScript’s text item delimiters’ and ‘text item delimiters’?

I wasn’t just thinking of msh’s mention of using a specific delimiter. It’s also a good precaution to set the TIDs explicitly before coercing a list to text and not just assume they’ll be the default {“”}.

I actually use the four-line version myself, simply because not having to set up lists makes it slightly faster in action. :slight_smile:

One thing about setting things by list (and the reason it can’t be used to make a one-liner here) is that all the values in the right-hand list are got at the same time and are THEN applied to the items in the left-hand list. So if you’re of an obfuscationist turn of mind, you can often arrange the lists in non-intuitive ways: :wink:

set theList to {"a", "b", "c"}

set {text item delimiters, TID} to {",", text item delimiters}
set {text item delimiters, theListAsString} to {TID, theList as text}

theListAsString --> a,b,c

No. Not really. In theory, it’s possible for an application to implement its own text item delimiters, in which case it might be necessary to specify which was to be used. There used to be such an application in the past, but I don’t remember which it was.

FWIW, it works fine – but you need to be running Yosemite or using it in a script library in Mavericks. And it needs a use framework “Foundation” line.

That page says the samples are for AppleScriptObjective-C applets, created in the AppleScript Editor via the File > New From Templates menu, which all support it.

It’s a bit dated…

The other reason to include the AppleScript’s is so that you can use it within an application tell block – without it, you get an error.

Could you elaborate on that? Do you mean setting lists would actually require more assignments in the end?

It’s quite intuitive when you debug it :stuck_out_tongue:

Just for the record, that wasn’t the original code that Nigel Garvey posted in post #7. The code above, does things in the wrong order, first you save the tids, then you set them, then you coerce something to text, and then you restore them.

However, there is a good readup on variable types here. I also think, that with AppleScript vesion 2.3 the text item delimiters are reset to whatever they was, when a script has finished executing, so nowadays, only three lines are needed, or one line, if that it is the only usage of a text item delimiter in a script.

set ml to {"a", "b", "c"}
set {text item delimiters, newText} to {", ", (items of ml as text)}

(Resetting the tids nowadays, is just a convenience, for backwards compatibility).

It’s really nothing to do with which version of AppleScript – the change has been in Script Editor. It used to use the same component instance of AppleScript for all documents, but changed to using a separate instance for each document (probably each compile, these days).

I disagree. There are examples where it can easily get you into hot water, especially if it’s done in handlers.

I agree, it isn’t only Script Editor that creates a new instance of AppleScript for a single script. (I tested it in Script Debugger).

So, I was wrong. I’m glad I got that sorted out. :confused:

Yeah. I don’t pretend to know all the details of what goes on under the bonnet in AppleScript, so don’t take this too authoritively. But the four-line version directly sets four “variables” to four values. Simple and fast. The list version sets the same four variables to the same four values, but in the process also creates two lists to hold two each of the values and then retrieves the values (or the pointers to them) from positions in these lists. The extra time taken is too minuscule to be measured over just a few executions, let alone to be noticeable to a user. But it’s something to think about if you’re writing a library of handlers and don’t know how intensively any future scripts you write might call them ” or if you simply like to know that the code you’ve written is a nanosecond or two faster than the way you didn’t write it. :wink:

The above considerations mostly apply when the values are supplied ” as in this case ” by vanilla AppleScript. If you’re getting a whole load of values from an application, the list method of setting variables may often turn out to be faster. It’s to do with the time it takes to communicate individual commands to applications and to receive their responses and with what the applications have to do internally to retrieve the information you require. So it depends on the application involved and how much of what information you need.