in progress :)

oh, i didn't know about that, thanks for the information

Can you explain why if accepts a predicate value instead of a thunk, while for and while predicates accepts a thunk? This is not how typical languages handle if statements with side effects.

It was never specified that multiple values can be in _case. This only occurs in the test cases.

The question below should be an issue: const is only tested for direct assignment.

(Also, I don't agree that const variables can be deleted. It's const after all. In almost all languages you can't do this either.)

Related: You only gave primitive examples of the expected behaviour in terms of a giant code block. This is not acceptable as kata specification.

For a proper language you need to specify the syntax of the language (what goes after what), what goes into each argument, the expected order of evaluation, etc. Otherwise this is more of a toy project than an actual kata.

There are no random tests.

The test setup is incorrect: it blocks in Mocha are run in async parallel, so you cannot depend on each it block running one after another.

Each it block should create its own Language object from scratch and test from there.

(Test frameworks that uses describe/it structure in other languages also does this in general, btw)

I think it's possible, because I didn't think that far ahead, in this KATA I just want to make it simple, not too complicated

Can variables be redefined from mutable to immutable and back? example:

lang.const.x(10);

lang.x // 10

lang.const.x(20);

lang.x // 10

lang.let.x(15);

lang.x // 15 or should it still be 10? and vice versa from let to const

im aware of how the javascript language works, but with regards to this language we're creating in the kata, it isn't clear how this should behave

and that is a perfectly good reason :]

sorry, its misstype

i use do because i want to use it

// if else
lang.if(/*condition*/)
       .do(/*some function*/)
    .else(()=< lang.d = 'aiueo')

That =< in else is supposed to be a => I guess?

Why is it if .. do instead of if .. then ? ( Yes, it's customisable, and arbitrary, but why not go with what JS itself does? )

1. There should be an introduction to the problem, something like:

You have to create a literal function range. These examples should explain what the function should do: ...

2. Multiple filters given to the function should be added to the description (user shouldn't have to attempt to know that it's invalid), you can add it in the example or explain it in its' own section.
3. The note section in the description is not formatted correctly (you need to use <br> or add another blank line between the two texts).

Good start but this is only one type of input. There is also the range with only upper bound and ranges without filtering function, and since you've also specified invalid inputs, some of them should also be included in the random tests.

This kata adds the filtering function, so in a sense it's a mix of multiple basic tasks (parsing the range, generating the filtered range, handling multiple arguments and their types). I don't know if this is a good or a bad thing.

like that?

Missing random tests.