I hit that mine too with my first implementation of pass1(), and was a little frustrated that the tree wasn't accepted and I had to refactor.

That said, and to be fair, the grammar for expression and term does define the order the tree should be built in, altough it could be a nice gesture to explicitly state the associativity in the description too.

But your tree does not seem to conform to the associativity described with the grammar syntax? The grammar does not allow for expression on the right.

Honestly pretty disappointed that the tests only accept a certian tree for pass1. I really like the way I implemented it with the tree going the other way but now I have to refactor everything to get it going the other way and I'm having a really tough time of it.

for example 1+2+3+4

right: Add (Add (Add (Imm 1) (Imm 2)) (Imm 3)) (Imm 4)

wrong: Add (Imm 1) (Add (Imm 2) (Add (Imm 3) (Imm 4)))

Very nice kata! Even though it is a very simplistic language, it is cool to have actually witten a (simple, but real) compiler.

It would have been nice to have the Ast classes (C#) provided just like the simulator to easily be able to play with it in your own dev environment (they were easy enough to recreate, but still).

ok thanks

Do you understand that you're comparing NESTING STRUCTURE, right? Read the description again if not. You're not comparing data types.

Complete the function/method (depending on the language) to return true/True when its argument is an array that has the same nesting structures and same corresponding length of nested arrays as the first array.

It doesn't say anything about each element datatype matching. You can think of the list elements like list and not a list (it doesn't matter which datatype is) if you want.

[1,'[',']'] same as ['[',']',1]
[nal,nal,nal] same as [nal,nal,nal] nal: not a list

[1,[1,1]] not same as [[2,2],2]
[nal,list] not same as [list,nal] not the same

not the same INT is not equal STR.

The nesting structure is the same, not a kata issue. The data type doesn't matter, unless it is a list, because they can be nested, unlike the other data types.

Test that is wrong:

Test :
Testing to see if you tried a certain short-cut
[1,'[',']'] same as ['[',']',1]: False should equal True

3 elements but the first is INT and the first in the second is STR then is False not True

in the example test
test.assert_equals(same_structure_as([1,[1,1]],[[2,2],2]), False, "[1,[1,1]] not same as [[2,2],2]")

2 elements but the first id INT and the first in the second is LIST then is False

the description states:

In this kata, you will create a simple, immutable, singly-linked list.

Typically, a ListNode will be implemented as an object with 2 properties, value and next. If the lists are immutable, the value and next for a given ListNode (uniquely identified by its address in memory, not directly accessible in JS but can be checked for equality with ===) never change. If that's a given, there are only two operations you can do: 1) create new nodes, and 2) possibly make them point to already existing (sub)lists for memory efficiency.

So if you already have a list (c d), and you want to append (a b) to it, you only need to create 2 new nodes a and b. Similarly, the remove() operation can be optimized by re-using the longest common suffix to the source list and the new, filtered one.

Immutable, memory-optimized singly-linked lists are typical of functional programming. But I can see how the current description can confuse a reader who is not familiar with them. The problem is that if the full algorithm was spelled out the kata would become less interesting in my opinion. Do you have a suggestion to improve it ?

Thing is, that one doesn't make any sense to me. At all.

If you have a list, it will never contain different things than it does at the moment

It seems to me that it is actually well-defined (from a mathematical point of view) if you keep in mind that:

If you have a list, it will never contain different things than it does at the moment

AND

new list shares as many nodes as possible with orig

If you apply both of these points, there is only one way to implement the push/append/remove operations, I think. Can you give an example of an operation that would be ambiguous ?

the error is in your code, at this line:

EmptyList.prototype.push = function(x) {return new ListNode(x, new EmptyList());};

You create a brand new EmptyList() for no reason there, you can reuse the current one instead

OP solved the kata

you are creating a brand new list of 4 allocated nodes when concatenating 2 lists of 2 nodes each, instead of reusing the latter 2.