In what way is that unexpected, given then & is string concatenation?

& is normally (= in C) a bitwise operator, not a string concatenation. Especially looking strange for me when it makes a string out of two numbers.

I never claimed for GorillaScript to be a C-like language, because at its core, stripped of syntax, JavaScript is not a C-like language.

It more resembles LISP with its macros and closures with nice syntax built around those concepts.

I tried to make all the operators match their closest arithmetic, mathematical equivalents. Thus using `^` for exponent and `+` for addition. Since JavaScript does not support bitwise operators cleanly, needing to cast to int32 and generally being disued, I felt they could be better aliased with `bit`, freeing up those operators. Since string concatenation needed some operator as a building block for string interpolation, the freed-up `&` was a ripe candidate for it.

That all said, string interpolation is the typical use case for creating strings, so feel free to just use that if possible. Anything more than that and you might need a templating engine.

What do you think about not using any operator (but space+"") for concatenation and using a syntax like this:

    var 1   = 5+5 // I would expect: Error 0-9 cannot be used as a variable
    var foo = "Hello " "Bob!" "\nAre you there?"
    var bar = "Hello " 1

    console.info(1) // throw error and refer to var 1

    console.info(foo)
    "Hello Bob!
    Are you there?"

    console.info(bar)
    "Hello 1"

Juxtaposition as an operator is already used by function invocation, e.g.

    f "Hello"

If f were a string, how would I know I wanted to concat it instead of calling?

By not making () optional. Honestly I get why people hate curly braces, but parenthesis are important, removing them makes a new language hard to understand, making it optional makes the language (horrible or) simply weird and non-deterministic.

There is ZERO technological or efficiency related benefit in making () optional, it just makes your grammar parser more complex and slows down compile/interpretation time.

If I would have time and no specs given, then I would write a compiler for Sanskrit. It's one of the oldest languages and as accurate as AI Agent languages. Really accurate. Just google for "Sanskrit Artificial Intelligence" and you will find very interesting publications. Here's something by NASA: http://www.vedicsciences.net/articles/sanskrit-nasa.html

Btw. I've written a simple language+vm in C already using bison,flex etc. Our Prof and other students made a custom CPU that runs on a custom OS made for this language called Ninja. A friend of mine extended it by Object Orientation later.

I realize you probably also wanted to answer OP, but let me just state that there was no real judgement intended. I am not a C-programmer, it was meant as an explanation.

> Thus using `^` for exponent and `+` for addition

That is good in my eyes.

"a" + "b" == "ab" is an unexpected result for C.

Well, because '&' is probably not a very good choice for a concatenation operator since it has a very different meaning in most of languages. Most developers would overlook such an error.

Of course you can say that since it is defined as such, it's not a issue, but then we could say that any Javascript "Wat" behavior is also defined in the spec.

I would say that & is a fine choice (much better than +) for a concatenation operator. It allows numbers to be built like strings in an interesting way and keeps the meaning of the & consistent. It really is past times that every language needs to conform to the choices made by C.

+ has problems as string concatenation, but that doesn't make & a good choice. We still use a lot of C-ism's because people are used to them, and any deviations from C-like behavior, which at this point could be called "common behavior" just increases the learning curve and the cost of a context switch.

Personally, I like Perl's period(.) for string concatenation, but I think it can too easily get lost in the line, especially for more complex stuff.

     $foobar = "foo" . $bar->{'bar'}

Period has a general meaning of ending a sentence. At this point in our history, people willing to clear the deck of C-ism should be encouraged. I think the learning curve is worse when folks imitate C for no reason other than computer tradition as opposed to building something that feels tied together. We ditched a lot of older habits with C, we should continue the path.

& is not only a bitwise operator, but also a set arithmetic operator in many languages (Ruby and Python, for examples).

In production code, using & for string concat is pretty atypical, since you can use string interpolation: "$(alpha)$(bravo)"

I have always liked ~ for string concatenation. Looks like a little string tying the strings together, and hardly likely to be confused with the bitwise not operator.

I thought about it, but for the most part I used `~` as a way of referring to something in an unstrict way, e.g. `~+` doesn't typecheck, it just adds and auto-coerces both operands to a number.

I didn't want to have `~` mean string concat because it overloads the semantic meaning of what `~` would represent.

I actually stole `&` from VB, as well as `\` as floor division.

Where is a ~ used for string concatenation?

D uses it too. I think they use it for array concatenation as well.

Perl 6 does...I can't recall anywhere else, though.