<companion_cube>
because the code isn't typed yet, right?
<Tetralux>
Just have your interpreter be an intermediate stage to compilation.
<companion_cube>
branches of the `if` are untypable
<Tetralux>
Suddenly you can run your entire program at comptime.
<companion_cube>
s/run/reduce/
<companion_cube>
you can't run the part that are runtime
<Tetralux>
You can require that you win a round of invaders before you're allowed to compile invaders ;)
<Tetralux>
And yes, you can.
<Tetralux>
Just more slowly.
<Tetralux>
You can use pointers, create threads.
<companion_cube>
how do you run a runtime part at compile time?
<Tetralux>
Because compile time, IS, runtime.
<Tetralux>
You can compute fib(25) at comptime.
<Tetralux>
.. is an example.
<companion_cube>
can you compute fib(n) where n is a runtime argument?
<Tetralux>
Maybe we have cross-purposes here.
<Tetralux>
My point is just
<Tetralux>
That you have two "runtime" times.
<Tetralux>
One is at compile time.
<companion_cube>
one is called compile time
<companion_cube>
and it's not evaluation but reduction
<Tetralux>
My point is, the same code can work in both cases.
<Tetralux>
You can run your game, win a round, and have your score become a constant in the final executable.
<Tetralux>
Which you then have to beat by playing the game using the exectuable.
<Tetralux>
That's a silly example, of course.
<Tetralux>
But being able to open a window, use OpenGL, shaders, threads, and godknows what else at comptime, LIKE ITS JUST A PROGRAM, is a powerful tool to have in your toolbox.
<Tetralux>
There's a certain beautiful simplicity in how transparent it is.
<companion_cube>
you just give up on compilation being terminating 😁
<Tetralux>
Who says it needs to be?
<Tetralux>
I don't.
<Tetralux>
And of course, since you're running at comptime, you _could_ ask the compiler to tell you about every piece of Ast in your program and insert perf instrumentation, or ensure you comply with MISRA.
<bgiannan>
daurnimator, Tetralux, I think unions are a cleaner way of dooing OOP but it's really verbose. Here's an example of muli-level inheritance: https://0x0.st/z4-d.zig
<bgiannan>
but it may be slower than the @ptrCast solution ?
ltriant has quit [Quit: leaving]
<mikdusan>
that example is shifting dynamic dispatch from function pointers to manual switch statements
<ntgg>
How would I pass a string from js to a zig fn?
<ntgg>
I am currently trying to do fn([*]const u8, length: usize), but the text seems to be invalid
<mikdusan>
ntgg: what is internal format of js string?
<ntgg>
mikdusan: I converted the string to a utf8 array in js
<ntgg>
I think the native is utf16
<bgiannan>
mikdusan, here's the pointers solution but it relies on a shaky trick to find out what types an instance inherits from
<bgiannan>
and requires packed structs
<gonz_>
I think doing OOP should be very verbose, because you probably should not be doing OOP.
<gonz_>
In any case it's probably better for you to pass comp time interfaces to functions that need to be working with different things.
<gonz_>
Which also does not preclude you from making these distinctions with unions if you want to.
<bgiannan>
gonz_, maybe but i would need at the very least rust-like traits (or swift-like protocols)
<gonz_>
For what?
<bgiannan>
Be able to hold an heterogeneous list of struct instances who exposes the same functions/behavior
<gonz_>
If they are all part of the same union, the function returning the interface is the one that actually matters. They could all also just have a method that returns the interface for that type and that would be checked at compile time.
<mikdusan>
what if you choose at runtime
<mikdusan>
i'd like to give runtime params such as: a stream (stdout), a file, a memory buffer, a socket, a pipe, a hub
<gonz_>
Then you just change the interface argument to not be `comptime` and the function returning it examines the values at runtime.
<bgiannan>
gonz_, not sure i follow you
<mikdusan>
and i don't want 6 times the code size
<gonz_>
bgiannan: Likewise. I think the definition of "OOP" matters here.
<gonz_>
mikdusan: Generated or written?
<mikdusan>
generated
<gonz_>
AFAICT zig doesn't need to generate tons of code for examining a value at runtime
<gonz_>
Or whatever version we would have right now
<mikdusan>
never said it did. i'm talking about code generation for comptime in lieu of runtime decision
<gonz_>
Comptime passed interfaces that compile down to fast calls is likely to be a better default in terms of programmer choices
<gonz_>
And those are already possible now, with very understandable semantics
<gonz_>
Even if you were to decide late on the interface, I don't see how that's not possible atm
<gonz_>
In any case I don't know that there's anything that needs adding at all with regards to any of this
kristoff_it has joined #zig
<gonz_>
I think there are already languages that are (allegedly) made for OOP
<bgiannan>
OOP doesn't need to be a language feature
<gonz_>
My point is that something like OOP or equivalent doesn't need *anything* added right now, contrary to what the prospective language designers in the community think.
<gonz_>
And I would argue they only think that because they are more interested in putting their fingerprint on zig with language features than they are with it being a usefully small language.
<bgiannan>
i agree
<bgiannan>
i'm just trying to find the most effective way of doing it in zig
<gonz_>
I may have misrepresented/misunderstood your original point
<gonz_>
sorry about that
<gonz_>
I had been reading the backlog as usual and as usual there's a lot of high-flying talk about new features
kristoff_it has quit [Ping timeout: 268 seconds]
<gonz_>
But yes, simple things like unions, passed interfaces to functions, etc., make for almost everything you could actually need
<gonz_>
I haven't found the boundaries yet but I would never suggest adding anything new until I had
<bgiannan>
gonz_, did you see the @ptrCast solution i linked?
<gonz_>
I did not, sorry
ntgg has quit [Ping timeout: 272 seconds]
<gonz_>
bgiannan: When did you paste it? I can't seem to find it in the logs.
<bgiannan>
huh talked about it but forgot to paste the link, one sec
<bgiannan>
https://0x0.st/z4-7.zig it lacks a way to tell which types an instance inherits from and it requires packed structs
<gonz_>
Yeah, like you said it doesn't feel as reasonable as the union variant
<gonz_>
And personally I wouldn't go for anything with less lines just for that
<bgiannan>
right
<bgiannan>
is it faster though?
<bgiannan>
because of less indirections?
<gonz_>
I dunno, I guess you would have to benchmark?
<mikdusan>
z4-7.zig doesn't call base sayYourName()
<fengb>
Not quite inheritance, but I'm not sure I really care about inheritance
<andrewrk>
I believe that either he or Jimmi tested it and it was friendlier to LLVM's optimizations as well
<andrewrk>
that being said, @fieldParentPtr should in theory be equivalent to the optimizer. it might be short-sighted to cater to something so volatile
<bgiannan>
andrewrk, the volatile thing being OpaqueType ?
<andrewrk>
the volatile thing being arbitrary optimizations which will not go into the zig language specification
earnestly has quit [Ping timeout: 245 seconds]
<andrewrk>
llvm is optimized for c and c++. @fieldParentPtr happens to be a bit uncommon in those domains. I'm predicting that if zig were more popular, this pattern would be recognized by the optimizer in the future
earnestly has joined #zig
<andrewrk>
rust had to implement a bunch of custom llvm optimization passes for their advanced stuff. in zig we barely need any of that because it's so similar to C, but there could be a couple benefits from doing some of that work
<fengb>
Should IO errors be unified?
lunamn has quit [Ping timeout: 245 seconds]
lunamn has joined #zig
<andrewrk>
I think that question is going to need more context
<fengb>
Oh I've been misusing all these methods. nvm
waleee-cl has joined #zig
halosghost has joined #zig
<Tetralux_>
There's not a special machine instructions for switch statements is there?
<mq32>
Tetralux_, not really. I'd say: add+jmp or a lot of cmp+jmp
<mq32>
depends on the complexity of the switch
<fengb>
When should I use var vs comptime T?
<fengb>
Tetralux_: most non-trivial switches optimize into jump tables
<fengb>
so offset + jump
<andrewrk>
fengb, generally, prefer comptime T, use var when it solves a problem
<Tetralux_>
.. The reason being that it reduces code size to use comptime T.
<kristoff_it>
So, I'm working on my Redis client, I've wired the parser to a stream and everything works. That said, I don't fully understand how Zig Streams work. Why do they close around an error type?
<fengb>
Ah yeah, I'm currently using "var" to work around that >_>
<kristoff_it>
Uhmm I see, thanks I'm gonna read that now. Btw andrewrk I think I wrote the first Redis client that doesn't need dynamic allocations for simple replies, judging from what's avaliable for C/C++
<andrewrk>
I'm still considering how to solve this. not closing around an error type would be an improvement in several ways, but then the error set of the stream functions would lose information
<kristoff_it>
I
<andrewrk>
kristoff_it, that's great!
<andrewrk>
I think that's a good example of how exposing allocations to be visible, encourages higher quality code
<kristoff_it>
I'm looking forward for a stream about how to make async I/O work for people that are new tho this stuff :)
<andrewrk>
I'm looking forward to that as well. I'm still doing some more proof-of-concept work in the std lib, and I will keep you posted
<kristoff_it>
Yes, I also think that it's weird that nobody tried to do this stuff before, a lot of embedded stuff is using Redis.
<fengb>
kristoff_it: are you doing zig for your day job?
<kristoff_it>
I'm a developer advocate at Redis Labs
<kristoff_it>
so... kinda
<kristoff_it>
I write/talk about Redis, and Zig is in many ways a great fit, both for writing modules (dynamic libraries that Redis can load and expose as new commands) and, I think clients too.
<fengb>
So... this generic error problem is exactly why checked exceptions are terrible in Java
<fengb>
kristoff_it: that's pretty cool
<andrewrk>
fengb, with regards to InStream, alternatives are: 1. use anyerror and the user of the stream will have to deal with that. or 2. fold errors into error{ReadFailed}
<andrewrk>
this is, once again, a problem with function pointers
<fengb>
Yeah, I'm just commenting that it's a hard problem to solve and I don't think anyone has done it well
<Tetralux_>
Notice how, read cannot fail if you passed an ArrayList, but you still must annotate the fn with anyerror in case it's not.
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
darithorn has joined #zig
andersfr has joined #zig
andersfr has quit [Client Quit]
halosghost has quit [Quit: WeeChat 2.5]
halosghost has joined #zig
<gonz_>
fengb: To be fair, is the alternative in Java really much better?
<gonz_>
AFAICT Java has no reliable way to actually be sure about your error domain(s).
donpdonp has joined #zig
<gonz_>
I'm not going to pretend to know the details, but when people bring up how the Java community doesn't like checked exceptions I can't help but think that other communities might/would prefer them to the chosen alternative for the most part.
<fengb>
I don't think any other community uses checked exceptions
<gonz_>
I didn't say they do, but that they might.
<fengb>
It's hard in Java because there's no way to upcast exceptions. So either the generic definition is super limited or it's super vast
<gonz_>
From what I understand of the value prop it seems a much better default attitude to have than the "anything goes" that comes with the alternative.
<fengb>
And both are crappy for capturing actual meaning
<fengb>
I've admittedly never worked in a language with better semantics. Maybe Haskell does it better?
<fengb>
Elm just attaches result or maybe to everything, which also doesn't give a lot of useful information
<gonz_>
Haskell is nice in terms of simple error use-cases but it has asynchronous exceptions (and you have to, it's not practically speaking a choice) and those are not really nice at all.
Tetralux_ is now known as Tetralux
<gonz_>
The community does the best it can and has a lot of machinery that can make it feel reasonable to a large extent, but no, it's not fundamentally nice.
<Tetralux>
You'd think that returning a value marked as an error and checking if you'd handled them all would be enough.
<gonz_>
Error unions are better than most things I've seen
<Tetralux>
The only thing with error unions is that you could get almost all the way there just by having multiple returns value and the ability to mark one as an error.
<fengb>
Yeah I really like Zig error handling
<gonz_>
What's the purpose of that, though, Tetralux?
<Tetralux>
More general, mainly.
<Tetralux>
I do like being able to return an error I didn't define though.
<Tetralux>
That's pro-exploration.
<fengb>
I prefer errors being special. It solves so many problems that Go encounters
<fengb>
You can just return `error.AnyArbitraryValue`
<Tetralux>
return zero(T), 12 -> signature: fn() (T, int #error)
<gonz_>
Special and mergable with each other, yes.
<gonz_>
Is what makes them good to me
<donpdonp>
usize(msgleft) -> expected type 'usize', found 'isize'
<Tetralux>
usize is not a cast.
<gonz_>
The problem in most nominally typed languages that can return error variants is that there is no good way to merge them.
<fengb>
@intCast(usize, msgleft)
<donpdonp>
usize(x) appears to have some powers to cast one int type to another
<Tetralux>
I get tripped up by that too.
<donpdonp>
yet in some cases it wont do it
<fengb>
type(foo) does a compile time cast. @intCast() is what you want
<Tetralux>
It only casts comptime_int to an int type.
<Tetralux>
It's more a type assertion.
<Tetralux>
Like in:
<Tetralux>
var x = if(cond) usize(1) else usize(42);
<donpdonp>
ok comptime_int makes sense. thx.
<Tetralux>
o7
<Tetralux>
I do like how you can just make one up to return.
<Tetralux>
That's pretty useful for me.
<donpdonp>
is warn("{}", 12) -> compiler bug: integer and float literals in var args function must be casted. Fixed in HEAD yet? o^O
<Tetralux>
I don't think so.
<andrewrk>
none of the var args issues are scheduled to be fixed in 0.5.0
<kristoff_it>
is there an easy way to know when a type is recursive?
<andrewrk>
can you elaborate on your use case?
<Tetralux>
Oh - also, you wanna be able to compose interfaces; things like `const Stream = Writer + Reader;` ... `fn f(rw: Stream) ...`
<Tetralux>
Otherwise you end up with things like Peekable(Rewinder(Writer(T)))
<kristoff_it>
`const reply = try client.send(i64, "GET", "key");`, If the first argument (which is the return type of .send) instead of being an i64 is a type that contains itself, then it's impossible to allocate statically. I was wondering if there was a simple way of rejecting those types immediately with a @compileError
<kristoff_it>
andrewrk: forgot to tag you
alexander92 has joined #zig
<kristoff_it>
maybe I'm thinking something stupid, now that I think more about it. You can't do it without pointers, otherwise the type would never end
<donpdonp>
is there a case insensitive []u8 compare?
<andrewrk>
kristoff_it, I suggest to not try to hide it from the API user
<donpdonp>
i realize that crosses the sematic line of std.mem.compare into string-handling o^O
<kristoff_it>
andrewrk: users can use .sendAlloc to decode responses with pointers
<andrewrk>
donpdonp, case sensitivity is more complicated than you might think at first. if you're comparing user provided strings, you'll need full unicode support. for your project you are using GTK I believe and they should expose a function for case insensitive string compare, because they already depend on full unicode support
<andrewrk>
alexander92, I just landed a big branch into master, and yes those docs are up to date, but there is more that I'm still working on before I have a meaningful demo
<donpdonp>
andrewrk: thx there is g_utf8_casefold () which looks like byte-compare can be used with the return value.
<andrewrk>
donpdonp, that looks right
<fengb>
Would Unicode be a userland thing?
avoidr_ has joined #zig
<fengb>
I mean implemented in std instead of the compiler
avoidr has quit [Ping timeout: 245 seconds]
<andrewrk>
yes
<andrewrk>
but probably not even in the std lib
<Tetralux>
Really?
<andrewrk>
yeah because it's a large dependency that changes constantly and rarely needed
<andrewrk>
"rarely" is debatable, but it's true that many important use cases don't need it
<Tetralux>
I mean, printing to stdout needs it.
<andrewrk>
why?
<Tetralux>
Because you might want to print unicode characters xD
<Tetralux>
Like, any time you want to interact with strings...
<andrewrk>
stdout is a byte stream, not a unicode character stream
<earnestly>
Tetralux: language doesn't need to do anything for that
<Tetralux>
The language, maybe not. But std.strings?
<andrewrk>
I'm still stuck on stdout. why does stdout need unicode?
<earnestly>
Are strings not just byte arrays?
<fengb>
Go has a concept of extra packages that are maintained by core but not in stdlib. Would that concept exist in Zig?
<Tetralux>
andrewrk: Because terminals generally assume utf8.
<fengb>
Unicode are a special subset of byte arrays with its own quirks
<Tetralux>
earnestly: .. namely that some characters take up multiple bytes.
<fengb>
Like codepoints != runes
<earnestly>
Tetralux: That doesn't matter to the language though, it matters to the terminal interpreting it
<andrewrk>
Tetralux, consider that you can manipulate UTF-8 in plenty of meaningful ways without the ability to decode or encode unicode, or have any knowledge of unicode whatsoever
<andrewrk>
for example, you can print utf-8 encoded bytes to stdout
<andrewrk>
you can test if a utf-8 encoded string contains '/'
<fengb>
Print already works with UTF8. The terminal is interpreting the bytes
<Tetralux>
I mean, you should be able to produce utf8 and consume it.
<andrewrk>
I think a lot of people don't understand this, and I find it a bit difficult to communicate. It would be worth figuring out how to explain it in a helpful way and put it in the docs or FAQ
<fengb>
You can type Unicode into strings and they work too
<Tetralux>
I think that it would be useful to have some basic utf8 stuff in the stdlib. Like encoding/decoding to and from []u8.
<Tetralux>
Or be able to install a pkg for it and then have that globally available - that could work too I suppose.
<andrewrk>
decoding/encoding into codepoints will be there. (it is there already, just incomplete)
Akuli has joined #zig
<andrewrk>
what won't be there is the ~10MiB unicode data about codepoints, for the reasons noted above
<Tetralux>
That should definitely be an optional extra xD
<andrewrk>
but yeah fengb I could see there being a "blessed" package for it. I don't think that's a decision that needs to be made now
<Tetralux>
I just think that if you ever have to think twice about seemlessly allowing utf8 text in your program, then it could be better.
Cloudef has joined #zig
<Tetralux>
And for that, you want it to be nigh-transparent.
<Akuli>
utf8 in, utf8 out :D
<earnestly>
Tetralux: But the language needs to be agnostic for that to work at all
<Cloudef>
streams are bytes, not objects, not text
<earnestly>
Iow, "just bytes"
<donpdonp>
[arduino temperature sensor code 345bytes][UNICODE LIB 12MB] thats not gonna fit in my 2k atmel chip :)
<andrewrk>
Tetralux, the phrase "allowing utf8 text" makes me think that you're not thinking about it in this way that I'm trying to communicate
<Tetralux>
andrewrk: That's possible. I'm no expert in unicode fiddlings xD
<andrewrk>
basically, don't decode ever
<andrewrk>
there's rarely a reason to
<andrewrk>
and then you fully support unicode, without any dependency on a unicode package
<Tetralux>
This is true.
<Akuli>
andrewrk, in a program like that, how do you lowercase a string?
<Tetralux>
Or search for a substring.
<fengb>
Shouldn’t there be a validation step for Unicode?
<Cloudef>
Tetralux: you have severe misunderstanding how text generally works
<Akuli>
or implement a windows path equality function?
<andrewrk>
you can't do either of those things in such a program. Unless the "string" is not user input and it's some thing from a spec which is guaranteed to be ascii
<Tetralux>
Cloudef: Maybe xD
<Akuli>
andrewrk, or some other subset of unicode, so that whenever someone needs to do this, they'll end up creating their own thing that works well until some character they didn't think of appears
<earnestly>
Akuli: Is that not the domain of platform API?
<Akuli>
as a finn, i might write it to handle ä and ö, but not ø, for example
<fengb>
I know HFS+ has insane rules for case matching. I forgot if they fixed it for APFA
<fengb>
APFS
<andrewrk>
I mean like maybe the BMP file spec allows "BMP" or "bmp" for the magic bytes (it doesn't), but that would be a time you don't need real case folding
<Akuli>
i was about to do this once but then i realized how horrible that idea was, and just went with python's case-insensitiveness which worked great
<Cloudef>
Tetralux: most cli programs for example aren't unicode aware at all, but utf8 just happens to work since it's compatible with strcmp and friends
<andrewrk>
and I stand by my claim that it's rare that a program needs to lower case a string
<andrewrk>
if it really does, ok great, use real unicode
<Akuli>
yeah that makes sense, if using real unicode is easy as adding a lib
<Tetralux>
What about command line options that are case insensitive?
<Tetralux>
Just only accept lowercase?
<Tetralux>
xD
<Akuli>
do some programs have case-insensitive switches?
<Cloudef>
Tetralux: terminals, might be utf8 aware, some / old ones probably check your system locale. But generally output from program doesn't have to be "text"
<andrewrk>
I feel like I mentioned this case already Tetralux
<Tetralux>
Forgive me if I missed it. It's like 35C over here rn xD
<Cloudef>
transforming / editing unicode is can of worms :P
<Tetralux>
Suffice it to say, I'd want to make it robust, by not caring - but I'm not sure how I'd do that trivially.
<Tetralux>
That's all I'm really saying.
<Cloudef>
even simple toupper/tolower
<fengb>
andrewrk: the protobuf spec has a separate string data from bytes. Should I just ignore the Unicode validation?
<andrewrk>
fengb, I see what you're talking about now
<andrewrk>
ok so your use case is to match the protobuf spec
<Tetralux>
fengb: CBOR does too. Currently I'm checking it with unicode.utf8ValidateSlice on both encode and decode.
<andrewrk>
I think validation does not carry the big dependency
<Cloudef>
fengb: protobuf actual treasts string/bytes the same
<Cloudef>
treats*
<andrewrk>
that's just making sure it will decode successfully
<Cloudef>
the string in spec is just hint for human
<fengb>
Over the wire yes, but it embeds some semantic meaning implying proper Unicode
<Cloudef>
I don't think the spec says it's supposed to be unicode
<fengb>
I’m happier to ignore it if that’s the de facto standard :P
<Cloudef>
it's just hint for human
<fengb>
Oh? I should double check then
<andrewrk>
fengb, I'm not suggesting to ignore standards
<fengb>
Damn dirty humans
<earnestly>
They make computers complicated
<Cloudef>
nanopb is good protobuf reimplementation
<fengb>
I’ve just been coding to spec atm
<Akuli>
oh one thing where i would like to have some unicode awareness: gnu expand and unexpand don't handle ä and ö correctly
<Akuli>
it's annoying when i have a file containing ä's and ö's on some lines and ascii on others, and when i expand it they just don't line up
<fengb>
Or the human version rn. I need to dig into it further
<Akuli>
because ä is two bytes but a is one byte, on my utf-8 system
<Akuli>
but i guess that a function to count the number of characters in an utf-8 string is enough to fix that?
<fengb>
That’s runes vs codepoints. A program often doesn’t need to care
<fengb>
The terminal should handle it pretty well.
<Cloudef>
yeah, when you are lining up text like that, you want to be unicode aware
<alexander92>
andrewrk, thanks, ill check out the new async code then when i can
<Cloudef>
expand probably isn't
<earnestly>
Cloudef: The terminal itself might also be missing it up, especially if it has to pull glyphs from other families
<andrewrk>
alexander92, for now the most interesting code would probably be in test/stage1/behavior/async_fn.zig. Or look for social media in 2-3 weeks when I should hopefully have an impressive demo in the tech news :)
<Cloudef>
earnestly: nah that's issue with expand
<Akuli>
this one isn't the terminal's fault, it's expand's fault for counting bytes rather than code points or character widths
<Akuli>
either one would be acceptable for my ä and ö needs
<earnestly>
Cloudef: Ah so it is, tried with higher plane stuff and it fails all the more
<earnestly>
wc -m is unicode aware for counting characters, as opposed to -c
<Cloudef>
it would be trivial to support utf8 at least though
<Cloudef>
counting runes isn't hard
<earnestly>
And is 2 orders of magnitude slower
<Cloudef>
I think some coreutils have switch for "utf8 aware" mode
<earnestly>
Usually dictated by locale though
<Cloudef>
that too
<fengb>
andrewrk: would it be possible to generate an executable ast at comptime?
<andrewrk>
ugh, c++ lets you implicit cast an enum to a bool
<andrewrk>
fengb, not sure what you're asking. it sounds like you're trying to generate .zig code during the build?
<fengb>
Yeah
<mq32>
andrewrk, c++ bools are 150% broken
<andrewrk>
fengb, can you elaborate on why you don't want to generate a .zig file?
<fengb>
It'd be neat to be able for the code to consume a .proto file without needing to spit out the intermediate
<fengb>
Not a dealbreaker by any means, but it'd be something special that Go couldn't do
<Tetralux>
Who the hell uses protobufs?
<Cloudef>
sadly a lot
<andrewrk>
fengb, I've put some thought into this, and I think it's better to have the intermediate file on disk
<Tetralux>
Cloudef: You're telling me.
<andrewrk>
for one, debug info. stack traces will be improved, and in the debugger it wants to know where something is defined for structs
<fengb>
Sure okay
<andrewrk>
it's also a nice place for caching to happen
<andrewrk>
empirically, @cImport improved once we had an intermediate file
kristoff_it has quit [Ping timeout: 248 seconds]
<andrewrk>
it's one reason we don't have @reify
<andrewrk>
although that's still an open proposal
<mq32>
@reify with structs could probably make inheritance/interface stuff a 100% userland thing
<mq32>
also interface combining (what tetralux wrote in #2938) would be doable in userland
<andrewrk>
it's undeniably powerful
<Tetralux>
That would also be something Go cannot do.
<Tetralux>
AFAIK, at any rate.
<companion_cube>
beware of fragmentation when sublanguages can be built from userland
<mq32>
yeah that's a drawback
<companion_cube>
the lisp curse ;)
<mq32>
ha, yeah
<mq32>
Lua can do similar things
<mq32>
it's crazy how much of a different language you can make with table syntax sugar
<fengb>
Or Ruby, if you want to see an example of poor fragmentation :P
<companion_cube>
like the meta thingy?
<mq32>
companion_cube: you can define a function that determines the value of non-declared variables (okay, Lua can do this too)
<mq32>
so you can do stuff like "a = hello world";
<andrewrk>
I think the field alignment branch can get merged today
<fengb>
The Ruby ecosystem loves to invent its own DSLs that are wholly incompatible with other libraries
<fengb>
And the DSL system isn't even that robust, unlike Lisp
laaron has quit [Read error: Connection reset by peer]
andersfr has joined #zig
andersfr has quit [Client Quit]
laaron has joined #zig
meheleventyone has joined #zig
<Akuli>
good luck getting autocompletion for a ruby dsl, lol
meheleventyone has quit [Client Quit]
<alexander92>
method_missing is not that strange
<alexander92>
its based on smalltalk
<alexander92>
i think autocompletion is a tooling problem: maybe autocompleters integrated in the compiler should be able to suggest better stuff for dsl-s/operator-based code etc
<companion_cube>
autocompletion is hard because tooling, by nature, knows little about the code since it's all dynamic
<alexander92>
that's true: but dsl-s in static languages don't have such a problem
<alexander92>
e.g. depends on the type of metaproramming, but e.g. if you can define your dsl with some quasiquoting/or with some helpers, the language might be able to generate suggestions
<alexander92>
or if you pattern match AST input for a macro (or you have compile time function "expression" types)
<earnestly>
Will there ever be standard search paths for @import? E.g. /usr/include/zig or -L like flags
<andrewrk>
no, there will be package dependency declarations. but there could be flags to help the build system find alternative locations for the packages
<mq32>
would be sane to store a single copy of each package at a centralized place
<mq32>
rust/cargo doesn't do this and even small projects have 2.5 GB folder size because each project contains all packages in built/cached for
<mq32>
*form
<THFKA4>
hey yeah, we could also hash the "derivation" script for each package and prepend it to the name in this "store"
<andrewrk>
nice try THFKA4
<andrewrk>
not going to depend on a third party project for this
<earnestly>
andrewrk: I would like to avoid language package managers if possible
<THFKA4>
noooooo, he didn't bite
<earnestly>
Having standard-ish locations for libraries, imports, etc. would help alleviate that need
<donpdonp>
there is a standard, i forget the name, that is especially helpful for languages as dynamic as ruby, where the compiler runs as a daemon and the ide can submit queries like if these 5 modules are loaded, what are my autocomplete options
<mq32>
donpdonp, did you mean "language server protocol"
<donpdonp>
mq32 that sounds right :)
<earnestly>
donpdonp: It's a microsoft invention
<Tetralux>
mq32: I'd honestly just not have build artifacts.
<mq32>
Tetralux, zig already has build artifacts ;)
<Tetralux>
Yeah, and I dislike it xD
<mq32>
just do "find zig-cache"
<mq32>
but it's sane ;)
<Tetralux>
I mean - you can't have caching related bugs without a cache
<earnestly>
mq32: Is that what creates the ~/.local/share/zig (ignores XDG_DATA_HOME) directory?
<Tetralux>
Besides which, how you do know that a bug isn't because of the cache.
<Tetralux>
And of course, it's just as sane to just be fast enough that you don't need to do it.
<Tetralux>
I'd argue, more sop.
<Tetralux>
so*
<fengb>
afaik, zig doesn't have cache errors
<Tetralux>
I've run into several weirdnesses that were fixed by `--cache off`
<Tetralux>
A piece of general advice
<Tetralux>
What you just said is quite like saying that a piece of software "has no bugs."
<Tetralux>
I instantly don't believe you. xD
<Tetralux>
But even if it didn't, I'd rather not rely on something that _needs_ to not have bugs for it to not cause weird problems.
<Tetralux>
I want things to be stupidly simple.
<Tetralux>
.. but powerful.
<Tetralux>
Besides which, object files are code duplication, no?
<Tetralux>
If so, that's the same problem C++ has with builds taking two years.
<Tetralux>
Though I'd imagine that Zig is a tad smarter about it than C++.
<Tetralux>
Still though, I'd rather have sub-half-second complete compile times.
<Tetralux>
Looking at you, stage2.
<mikdusan>
andrewrk: just to confirm zig-ir does not have any actual instructions for runtime safety checks and that's all done at codegen?
earnestly has left #zig ["WeeChat 2.6-dev"]
wootehfoot has joined #zig
<gonz_>
Tetralux: You say these things as if it's just a choice you have to make and then suddenly it's done.
<Tetralux>
Perhaps less of the "suddenly", but otherwise.. sure let's go with that.
<mikdusan>
Tetralux: why is it you are unwilling to accept possibility of bugs from complexity of caching but are willing from incremental compiles (sub-half-second) ?
<Tetralux>
Incremental doesn't have weird caching bugs.
<Tetralux>
xD
<Tetralux>
xD
<Tetralux>
Oops. Wrong window xD
<gonz_>
Tetralux: Since you feel very strongly about this I guess a forked version of the compiler that does ~100kloc/s compilations and no caching is something you should aim for.
<gonz_>
Though maybe the real aim is ~1Mloc/s, IIRC.
<gonz_>
Or maybe Thekla is hiring instead. :D
wootehfoot has quit [Quit: Leaving]
<Tetralux>
Hey man - if I had a language that was fast to write good code in... ;)
<Tetralux>
But yes - I'd consider it.
<andrewrk>
Tetralux, no rumors spreading about cache system bugs unless you have a documented example please
* Tetralux
smiles.
<Tetralux>
I thought you might say that.
<andrewrk>
mikdusan, correct
<andrewrk>
regarding runtime safety checks. although I do think it would be beneficial to move those checks (maybe all of them?) to zig ir
<mikdusan>
yeah i'm looking into bounds checking and splitting logic between analysis and codegen is a little icky
<mikdusan>
we can take a slice of a pointer to array `*[10]u32`, but is there reason why we can't take slice of pointer to slice `*[]u32` ?
<andrewrk>
wow, fundude builds fast
<fengb>
Well it's not too complex
<fengb>
Doing some userland checking for the merge?
<andrewrk>
yes
<fengb>
I'll do a sweep later tonight to see which of the bugs I've encountered are fixed
<andrewrk>
it fixes a bunch of bugs but it is still a breaking change
<fengb>
I do abuse packed alignments quite a bit with fundude
<fengb>
... I need to pick that back up
<andrewrk>
you're probably also bound to run into "struct 'foo' depends on itself" followed by an error note trace. In most of these cases, the lazy value system can be improved to resolve the dependency loop. however some cases will need some code modifications
<fengb>
Actually most of the issues I’ve encountered had to do with missed packing
<andrewrk>
one limitation is comptime function evaluation. all parameters must be fully evaluated before evaluating the function
<fengb>
Accidentally declaring a 7 bit struct and stuff
<andrewrk>
ah yes. there's a lot of room for improvement around packed structs
<andrewrk>
7 bit struct will work fine eventually. that's equivalent to u7
<andrewrk>
but I didn't handle that case yet
<fengb>
Well I didn’t mean it. And the compiler just crashes on me
<andrewrk>
yeah
<andrewrk>
wow the new sound effects in oxid sound great
<alexander92>
is it planned to have functions with delayed evaluation
<alexander92>
maybe this might be enough to support some more macro-like usages
<Tetralux>
What does "delayed evaluation" mean exactly?
<gonz_>
Lazy evaluation, evaluated when needed, I assume.
<gonz_>
A'la Haskell
marijnfs has joined #zig
<halosghost>
aka call-by-need
<halosghost>
which is fancy
<gonz_>
I like it in Haskell but I don't think it has a place in a language desiring simplicity.
<halosghost>
but rare
<halosghost>
I'm not sure what the use-case would be in Zig
<halosghost>
in Haskell, it allows for some really incredible things like simple operation on infinite lists (aka streams)
<halosghost>
but, that's not exactly a common thing to do in a systems language
<halosghost>
there are also some performance benefits, but Zig is already likely to out-perform most other modern languages anyway
commander has quit [Remote host closed the connection]
shritesh has joined #zig
halosghost has quit [Quit: WeeChat 2.5]
porky11 has quit [Ping timeout: 264 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
marijnfs has quit [Quit: WeeChat 2.4]
<shritesh>
I'm compiling Zig on Arch and it's failing at "Building CXX object CMakeFiles/zig_cpp.dir/src/zig_llvm.cpp.o" with an "initializing llvm::ArrayRef<..> from 'std::initializer_list<..>::begin' does not extend the lifetime of the underlying array [-Werror=init-list-lifetime]" warning that's treatead as an error. I couldn't find an existing issue for it.
<andrewrk>
shritesh, what c++ compiler/version?
<shritesh>
g++ (GCC) 9.1.0
<andrewrk>
let me see if I have that easily available