Why is there no 'int' type?


#1

I keep getting burned by this — chaiscript is essentially very close to being a C/C++ language but I want to declare an integer variable I have to remember to say

var i;

rather than

int i;

Why this decision? Can we have an int type?


#2

Hi,

If you want to declare an integer you can do like this :

var i = int()

But if you want a function to receive an integer you can do as in C++:

def fun(int i)
{
}

That’s all I know :wink:


#3

Yeah, I know — but that’s the thing — ‘int’ works sometimes and not other times. That’s why I keep getting burned.


#4

I believe it would be very difficult to allow optional typing of variables without breaking something else. Function parameters are a specific context and have a specific meaning - allowing for creating overloads.

If you want to take a crack at updating the parser, I’d probably accept the patch, if all unit tests pass.

OTOH, here’s one way to look at it. By requiring var or auto I am pushing you to use the best-practice of “never declare a variable until you can give it a meaningful value.” :slight_smile:


#5

Jason, I think you’re misunderstanding — I’m 100% in favor of both strong typing AND explicit variable declarations.
The problem I’m having is the use of ‘var’ INSTEAD of the actual type.

I understand (I think) the difference in scoping rules with ‘global’ vs ‘var’ although I’m not sure I understand the point of the latter unless perhaps one is doing 100% functional programming.

I guess that if I had been involved in the language design, I would have argued for syntax such as

<type declaration> ::= <type> [<scope>] <identifier ';' ;
<scope> ::= 'local' | 'global' ;

and so could write

int i;

or

int global i; // global would be the default if 'local' wasn't used

This would make the language closer to C/C++ in basic usage.

I haven’t looked at the source for chaiscript? How did you build the parser? Did you use a grammar definition (or even better an attributed grammar) and a parser generator or did you handroll the parser?


#6

I understand, my point was if you do:

int i; // undefined value in C++ in most contexts
auto i; // invalid, you did not initialize it in C++
auto i = 0; // valid, initialized int of value 0, also valid in ChaiScript, `auto` and `var` are synonyms
global i = 0; // also valid, it's an initialized int that's global

I have considered allowing explicit typing as you suggest, but it has been very low priority (yours is the first actual feature request for it).

No parser generator or grammar definition was used to create the parser. Indeed, overloading based on type, as you can now, ie:

def f(int i) { }

Was added very late in the language development.

originally you would have had to do:

def f(i) : is_type(i, "int") { } // use a function guard

So, in other words, its been an evolution.

Of course, ever since Type:: notation was added you could have done this:

def int::f() { } // type based selection using method definition syntax

Anyhow, there’s some history.


#7

I am fine with
int i = <expression>

I always do that anyway (I should have included required initialization along with variable declaration and strong typing :slight_smile: )

It’s just the use of a non-standard identifier (i.e. ‘var’) rather than a well known typename (i.e. ‘int’) in front of the variable name that keeps biting me.

I keep wanting to write

int i = 42;

and then have to deal with the syntax error and rewrite it as

var i = 42;