The unwritten coexistence of integers & arrays namesakes

[MaximilianYan]

A code

function sum(id, pr, n, a):
    x := array(n)

    x := 1
    x += id

    print(x)
    x := array(n)
    print(10000+x)

    x += id

correctly (without errors being occurred) works with output (e.g., input is 1 239)

1
2
3
...
100
10001
10002
10003
...
10100
steps: 26

.

Meanwhile, a code

function sum(id, pr, n, a):
    x := array(n)
    print(x)

    x := 1
    x += id

    x := array(n)

    x += id

(e.g., input is 1 239) fails with an error

step 3, id 0, line 3: no such variable: x

.

I've found nothing about redeclaration of the variables in the documentation, and such a behavior seems inconsistent to me.

[GassaFM]

In the current version of the language, there are two variable types: int64 and array of int64. In the current implementation, these two are kept in separate namespaces, see struct Context at https://github.com/GassaFM/interpr/blob/master/source/runner.d#L65-L72 and around. The rationale is that the type can be uniquely determined at site of usage, so why bother distinguishing?

So, what are the benefits and the drawbacks, and what should be done about it, if anything?

[MaximilianYan]

The rationale is that the type can be uniquely determined at site of usage, so why bother distinguishing?

Ok, I can accept such a notation. But also I think that such a language invariant like "the syntax must explicitly define type of variables at the site of usage" must be explicit declared somewhere.

[GassaFM]

"the syntax must explicitly define type of variables at the site of usage"

The syntax does not have an obligation to define type, it just does, partly by coincidence. This may change if the language ever gets more complex.

[MaximilianYan]

I think that you (as language creation coordinator) must make a decision and choose one of the paradigms:

• Language does not support namesakes variables.

or

• Language supports namesake-variables syntax via explicit definition of the type of the variable at the site of usage

.

[GassaFM]

That's one possible way.

But the language is, at least in part, a learning project. Non-blocking issues are opportunities for the students to take part. Not just by reporting stuff, but also, for example, by discussing language design.

So, as issue author, what do you think of each of the possible decisions?

[MaximilianYan]

what do you think of each of the possible decisions?

Probably, I am guided by a sense of beauty, but I find such a syntax attractive (mostly in cause of it's being funny and intriguing), so I would prefer legalizing the namesake-variables syntax.

[GassaFM]

Yeah, that. But what are the practical considerations, beside beauty which is mostly in the eye of the beholder?