Semantics Discussion

[Aliqyan-21]

let's discuss all the sema rules here.

[Aliqyan-21]

rough roadmap

1. Names + scopes + resolution
2. Semantic types
3. Variables + mutability
4. Expressions + operators
5. Functions + calls + returns
6. Control flow
7. Structs + fields
8. Enums + variants + match
9. Pointers
10. Error handling
11. Generics
12. Comptime
13. Anything else

and memory-model somewhere whenever it's ready!!

[Aliqyan-21]

Should there be shadowing in bedrock or totally not allow duplicate declaration at all in any scope?

[vasucp1207]

I think we should allow the shadowing, declaring a new variable everytime is not very convenient to a programmer. We can track the variable scopes so I don't think its a big issue.

func main() -> i32
    var a = 10;
    if true
        var a = 10
    end
    return 0;
end

func main() -> i32
    var a = 10;
    var a = "string";                     <------------ delete the previous declaration from here
    return 0;
end

[Aliqyan-21]

I don't like this:

func main() -> i32
    var a = 10;
    var a = "string";                     <------------ delete the previous declaration from here
    return 0;
end

This could be a mistake by programmer too, and we should error here that it's a duplicate declaration, also, this is not safe, as it could have lifetimes and we can't just delete like that. I don't think any systems langauge allows this thing.

[Aliqyan-21]

I think for these scopings, we can take c/c++ or zig's model directly they don't allow same scope duplication, they always give error for this things.

[vasucp1207]

This could be a mistake by programmer too, and we should error here that it's a duplicate declaration, also, this is not safe, as it could have lifetimes and we can't just delete like that. I don't think any systems langauge allows this thing.

What kind of mistakes are you referring here, can you give me some example? Also how this could be problematic with lifetime?

[Aliqyan-21]

what if by mistake programmer chooses same name, like copy mistake, and programmer never intended to overwrite it.

if we just delete the var it could have it's own memory, that will never be freed, so we will have to keep it somewhere to free memory and everything, even though it's no more in code.

so better is just don't allow such thing, why redeclaration should be allowed, it's not allowed in go, c/c++, zig, etc.

[Aliqyan-21]

So let's discuss type system

• for inferencing var a = 32 for integers we can do i32 and for floats we can do f64 like zig/c does it.
• suppose we have:

var x: u32 = 14;
var p: u8 = x;

Will this be implicit or explicit and what about the vice versa that is u8 to u32?

• what about the types of structs and enums?

CC @vasucp1207

[Aliqyan-21]

@vasucp1207 how type conversion will take place?

suppose I wanna do int to float or float to int, which one will be legal?

can I do char to string? but then how string to char will work?

what if I do i32 to i8? or i8 to i32?

many questions!

[vasucp1207]

I we should not do automatic type conversion and assigning ex form i32 to i8 we need to type that explicitly with some kind of sugar syntax. We can provide these conversion functions as a part of standard lib.

[vasucp1207]

var a: i8 = 5;
var b: i32 = 5;
a = <builtin-fn>(b);

[Aliqyan-21]

I see, so they will not be implicit part of the language but part of the standard library?

[vasucp1207]

builtins can be used directly with a hashmap storage

[Aliqyan-21]

no I mean, the conversion, usually the conversions are implicit part of the language no?

Idk, if we keep it in standard library, then it will be a long time before we have conversions in bedrock.

[Aliqyan-21]

@vasucp1207

suppose foo is a func that returns a value obviously.

so then we can do:

foo();

give error.

_ = foo();

does not.

yeah?

[vasucp1207]

Yes, ignoring like this ok

[Aliqyan-21]

@vasucp1207

consider a proc named foo which does not return any value:

a = foo();

// or

var b = foo();

this should be illegal or warning or what? I think it should be illegal, as proc does not return anything right.

[vasucp1207]

I think we should mark this as error because if we only emit warning then there is a possibility that we can ref to the proc result value which means nothing.

[Aliqyan-21]

yes right, and this does count as error, because this could be mistakenly done by user as it does not makes sense storing a proc's value, another win for proc ig.