ziglang / zig

General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
https://ziglang.org
MIT License
34.08k stars 2.49k forks source link

first draft of the language specification #75

Open andrewrk opened 8 years ago

andrewrk commented 8 years ago

It has to happen sometime. Probably not until a proof of concept is already working and the language isn't constantly changing.

larroy commented 8 years ago

Is there a wiki to discuss language features / syntax?

andrewrk commented 8 years ago

Sure, I mean the wiki's open. Have at it. Feel free to ask questions and make proposals here or in other or new issues too.

larroy commented 8 years ago

My two major comments are:

The const in front of the type when you use suffix types is inconsistent, I would have it in the suffix.

The maybe type should work like a monad. Also somehow the percent operator and the mix between references, pointers and nullable doesn't make a lot of sense to me. Why would you be able to maybe an i32 that is not a pointer? A reference should never be null also.

andrewrk commented 8 years ago

The const in front of the type when you use suffix types is inconsistent, I would have it in the suffix.

Can you give some code examples of how it's inconsistent? I'm a visual learner.

Also zig doesn't have suffix types, only prefix types.

The maybe type should work like a monad.

Can you spell this out in more detail for someone who isn't super keen on functional programming?

Also somehow the percent operator and the mix between references, pointers and nullable doesn't make a lot of sense to me. Why would you be able to maybe an i32 that is not a pointer? A reference should never be null also.

Zig doesn't have references, only pointers. You can make any type nullable if you want to introduce a null state to the set of possible values. The generalized concept makes sense independent of pointers.

thejoshwolfe commented 8 years ago

The const in front of the type when you use suffix types is inconsistent, I would have it in the suffix.

Are you talking about:

var a : i32;
const b : i32;

vs something like:

let a : i32;
let b : const i32;

If so, the reason for this is that the const-ness of a symbol is not a property of its type, but rather of its declaration in context. If a "variable" is declared constant, it means you can't assign to it. That idea doesn't really have anything to do with its type.

In zig, you can't declare a field of a struct const. Either the whole struct is const, as determined by its usage in context, or the whole thing is variable. Likewise, you can't declare an array of constant values. Either the array itself is declared const, or the whole thing is variable. If const was syntactically part of a type declaration, like it is in C, then the compiler would need to disallow const in these cases. Instead, const is part of declaration syntax and part of pointer types.

Unlike structs and arrays, which are "by-val" compound types, pointers do not embed their "child type", and so their const-ness is independent of their target's const-ness. That is why the const keyword is allowed in pointer types and not in struct or array types.

larroy commented 8 years ago

Yeah thats what I meant. I was a bit brief as I'm a cellphone.

Still the compiler can check that a const pointee is not mutated through p: const*T. So WRT to const it boilds down to const / let/ var. If using const then it would be great to also be able to use const on the right side so the typechecker can avoid mutating the pointee through that pointer as C++ would do.

About the monads I will respond later.

thejoshwolfe commented 8 years ago

Are you suggesting that this be allowed:

var a : i32;
const b : i32;
const c : const i32; // same as b
var d : const i32; // probably not allowed?
larroy commented 8 years ago

According to your comments I thought that const p: const * i32 wouldn't be allowed.

How would a pointer to a const array of char be declared?

const s: []u8 = "something in .rodata" const p: *const char = s

p can't be changed, nor the data it points. Equivalent to const * char const in C++...

I'm just trying to understand the logic behind the type syntax.

Regarding monads I would suggest watching this: https://www.youtube.com/watch?v=Mw_Jnn_Y5iA&feature=youtu.be

This is very pictorical (swift based):

http://www.mokacoding.com/blog/functor-applicative-monads-in-pictures/

And more:

https://vimeo.com/132657092

andrewrk commented 8 years ago

How would a pointer to a const array of char be declared?

const s: []u8 = "something in .rodata" const p: *const char = s

const s = "something in .rodata"; // @typeof(s) is `[20]u8`
const p = &s[0]; // @typeof(p) is `&const u8`

As for monads, you made this claim:

The maybe type should work like a monad.

Can you provide code examples to demonstrate your proposal?

andrewrk commented 3 years ago

Here's the repo: https://github.com/ziglang/zig-spec

Once we have a first draft, this issue can be closed, and that repository can be used to track progress towards completion of the spec.