Variable initialization/assignment questions

Variable initialization/assignment questions

Bild des Benutzers Minh-Nhut Hong

1) Is it possible to define a variable and initialize it later?
For example, var x;
x = 1;

2) Can type of variable change after its first definition?
For example, var i = 1;
i = 2;
i = 2.0;
i = "i";

22 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.
Bild des Benutzers 邓辉
var i = 1;
free(i);
vari = "i";
free(i);

This is valid

写字楼里写字间,写字间里程序员 程序人员写程序,又拿程序换酒钱 酒醒只在网上坐,酒醉还来网下眠 酒醉酒醒日复日,网上网下年复年
Bild des Benutzers mdma

Is reassignment valid, or does this exit with an error? var a = 1; var a = 2; output(a);

Bild des Benutzers Minh-Nhut Hong

3) Is it possible to define
var i = -1;
var j = -(1 * 2 - 3);

4) What happens if there is reference to undefined variable or assignment to undefined variable?

5) Is it possible if we can have syntaxBNF for the parser so we have less syntax questions?

Bild des Benutzers DweeberlyLoom
Quoting Minh-Nhut Hong 1) Is it possible to define a variable and initialize it later?
For example, var x;
x = 1;

2) Can type of variable change after its first definition?
For example, var i = 1;
i = 2;
i = 2.0;
i = "i";

I can only guess of course, but I would say that for #1 the answer would be no. Since we have to infer the type from the right hand value. Without a right hand value we would have no way infer a type.

#2 would also be no, the pdf states that the 'i="i"' (changing the type from numeric to string) should be an error.

Bild des Benutzers DweeberlyLoom
Quoting mdma Is reassignment valid, or does this exit with an error? var a = 1; var a = 2; output(a);

My guess is no, since there is no "free" between the two var statements I think an error should be generated.

Bild des Benutzers DweeberlyLoom
Quoting Minh-Nhut Hong 3) Is it possible to define
var i = -1;
var j = -(1 * 2 - 3);

4) What happens if there is reference to undefined variable or assignment to undefined variable?

5) Is it possible if we can have syntaxBNF for the parser so we have less syntax questions?

The PDF says we can map types to standard types such as signed integer, signed double ... so I would expect the definitions in #3 to be value.

#4 an error condition should be generated

#5 I agree that would be helpful

Bild des Benutzers Rama Kishan Malladi (Intel)

Hi,
# 1 is possible. You can support this feature of declaring on a source line and defining on another.

# 2: This is possible as we defined integer to double is an implicit typecast that parser would support:

var i = 1;
i = 2;
i = 2.0;

The following.... i = "i" .... isn't possible.

Thanks
-Rama

Bild des Benutzers Rama Kishan Malladi (Intel)

Hi,
#3 possible and valid.

#4, error to be printed in the output file and parsing stops.

#5, can you indicate what are other aspects you looking regarding syntax?

Thanks
-Rama

Bild des Benutzers mdma

I'm surprised #1 is allowed - the spec always declares variables and initializes them in the same statement. This is good, since it keeps the parser simple. IMHO, uninitialized variables just complicate things further. If uninitialized variables (#1) are allowed, what is the behaviour of using an uninitialized variable? Is it a runtime error?

Bild des Benutzers mdma
QuotingRama Kishan Malladi (Intel)
#3 possible and valid.

can the judges please double check this - #3 includes a unary negation operator..that's not mentioned anywhere in the spec. At present, the 4 operators take 2 operands. Seems this thread is turning into a list of ad hoc changes.

Bild des Benutzers Rama Kishan Malladi (Intel)

Hi,
I got your point now. Yes, I mark this as invalid as it contains a unary negation operator which didn't indicate as supported in the problem statement. So #3 isn't supported.

Thanks
-Rama

Bild des Benutzers akki
Quoting mdma I'm surprised #1 is allowed - the spec always declares variables and initializes them in the same statement. This is good, since it keeps the parser simple. IMHO, uninitialized variables just complicate things further. If uninitialized variables (#1) are allowed, what is the behaviour of using an uninitialized variable? Is it a runtime error?

I agree with mdma. Uninitialized variables complicate matters.

Bild des Benutzers Rama Kishan Malladi (Intel)

Hi,
I would want us to focus onthe parallel aspect/ implementation of the parser. So, yes, we can relax these criteria of uninitialized variables. So, #1 is not allowed - i.e., variables have to be initialized at declaration. This wouldn't add much to the problem statement; instead adds complexity. Happy coding :-) !

Thanks
-Rama

Bild des Benutzers jimdempseyatthecove

I agree, unary operators should be covered in the rules as to permitted or to be rejected
Same with multiple unary operators:y = ++-+--x

Jim Dempsey

www.quickthreadprogramming.com
Bild des Benutzers DweeberlyLoom
Quoting Rama Kishan Malladi (Intel) Hi,
#3 possible and valid.

#4, error to be printed in the output file and parsing stops.

#5, can you indicate what are other aspects you looking regarding syntax?

Thanks
-Rama

I believe this is more an issue of disambiguating the syntax. For example I learned in this thread that var x; is valid which means that you dont necessarily know the type when a variable is declared. In another thread I learned (or think I learned) that statements cannot span lines and that strings are composed of only [A-Za-z0-9] and space. This makes parsing much easier (as well as making ; line termination syntactically unnecessary, but still required). A BNF (or EBNF or ABNF) would collect this information in a terse and (mostly) unambiguous package. Something like (expressed in unverifiedDLBNF - Dweeberly Loom BackusNaur Form ;-)):

letters = [A-Za-z]

digits = [0-9]

int = [-|+]* [digits]+

real = [-|+]* ([digits]*[.])* int

space = [ ]

quote = []

lineterminator = [space]* ; [space]* [\r]{0,1}[\n]

string = quote [letters|digits|space]{0,256} quote

stringFunc = string [space]+ ([space]* [varname|string|int|real] [space]* )

varname = [letters]+ [letters|numbers]*

assignmentOp = [space]* = [space]*

additionOp = [space]* - [space]*

subtractionOp = [space]* + [space]*

multiplicationOp = [space]* * [space]*

divisionOp = [space]* / [space]*

mathOp = [int|real] [additionOp|subtractionOp|multiplicationOp|divisionOp] [int|real]

math = ([int|real] mathOp [int|real]) (mathOp [int|real])*

mathgroup = [-|+]* ( [math|mathgroup|int|real|powFunc|sqrtFunc] )

powFunc = pow( mathgroup )

sqrtFunc = sqrt( mathgroup )

concat = [(]* string additionOp string [)]*

assignStmt = [space]* varname [space]* (assignmentOp [string|stringFunc|int|real]){0,1} lineterminator

varstmt = var [space]+ varname [space]* (assignStmt){0,1} lineterminator

freestmt = free [space]+ ([space]* varname [space]* ) lineterminator

outstmt = output [space]+ ([space]* [varname|string|stringFunc|int|real] [space]* ) lineterminator

Bild des Benutzers john_e_lilley

I think that this: real = [-|+]* ([digits]*[.])* int should be this: real = [-|+]? ([digits]*[.])? int

Bild des Benutzers john_e_lilley

mmmm, actually I think there are several technical problems with this syntax. Not to be difficult, but I think that e.g. this is wrong:

mathOp = [int|real] [additionOp|subtractionOp|multiplicationOp|divisionOp] [int|real]

math = ([int|real] mathOp [int|real]) (mathOp [int|real])*

I've also posted a syntax here... I think its a little better although there are still some questions. I don't really care what gets used, but it would be nice to agree on something:
http://software.intel.com/en-us/forums/showthread.php?t=83348&p=1#152288

Bild des Benutzers Minh-Nhut Hong

Rama,
Regarding #5, I am wondering if you can release your formalsyntax definition to the public.

Bild des Benutzers john_e_lilley
Quoting Rama Kishan Malladi (Intel) Hi,
I would want us to focus onthe parallel aspect/ implementation of the parser. So, yes, we can relax these criteria of uninitialized variables. So, #1 is not allowed - i.e., variables have to be initialized at declaration. This wouldn't add much to the problem statement; instead adds complexity. Happy coding :-) !

Thanks
-Rama

Does this also mean that later assignment independent of declaration is also invalid, e.g.:

var x = 1;

x = 3;

Bild des Benutzers DweeberlyLoom
Quoting john_e_lilley mmmm, actually I think there are several technical problems with this syntax. Not to be difficult, but I think that e.g. this is wrong:

mathOp = [int|real] [additionOp|subtractionOp|multiplicationOp|divisionOp] [int|real]

math = ([int|real] mathOp [int|real]) (mathOp [int|real])*

I've also posted a syntax here... I think its a little better although there are still some questions. I don't really care what gets used, but it would be nice to agree on something:
http://software.intel.com/en-us/forums/showthread.php?t=83348&p=1#152288

Oh yea, my ~BNF might be completely wonky. You are certainly correct that the above isn't correct, I shouldn't have put the [int|real] items in mathOp.

The [-|+]* was intentional because I thought something like ---(1) should be valid.

Still I'm very much like you I don't really care what is used as long as it's clear nuff to code to. I'll take a look at your thread, hopeful the Intel folks will be able to take one (or both) of these and tune it to communicate the exact structure of the language.

Bild des Benutzers gaston-hillar

John, The situation you mentioned is explained in the problem definition: "After a variable has been defined with the var keyword, it
is possible to assign new values to it without a keyword. For example:

var a = 50;

a = a + 1;

a = 30;

free(a);"

In addition, it's included in the Input example file mentioned in the problem description:

"

var message = "a / b = ";

message = message + string(a / b);

"

So, the answer is yes. It is possible to assign new values a variable without a keyword after its declaration.

Hope it helps.

Gaston

Gastón C. Hillar

Melden Sie sich an, um einen Kommentar zu hinterlassen.