<curtisf>
I feel like I must be doing something dumb wrong. Has someone used Zig on Windows to write to files? I'm getting `Access is denied` whatever I try
<diltsman>
Basically trying to create a compile-time function to create a custom prologue/epilogue for interrupt handlers.
<diltsman>
If I remove the semicolon it compiles.
<diltsman>
However, removing the semicolon starts complaining about array access to non-array type.
<diltsman>
Seems to be something with trying to write higher-order functions. It appears that it thinks that the {} pair to delimit the function body is actually for something with arrays.
<emekankurumeh[m]>
daurnimator: on windows it would just be the same as `sockaddr_storage` right?
<gonz_>
diltsman: As far as I'm aware we don't have anonymous functions
<gonz_>
Can someone update me; does Go do any exhaustiveness checks on error return values?
<gonz_>
Last I checked it doesn't, and can't
<gonz_>
They can't do exhaustiveness checks, period.
<curtisf>
what would you mean by exhaustive check on error return? `error` is just an interface type you're not really supposed to inspect except to print the message, there's nothing to really branch on
laaron has joined #zig
<gonz_>
Well, you certainly want to handle errors differently depending on which error you're getting
<curtisf>
I'm not sure I've ever actually seen go code do that
<curtisf>
I guess you can do a type case check
<gonz_>
This doesn't seem like taking error handling seriously to me
<curtisf>
Agree. The only thing that Go really does over C is require you check function return values
<gonz_>
If it's still like the above blog post that just seems a bit cowboy to me
<curtisf>
Without unions (or equivalently, checked exceptions) it's hard to actually handle errors right. But since Go doesn't even have enums...
<gonz_>
Exactly
<gonz_>
There's very little base there to build something robust in terms of error handling on
<gonz_>
Explicit error handling is super nice
<gonz_>
But ideally it should also be machine checked
<curtisf>
Zig's error handling is really great. It's all of the good of checked exceptions and also of not having exceptions. I'm surprised it took this long to appear
<gonz_>
There is an issue up right now about how Go's error handling could supposedly be taken as inspiration to improve the error handling in Zig, but I'm wondering if there's actually any inspiration to be had at all.
<curtisf>
I'm reminded of the discussions about checked exceptions in Java, which I haven't really understood. Usually someone says something like, if you make a change to the code that throws a new/different checked exception, you've broken all of your callers if the exception is checked, which is a violation of the open/closed principle because an implemen
<curtisf>
tation detail is leaking. But that's not really true; exceptions are part of your function's interface; they should be explicit and every caller should handle every one of them explicitly
<gonz_>
Yes
<gonz_>
I *want* to have my code not compile if you change that
reductum has joined #zig
<daurnimator>
emekankurumeh[m]: yes on windows,.
<emekankurumeh[m]>
do any of you know of any guides to understanding atomic orderings?
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Client Quit]
laaron has joined #zig
kristoff_it has joined #zig
_whitelogger has joined #zig
reductum has quit [Quit: WeeChat 2.5]
<gonz_>
In the case of `@distinct` I find myself thinking that this one would probably be good to have, but at the same time that's what everyone thinks about their arbitrary set of nice features, even the obviously reader hostile ones.
<gonz_>
If wrapping distinct types in structs only has the issue of people losing their operators, etc., maybe that's fine. Defining the behaviors you need for the type you've made should not be the issue.
<mikdusan>
btw it's a safety-check error. looks to me compiler is being over-zealous in that error in debug/release-safe modes
_whitelogger has joined #zig
kristoff_it has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
<nrdmn>
Why can't enum(T) be implicitly cast to T?
<Poetastrophe>
My guess is that it is one of those types of conversions you do not want to happen on accident. Similar reasoning behind enum class in C++ and why they do not have implicit cast to the underlying type: https://stackoverflow.com/a/8357366
<mikdusan>
'compiler is being over-zealous'; changed my mind. it's a legit error. have tiny userland patch.
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
Poetastrophe has quit [Remote host closed the connection]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
SimonNa has joined #zig
jjido has joined #zig
jjido has quit [Client Quit]
<scientes>
how do i do bold in the documentation?
<scientes>
oh, i'll just use <b> heh
Akuli has joined #zig
<Tetralux>
gonz_: Phantom types?
<gonz_>
Types that disappear after compilation and are effectively only there to make types distinctive at compile-time
<gonz_>
In PL dweeb circles they're usually called phantom types
<gonz_>
because that sounds cool :D
<gonz_>
`newtype` in Haskell defines a phantom type and adding a type parameter you never use in the data type when using `data` will do the same
<gonz_>
`data User a = User { name :: String, age :: Int }`
<gonz_>
You can now put any piece of data in the `a` spot to distinguish the particular type of `User` you have
<daurnimator>
gonz_: the proposal in zig is called "distinct types".
<gonz_>
`sanitizeBeforeLogging :: User LogUnsafe -> User LogSafe`, etc.
<gonz_>
daurnimator: Sure. Your point?
<daurnimator>
gonz_: that things are more clear if you use the established terms in the zig community? :P
<gonz_>
There are no established terms in the zig community
<gonz_>
And there are already established terms for that concept
<Tetralux>
gonz_: You mean things like `const int = distinct i64;` ?
<Tetralux>
.. A type that's the same as i64, but requires comptime casting, even though it's just an i64 at runtime.
<gonz_>
"distinct types" are just phantom types, yes
<gonz_>
This is just hidden behind a keyword
<Tetralux>
I'm alright with that idea.
<gonz_>
Yes, I was just answering what you were asking
<gonz_>
They're called phantom types because they don't exist at run-time
<gonz_>
I'm not against the specialization, especially since the crowd is so different. As I said before, Haskell has a specialization for it as well
<gonz_>
`newtype Kilometer = Kilometer Double`
<gonz_>
I don't think having "distinct" types is something that's needed either
<gonz_>
I don't think "no one will want to distinguish types because they have to type too much" is a good argument for them
<daurnimator>
gonz_: the key conversation around distinct types for zig is if operators will work
<daurnimator>
as we don't have operator overloading; people want some way to avoid mixing different units but still be readable
<gonz_>
I read the issue. I don't think they have to.
<daurnimator>
yeah I'm on the side that isn't probably not worth it
<daurnimator>
uh *is
<fengb>
I think some people are confusing “simple is good” with “simpler is always better”
<fengb>
C is really simple for all the wrong reasons :P
<gonz_>
I think some people forget that if everyone gets "that one feature in" you end up with an unreasonable set of features
<gonz_>
When the argument pretty much is "I don't want to type too much" I think it's pretty easy to say it's not super important
<daurnimator>
yeah. that's why I noted that non-exhaustive enums get you distinct integer types (but without operators)
<gonz_>
Correctness is good and that's part of the argument for the distinct types, but wrapping them in structs gives you the same thing except you have to also treat it as its own type completely, not just a little bit.
<fengb>
I don’t mean adding features is always good, but we should at least do a real trade off analysis
<fengb>
I’ve been wrapping types in structs a decent amount in C. It’s dumb and I want a language construct to capture this
<Tetralux>
The thing about distinct types for me, is that the point of them is largely just that I want to remind the programmer that it is not just an old integer. The values mean things.
<fengb>
I dunno why I’m stating my points when you already agree >_>
<Tetralux>
Thing is, that doesn't necessarily mean that you should be able to do arithmetic.
<Tetralux>
Personally, I want to be able to have a distinct integer type which you _can_ do arithmetic on.
<Tetralux>
But have to cast between it and it's base type.
<Tetralux>
Or any other integer type.
<daurnimator>
Tetralux: one issue with that is.... who says that the arithmetic is "normal" arithmetic
<Tetralux>
The programmer who says "I want to be clear that is not just any old integer and it means a specific thing.
<Tetralux>
Like READ/WRITE/EXEC, for instance.
<Tetralux>
FileFlags
<gonz_>
Tetralux: The self-documentation/programmer bit is just type aliases and I'm not saying I don't see the point. I've used these to great effect in other languages. I don't need to be sold on it, to be honest.
<fengb>
How about: no implicit casts but allow operator overloading? Distinct i32 only adds others of the same type or comptime
<Tetralux>
If it was just you I had to convince, I wouldn't be saying anything xD
<Tetralux>
daurimator: More simply, you're idea is "use an enum"
<fengb>
Actually that would only be natural with addition/subtraction. Multiplication breaks that blah
<Tetralux>
My point is, if you want an integer to be distinct, it generally means that it's still an integer, and you want to do arithmetic - otherwise, you would have used an enum to begin with.
<Tetralux>
The whole point "I want it to be clear that this is not _just_ an integer"
<Tetralux>
bitflags would solve the enum part, I think.
<daurnimator>
bit flags should be done with a packed struct
<Tetralux>
It's like how you have SlotIndex in the gpda.
<Tetralux>
It's an integer.
<Tetralux>
It's just not _any old_ integer.
<daurnimator>
Tetralux: but would you ever add/subtract/multiply it?
<Tetralux>
In the case I just gave, you might.
<Tetralux>
The point of the name is make it's role explicit.
<gonz_>
In the case that you want to do interesting things with it, doesn't it make sense to have them all laid out where the type itself is defined?
<gonz_>
The things you want to do, that is.
<Tetralux>
It does, if it's more than just +, -, /, *.
<fengb>
daurnimator: I think what he’s trying to say is that it conceptually behaves much more like an int than an enum
<Tetralux>
Though if it's +, -, /, *, _and one other thing_
<Tetralux>
That could be a bit annoying.
<fengb>
In my emulator, memory and registers are just numbers. Trying to make them enums feel super weird
<daurnimator>
fengb: the key thing about an integer is that all math operators are well defined.
<Tetralux>
fengb: Yeah - I guess so.
<daurnimator>
fengb: why does making them enums feel weird?
<fengb>
But they also need to be distinct because mixing them up is super easy and leads to stupid behaviors
<Tetralux>
daurnimator: Because there may not be specific values that matter.
<fengb>
Because it’s any number in u8 space. It’s just an int and there’s no defined values anywhere
<fengb>
None of the values are distinctive so using enum doesn’t make conceptual sense
<Tetralux>
If you had specific values that mattered, you'd have an enum.
<Tetralux>
Though if you had a range of values that were fine, plus a couple of others, you'd have to panic at runtime if you tried to cast to it, which you'd have to use a struct for in status quo Zig.
<Tetralux>
But the main use of distinct over enum is just that any int value that fits is okay, it's just that I want it to be clear that it's not _just_ an int.
<Tetralux>
It's like "I want to use arithmetic on this thing and I want to name it, but I want it to be differently typed than the underlying int type so I don't make a mistake.
<gonz_>
I dunno, drawing the line at operators seems weird to me
<fengb>
Random thought: would it be weird to have an unwrap operator?
<Tetralux>
It's more drawing the line at types than it is operators, really.
<Tetralux>
fengb: unwrap how?
<fengb>
km.* += 1;
<gonz_>
Tetralux: You said you wanted people to have to specify the things they wanna do with the distinct types, except operators, no?
<fengb>
Not technically overloading and you can’t do normal math but the extra syntax would help out a little
<gonz_>
That's the part I just find odd.
<gonz_>
But I guess this is just another point for operator overloading, to be honest
<fengb>
It doesn’t have to be the pointer syntax. I couldn’t find a better a symbol on mobile :P
<gonz_>
I guess it's a point for overloading in general in some sense
laaron has quit [Remote host closed the connection]
<mikdusan>
`@distinct(T: type, ops: bool)`
<mq32>
hey
<mq32>
mikdusan, sounds like a nice thing
<Tetralux>
mikdusan: I think I'd prefer @distinctWithOps for clarity, but sure.
<Tetralux>
gonz_: You just want people to have to cast an int to this type.
<Tetralux>
Much in the same way you might for `Miles(1) + Kilometer(5)`
<Tetralux>
That would not work.
<Tetralux>
Of course, if you had op overloading, you _could_ make it work
<Tetralux>
But that's not the point of the example
<Tetralux>
The simple point is that you are essentially just annotating the "type" of the thing that the otherwise-normal-integer is representing.
<mq32>
but i'm in for distinct types for distinct semantics
<mq32>
also the example of daurnimator in the issue is quite a thing. i'm using OpenGL a lot and want to have the methods of OpenGL objects as methods, not function calls
<mq32>
it's so annoying that OpenGL just has GLuint for object identifiers
<diltsman>
Is there a way to do generic functions like there is a way to do generic structs?
<fengb>
Sticking in a comptime argument would generate a separate runtime function, like with std.debug.warn. Can you be more specific at what you’re trying to do?
<mq32>
fn(comptime T : type, a : T, b : T) T { return a + b; }
<fengb>
Oh you can’t define functions in functions atm. The current pattern is return an empty struct with a method
<diltsman>
Basically, interrupt handlers for my platform (armv7-m) can be...interesting. I need to provide custom calling conventions.
<diltsman>
I need the function to return something that can be assigned to a function pointer in a struct.
<diltsman>
Basically, I want a helper function to wrap different prologue/epiloge around a function.
<diltsman>
Otherwise I have to insert the same inline assembly in every interrupt handler (~30 functions).
<fengb>
Posted a reply. I’m not at my computer so it might not work >_>
Tetralux has quit [Ping timeout: 245 seconds]
<diltsman>
fengb, I did not see a reply.
<fengb>
Replied to the gist
Tetralux_ has joined #zig
<diltsman>
Ok, I replied to that.
Tetralux_ is now known as Tetrlaux
Tetrlaux is now known as Tetralux
<fengb>
Oh maybe try assigning the struct to a const and returning from that? Coding is hard from memory :/
<diltsman>
Fair enough.
<fengb>
e.g. `const s = struct { ... }; return s.f;`
<diltsman>
Ok, finally got things working. Thanks.
avoidr has quit [Quit: leaving]
<fengb>
Great! Anonymous functions are a pain point atm
<diltsman>
My biggest pain trying to get your code working was that I replaced the variable type in the struct definition rather than the initialization in the variable.
<daurnimator>
Oh I also realised something..... closures will be really easy once we have @Frame from the coroutine work
<mq32>
daurnimator, yeah we noticed that yesterday too :)
<mq32>
maybe closures may even be a userspace thing
<daurnimator>
I do think we'd want language support
<mq32>
yeah, that's true
<mikdusan>
i assumed difficulty in closures would be deciding on what to copy vs. reference
<mq32>
yeah, that's true
<daurnimator>
mq32: I would assume anything `const` => copy. anything `var` => reference
<mq32>
hmm
<daurnimator>
but of course.... the copy of a `const` can be skipped if it has long lifetime
<mq32>
i think the use should have full control over what to capture by-ref and by-value
<mq32>
that's just a thing Zig promotes
<daurnimator>
yeah I'll have to think about the copy vs reference a bit more
<mq32>
var closure = fn [&x,y] (i : i32) { };
<mq32>
similar to c++ syntax
<mq32>
would be a thing
<mikdusan>
I imagine if the compiler can prove the closure will stay on (nested) stack, captures could all be refs
<gonz_>
Tetralux: I know exactly what it is you want and I've used exactly that thing. My point about overloading was that there's so much grinding on in from different angles that all of those things point to people really wanting overloading.
<gonz_>
"distinct types" are not a special thing outside of lower level languages, it's not that I don't see what you want with them.
<gonz_>
If the idea is "Everyone wants this" = "People will have it", overloading will be added
<Tetralux>
id stick to just an int over using a custom struct with op overloadig for that
<scientes>
no overloading, thank you
<Tetralux>
too much boilkerplate / friction
<Tetralux>
boilerplate*
<gonz_>
Historically I've overstated the role boilerplate plays
<gonz_>
I'm ready for something different
<gonz_>
This isn't my third language
<Sahnvour>
hooray, stage1 stack traces are now working on windows !
<gonz_>
I'm ready for a language that makes a point out of not necessarily having an abundance of ceremony and boilerplate, but leans heavily toward a very small feature set and people being able to rely on that feature set being small and predictable
<scientes>
well, there are also places where the language is more complicated to make user code less complicated
<scientes>
an example of this is u0
<scientes>
and when the user-code is well defined
<scientes>
like I am adding an implicit cast that only happens with doing a & between a vector and a vector of bools
<Tetralux>
Here's an issue I've found in my travels.
<gonz_>
Tetralux: I deleted my response. Maybe just add what you replied with in the top post
<gonz_>
I misunderstood what the issue was
<Tetralux>
Done.
<Tetralux>
Ta for interest though.
jmiven has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
<emekankurumeh[m]>
nice Sahnvour
avoidr has joined #zig
andersfr has joined #zig
andersfr has quit [Client Quit]
Ichorio has quit [Ping timeout: 264 seconds]
Ichorio has joined #zig
Akuli has quit [Quit: Leaving]
euantor has quit [Ping timeout: 258 seconds]
euantor has joined #zig
<nrdmn>
is it possible to completely disable stack checking for PE binaries? If yes, where would I configure that?
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lunamn has quit [Ping timeout: 248 seconds]
jjido has joined #zig
lunamn has joined #zig
<emekankurumeh[m]>
nrdmn I don't think so, but a workaround might be linking libc
<nrdmn>
emekankurumeh[m]: by "configure" I mean "modify the compiler"
<nrdmn>
I don't have a libc on my platform and I don't want to provide an empty __chkstk as a workaround
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gamester has joined #zig
<gamester>
I'm curious to see how the function syntax change will turn out. It's more consistent but also takes 8 more characters of horizontal space and makes grepping more awkward.
<gonz_>
Function syntax change?
<hryx>
gamester: are you talking about 1717?
<gamester>
hryx: yes
<hryx>
not sure I understand the space difference. `pub fn main()` -> `pub main = fn()` is +2 characters
<gamester>
Isn't it "pub const main = fn()"
<hryx>
do you have an example?
<hryx>
oh yes it is. I of all people...
<gamester>
haha
<gamester>
It's certainly a change that makes sense for Zig
<hryx>
I should have finished my first coffee :|
<hryx>
Personally I'm excited about it, not for the syntax itself but because it opens the door a little better for passing anonymous functions
<gonz_>
I think the consistency is nice
<hryx>
but you're not alone with concerns about grep-ability. some of my other proposals were rejected because the community had similar qualms
<gamester>
Zig is not afraid to have character :) - It's probably a good change
<scientes>
no, every function does not have to start as an annonymous function
<scientes>
but its a valid idea
<hryx>
scientes: who/what are you responding to?
<scientes>
<hryx> not sure I understand the space difference. `pub fn main()` -> `pub main = fn()` is +2 characters
<scientes>
lets get those implemented before talking about closures ;)
jmiven has joined #zig
jmiven has quit [Client Quit]
jmiven has joined #zig
curtisf has joined #zig
<curtisf>
strictly speaking LALR/LL/RR are weaker than CFG. You can almost surely write a CFG for Zig. But it is still true that PEG is more powerful than constant lookahead parsers
<hryx>
curtisf: I see. was my comment incorrect? don't want my ignorance to be misleading or misrepresentative
<curtisf>
> If your goal is to write a CFG for Zig, that may not be possible
<curtisf>
That's the only part that's incorrect
<curtisf>
Replace "CFG" with "LL/LR/LALR" and it's correct
<hryx>
ah, thank you very much
<curtisf>
fun fact, as far as I know it's still open whether or not CFGs can recognize the same thing as PEGs
<curtisf>
sorry, that PEGs can recognize all CFGs*
<curtisf>
PEGs can match some non context-free languages
<hryx>
interesting!
<scientes>
hryx, there are four classes of language, as described by Noam Chomsky
<scientes>
hehe, hryx yes that is where by sheepskin is from
<scientes>
Alan Turing and Alan Church discovered the same thing at the same time
<scientes>
and then Noam Chomsky improved on it
<hryx>
presiden: double rad
<curtisf>
I still feel like the importance of constant-lookahead parsers is over-emphasized nowadays since we don't have to be so sparing with memory. PEG seems to be a much better place to be for parsing computer languages
<scientes>
syntax is not the only interesting thing in language, but Noam Chomsky was pretty influential
<scientes>
curtisf, if you want to be *fast* you probably should tokenize with regular expressions, specifically hyperscan
<scientes>
and you can *tokenize* some non-regular languages, just not parse them
<scientes>
*with regular expressions
<scientes>
I am still looking forward for a compile regexp engine
<curtisf>
I don't follow what you mean. You can still tokenize with regular expressions but capture the syntax with PEG
<curtisf>
What I'm complaining about is LL(k), LR(k), etc, not regular languages
<scientes>
comptime regexp engine
<curtisf>
be the change you want to see!
<scientes>
well zig finially makes it possible
<scientes>
I wanted this in C, but C just isn't designed that that (where its called Forward constant propagation)