Type inference

[Namek]

Spider is not statically typed language but I believe it's a good option to have. But as I understand you (@alongubkin) don't desire to put it into Spider. But there's alternative which could help a little and wouldn't need to put static typing, I'm talking about type inferencing which has been done for JS already: http://flowtype.org/

First example from the site:

/* @flow */
function foo(x) {
  return x * 10;
}
foo('Hello, world!');

should show error in "compile" time.

hello.js:5:5,19: string
This type is incompatible with
  hello.js:3:10,15: number

I know there are many situations when this could not used anyway but that's just a proposition to have.

[alongubkin]

This is a must. But let's consider first if optional typing is really that bad? Because it's currently the most requested feature.

[Namek]

I don't think optional typing is that bad. To me it's best to have both optional and dynamic. In languages like C# or Java there is Reflection mechanism (somewhat introspection) which is just because it's statically typed. So making typing an option leads to not having Reflection at all and having flexibility of dynamism due to types. In the other hand type inferencing during "compile" (parse) time has to be done when some variables are typed by programmer and some are not.

[Devric]

Well sometimes having type can help on developing frameworks/foundation code for others to use.

I would prefer not to touch the function itself than having a comment parser using jsdoc style to detect the type, so that the code can be used elsewhere that doesn't require compile

eg:

/**
 * 
 * @param {Object} paramName
 * @param {String} paramName
 */

[Namek]

I'm against contextual/informational comments built-in into language itself. OR it has to be so extended that no one can beat it.

@alongubkin how does this issue refer to #82? Shouldn't this one be closed now?