Maintain Syntax Compatibility with ES6 where possible and sensible

[nmn]

There are some features already implemented in Spider that have a similar but different syntax compared to ES6. These should be made consistent.

Examples I can think of:

• Splats. ES6 uses ...rest, spider uses rest...
• use / require vs the ES6 Module syntax
• Class Syntax (already mentioned)
• Interchanged for-of should work with objects as well.
• List Comprehension:
  • ES6 : [for x in list x * 2]
  • Spider: [x * 2 for x in list]

[Skalman]

I agree that Spider should follow ES, unless there's a good reason to change the syntax. Another example:

• Template strings/string interpolation: ES uses 1 + 2 = ${1+2}, Spider uses "1 + 2 = \(1+2)"

[nmn]

@Skalman that is actually one place where I like the spider syntax! Though it does fall into the 'stay consistent with syntax where possible' principle.

I think in this case ES6 had to come up with a strange syntax to not break existing strings. Spider can possibly support both formats. As the template strings can be used for powerful functions as well.

Well, in any case, I'll be fine either way on this issue.

[alongubkin]

I think in this case ES6 had to come up with a strange syntax to not break existing strings.

Exactly. Why maintaining compatibility with ES6 is a goal?

[jedahan]

Maybe for making it easier to transition into/out-of spider. I think the changing syntax for the sake of changing syntax is not that compelling. Changing syntax for improvements in readability, go for it.

"\()" vs ${} is a good example of unnecessary differences.

[nmn]

I think it makes sense to have the same syntax as ES6 for identical features. Again, I really like the swift string interpolation syntax, but I still get why keeping the #{} syntax makes sense.

However, Spider does have unique features and some unique syntax sugars, and there is no need to make everything identical to ES6

[alongubkin]

Splats. ES6 uses ...rest, spider uses rest...

Even though they're similar, splats and rest parameters aren't the same thing. Spider's splats are much more powerful. For example, in ES6, you can't do:

function (a, b, ...c, d) {
}

---

use / require vs the ES6 Module syntax

use is not related to modules. ES6 module syntax was added in 0.1

---

Class Syntax (already mentioned)

This is a larger discussion. Should we add classes to Spider? #28

---

Interchanged for-of should work with objects as well.

There are 2 reasons I separated for-in and for-of:

1. Better readability. For example:

   for apple in apples
   for property of file

2. The ability to get index or value. For example:

   for apple, i in apples
   for property, value of file

---

List Comprehension

Readability. For example:

• Spider: var fileNames = [file.name for file in files if file.size > 100];
• ES6: let fileNames = [for file in files if (file.size > 100) file.name];

---

Template strings/string interpolation: ES uses 1 + 2 = ${1+2}, Spider uses 1 + 2 = \(1+2)

This was a purely opinionated decision. I just think that \(x) looks better than $(x). Do you think we should change it?

[nmn]

Here is my opinion on these things.

Splats:

I understand that the splats in Spider are more powerful. But the intention is the same as ES6 splats.

Also, from a readability point of view ...rest and rest... are not that different. Just for the sake of consistency and making things easier for Javascript development, I think the ES6 way makes more sense in this case. Spider can have a much more powerful splat with the same syntax.

Module Syntax:

If ES6 module syntax has been added, this part is pointless for discussion.

Class Syntax:

Let's keep this discussion in the other issue.

for-of vs for-in

I think it makes sense to use only for-in for all sorts of loops, and make things simpler by having fewer types of loops.
ES6 is trying to do the same thing and for-of is intended to replace for-in. for-in has to be kept around for compatibility reasons.

List Comprehension

I think the readability in this matter is a meaningless argument. It's like active and passive sentences in English. ES6 and Spider (taken from Python as far as I know) are both readable to me, but again, I think using the ES6 syntax will keep things more consistent for JS developers.

Template Strings / String Interpolation

In this case I'm biased, and I like the Spider syntax \(). ES6 syntax was stolen from Coffeescript. I also dislike Coffeescript quite a bit.

Summary:

I don't want this to be a long discussion, and I think, @alongubkin as the author of Spider you will have to make a call on the best syntax.

My thinking behind this issue is this:
Spider is primarily targeted at Javascript developers, who want a better version of the language free from legacy baggage. Spider is not like Coffeescript, which was targetted at devs who didn't like Javascript and wanted something more like Ruby. It's also not just a bridge from another existing language like Clojurescript.

Keeping that in mind, I think it makes sense to just port of javascript as-is, where changing the syntax doesn't have a benefit. (you have done this for many other parts of Spider).

/end of opinion outburst.

[alongubkin]

Splats - I agree, let's change that to ...splat.

Loops - Splitting ES6 for-of to for-in and for-of gives us more power and readability, so I think we should keep them the way they are.

List Comprehensions - I don't think readability is a meaningless argument here. Sure, it's a minor one, but it still exists. The reason why I think we should keep the Python syntax is:

Spider doesn't require parenthesis around the test expression in an if statement. So the following code in ES6:

[for file in files if (file.size > 100) file.name]

would become the following in Spider:

[for file in files if file.size > 100 file.name]

so the only thing that separates between the condition's test expression and the result expression is whitespace, and that's a source of confusion.

Moving the result expression before the for keyword makes the code more readable:

[file.name for file in files if file.size > 100]

[nmn]

Cool. I see your point. I agree.

On another note, would like some more documentation around for-in for-of.