Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

first draft of the language specification #75

Open
andrewrk opened this issue Jan 18, 2016 · 10 comments
Open

first draft of the language specification #75

andrewrk opened this issue Jan 18, 2016 · 10 comments
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase.
Milestone

Comments

@andrewrk
Copy link
Member

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

@andrewrk andrewrk added enhancement Solving this issue will likely involve adding new logic or components to the codebase. lowpriority labels Jan 18, 2016
@andrewrk andrewrk mentioned this issue Jan 19, 2016
10 tasks
@larroy
Copy link

larroy commented Feb 28, 2016

Is there a wiki to discuss language features / syntax?

@andrewrk
Copy link
Member Author

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
Copy link

larroy commented Feb 28, 2016

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link

larroy commented Feb 28, 2016

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
Copy link
Contributor

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
Copy link

larroy commented Feb 28, 2016

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
Copy link
Member Author

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 andrewrk changed the title language specification first draft of the language specification Oct 9, 2020
@andrewrk andrewrk modified the milestones: 0.7.0, 0.8.0 Oct 9, 2020
@andrewrk
Copy link
Member Author

andrewrk commented Oct 9, 2020

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.

@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 Jun 4, 2021
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 Nov 22, 2021
@andrewrk andrewrk modified the milestones: 0.10.0, 0.11.0 Apr 16, 2022
@andrewrk andrewrk modified the milestones: 0.11.0, 0.12.0 Apr 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase.
Projects
None yet
Development

No branches or pull requests

3 participants