All languages seem to either always have or always not have garbage collection. Because if gc exist, it must be build into language, and language should be build according to that. But gc is an overkill in some situations, and isn't necessary if you are careful to always free memory. I hope to turn garbage collection into a debugging feature, and remove it from the final build. I'm not sure how exactly I would make that, memory management is probably more complicated than code generation. I'll probably take a static analysis approach, simply warning a programmer when he forgot to free something. Not sure. I care about the final binary more than about the prettiness of language itself.

Can't really improve Nim beyond certain point. If Nim compiles to C, then it has flaws of C I'd like to fix. Namely being unable to receive multiple return values from a function. (You can do that, but it's not supported directly, you must pass variable's address as one of arguments. It's pretty ugly. Compiler probaly can optimize that away, but I have no idea if it actually does that.)

Meanwhile you can check out http://ziglang.org/ , interesting how it listed both "no garbage collection" and "no dependency on C" right on the front page, two problems I complained about with Nim. It actually passed "4 kilobyte test", but it's still very very raw at the moment. Try donating to him, maybe it will speed things up.

I'm concerned about how that "exception on integer overflow" will look like, need to look at generated assembly. Need to compile the damn thing first.

Internally depends on llvm, and with windows it depends on either visual studio or mingw, I guess for the final assembly->binary and for headers.

The "comptime" feature is really promising, it's zig's way of killing preprocessor for good, and replacing C++ templates. Also, I like how it's goal seems to "simplify and replace C". My goal is to simplify and replace assembly without compromising anything.

Also check out https://luapower.com/winapi , it seems to pass the "interactive" requirement. Don't think the resulting exe file is good though.

There is also Idlewild https://board.flatassembler.net/topic.php?t=18704 , don't think it passes either requirement, but it's focus is also gamedev. Crossplatform, written in haskell. Confused on how to install this thing, so haven't tried it yet.

I'm concerned that Zig thinks that exceptions are useless. I thought so too before, but I think they can actually speed program up. If used with care.

Another thing is that Zig claims to compete with c, but still uses llvm for all code generation. It could be a limiting factor, too many operations in the middle, it can affect compilation speed. It also supports too many processors and oses, which could mean it wouldn't use os native functionality properly.

That I really like about Zig is, oddly enough, how it handles switches. You can use ranges, you can use else, and not having everything covered is a compile-time error. You can mark one of cases as unreachable, and then it will be a runtime error.

About Idlewild, it's an interesting language, simple but still pretty capable. It only compiles to a 64bit assembly, which I for some reason avoid. I'm trying to make 32bit windows games, since it will run everywhere anyway.

My progress with luajit is that I got it running. At first I recompiled it myself, and some programs broke because my compiled luajit had no proper manifest. I finally see what they are for. I'll probably never use manifest files, ever.

I'm concerned about how that "exception on integer overflow" will look like, need to look at generated assembly.

Perhaps using the dedicated x86 instruction INTO? Note that there is no equivalent INTC for unsigned overflow. Nor for that matter any other generic INTcc for any other condition code variations.

Didn't knew INTO existed, Thanks, it could come in handy one day.

vivik wrote:

I'm concerned about how that "exception on integer overflow" will look like, need to look at generated assembly. Need to compile the damn thing first.

It's only a debug feature, release version goes without those.

vivik wrote:

Internally depends on llvm, and with windows it depends on either visual studio or mingw, I guess for the final assembly->binary and for headers.

Looks like visual studio is only needed for libc. Maybe one day zig will work without libc, technically it can to some extent. I still don't quite understand what libc does other than some annoying initializations you can't get rid of. Looks like work on it is in plans.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum