concatenanation (++) on a Symbol should stay a Symbol

[olafklingt]

On the mailing list a reoccurring question is why does a concatenation (++) of a symbol with something else does not stay a Symbol.
As other implementations of ++ are also aware of the Species of what is concatenated I suggest that it would be appropriate when Symbol would do the same.

[telephon]

Yes this might be right. But to be sure, let's see the way it evolved. In earlier versions of sclang, species would return (if I remember correctly) just either Array or String. So the system was simple: many operations on collections would simply return an array, and you would, after a series of operations, convert back to the class that you had started with. In most cases, this makes the most efficient procedure the default one.

Later, we decided that it was not so good that you had to write a conversion explicitly in the case of Set, where it is likely not to be efficient either. So we added to Set: species { ^this.class }.

Now indeed, ++ is a case where there are many more classes that implement it, and the receiver's class is a common return value.

Here is and overview of the current cases:

SequenceableCollection -> this.species
SparseArray -> SparseArray
Char -> String
Stream -> Stream
ArrayedCollection -> this.species
String -> String
Collection -> this.class
Nil -> the receiver class
Dictionary -> this.class
Symbol -> String
Pattern -> Pattern

(edit)

Here is the same divided into two groups:

// uniform:
SparseArray -> SparseArray
Array -> Array
String -> String
Collection -> Collection (via this.class) (Set, Range, Interval, Pair, Bag, various dictionaries)
Dictionary -> Dictionary (via this.class)
Pattern -> Pattern (may behave differently)
Stream -> Stream (may behave differently)

// non-uniform
SequenceableCollection -> Array (via this.species)
ArrayedCollection -> Array (via this.species)
Char -> String
Nil -> the receiver class
Symbol -> String

[telephon]

So one thing that we should keep in mind: if you do something like the following:

a = \rocky;
1000.do { a = a ++ "abcdefghi".choose };

this will create 1000 new symbols in the symbol table, if you change the current behaviour.

while it can be written like this, without this side effect:

a = \rocky;
1000.do { a = a ++ "abcdefghi".choose };
a = a.asSymbol;

If I see it correctly, we already have a "leak" in the symbol table when you varying send strings over OSC, but that is another issue: #1029.

[olafklingt]

ok that is to some degree an issue when you do something like
\gain++++\off++++6++\th++_+\filter
...
when does something like this becomes in a real world scenario a problem?

The other cases of non-uniformity are logical
the collections are classes can not be used directly:
SequenceableCollection -> Array (via this.species)
ArrayedCollection -> Array (via this.species)

two chars are a string i would say.
Char -> String

I am unsure about the behaviour of Nil.
Nil -> the receiver class

1. leave it as it is
2. return an error because why should ++ be implemented for Nil ?

[telephon]

when does something like this becomes in a real world scenario a problem?

I am not sure, it may amplify the issue described above when generating a lot of names. In any case, should we change it, we should not forget to document that the new usage is gain.asString ++ '_' ++ \off ++ _ ++ 6 ++ \th ++ _+\filter.

The other cases of non-uniformity are logical. the collections are classes can not be used directly.

You can use them directly: a = ArrayedCollection[]; that a = SequenceableCollection[]; throws an error is a bug, I think. But you are right that normally they are not used directly.

The Nil behaviour is intended, and well decided, I think. Also changing it would break a lot of code in weird places.