4 ms·

I like it in general, but i have a few comments: 1. "Data oriented. Just functions, structs and enums. NO: classes, inheritance, properties, etc." I think you

by Crinus 8y ago

I like it in general, but i have a few comments: 1. "Data oriented. Just functions, structs and enums. NO: classes, inheritance, properties, etc." I think you should allow for struct "inheritance", at least in an Oberon-style manner. There are many cases where having a common "head" between structs is useful (e.g. widgets for a GUI toolkit, object types for a scripting language, etc). 2. "Memory is initialized to zero. Array bounds are checked (can be turned off where needed)." It is not clear from this, but how can both be disabled in a case-by-case basis? For example in D local variables are initialized to zero by default but you can do something like (IIRC): Foo foo = ? (or = nil, i do not remember) which the compiler interprets as "do not zero-initialize this). Similarly can i do something like array[foo] (bound checked) and array{foo} (non-bounds checked, imaginary syntax)? 3. "An LLVM backend is in the works which will avoid any undefined behavior." LLVM inherits most of C's undefined behavior, so it will not solve your problem there - you'll need to explicitly generate code that works around undefined behavior. This is a problem that the Free Pascal developers also faced (the language has much less undefined behavior than what LLVM assumes). 4. I am not fan of the language enforcing code style (e.g. "The name of a type parameter must be a single uppercase character." and significant whitespace) 5. Nitpick, but "List<T> struct #RefType { dataPtr pointer count int capacity int }" is a dynamic array, not a list (also, an example of why significant whitespace isn't a great idea :-P) 6. "Type inference for function return values and locals" I actually prefer to explicitly see the data types passed around, it helps better understand what exactly the code is doing (not just the algorithms, but also the data types which are important) without needing to have too much "implied code" in my mind (i.e. with explicit data types i don't need to "know" that "foo" returns "bar" when looking at its use in a diff (or any other non-syntax highlighted, non-code aware code viewing context), i actually know it because i see it in the code). (FWIW for this reason i also dislike auto in C++ and similar constructs in other languages - you save a bit of short term typing now, for a lot of long term headache later) 7. "fgets(s pointer #As("char "), size int, stream pointer #As("FILE ")) pointer #Foreign("fgets")" I think you need to make your type system good enough to natively express C types, otherwise the string-based pseudotypes will bite you hard later when you want to move away from using C as a backend. 8. I do not see any mention of a preprocessor, how is code supposed to IFDEF stuff (like, e.g. a commercial program that needs to have something like IFDEF DEMO, or a source file that needs to behave slightly differently if linked as a static library or dynamic library, or the use of two APIs like e.g. IFDEF LINUX, IFDEF WIN32, IFDEF OPENGL, IFDEF VULKAN, etc) or work around language limitations (like the non-availability of inherited structs mentioned above that C programs often work around by using a macro that defines common elements for structs)? 9. "Number literal suffixes" I'm not fan of the underscore in the suffixes and also i'd avoid the uppercase L and introduce an i (that is 'nop' but could be useful for automatically generated code via scripts and/or macros). There are other minor nitpicks, but i'd need to actually check it in practice to write more :-P.

nickmqb 8y ago
Thanks! 1. Right now, you can emulate this with the transmute builtin function. Not yet sure if the additional complexity of this feature would be worth it. 2. Array bounds checks can be avoided by using the unchecked_index builtin. Uninitialized locals are not yet possible, but I think it makes sense to eventually add a construct to allow that, for situations that need every last bit of performance. 3. I've only started to look into LLVM recently, thanks for the heads up. 4. See my comment here: https://news.ycombinator.com/item?id=19599908 https://news.ycombinator.com/item?id=19599908 5. C# programmers would like to disagree with you ;). Note that the formatting issue is not due to significant whitespace, as you'd have the same issue writing up a Golang snippet. 6. Editor support (specifically, language server) should help a lot here. 7. The string based types are only used for inserting the right cast to make the C compiler happy, so they should not be an obstacle. 8. Compile time evaluation can be used for some cases. Adding a preprocessor comes with its own set of tradeoffs, haven't yet decided what to do there. 9. A lowercase l looks a lot like a 1 in many fonts, hence the uppercase L. Will consider adding an i suffix.
- Crinus 8y ago
  1. The point of this is to avoid repeating the common headers and have the type system validate that a pointer/reference of a subtype is compatible with its parent type (in C you'd need to typecast which can be dangerous). 5. I also tend to name dynarrays as lists, but in this case you have both List and Array and the only difference seems to be that one has a capacity while the other doesn't. Having both can be a bit confusing when you actually wanted a (linked) list. 6. It will only help when inside the editor, hence why i explicitly wrote "when looking at its use in a diff (or any other non-syntax highlighted, non-code aware code viewing context)". 8. None of the examples i mentioned can be solved with compile-time evaluation (except some cases of IFDEF DEMO) since they change what code is actually compiled (e.g. if you want to use an API that may not even be available on a target - like e.g. DirectX on Linux) or generate code themselves. 9. I do not think it makes much sense to worry about that, there are fonts that have 0 and O look the same, let the user fix their fonts, do not punish those who use unambiguous fonts with inconsistency. Trust your users.

by Crinus 8y ago

nickmqb 8y ago

Thanks! 1. Right now, you can emulate this with the transmute builtin function. Not yet sure if the additional complexity of this feature would be worth it. 2. Array bounds checks can be avoided by using the unchecked_index builtin. Uninitialized locals are not yet possible, but I think it makes sense to eventually add a construct to allow that, for situations that need every last bit of performance. 3. I've only started to look into LLVM recently, thanks for the heads up. 4. See my comment here: https://news.ycombinator.com/item?id=19599908 https://news.ycombinator.com/item?id=19599908 5. C# programmers would like to disagree with you ;). Note that the formatting issue is not due to significant whitespace, as you'd have the same issue writing up a Golang snippet. 6. Editor support (specifically, language server) should help a lot here. 7. The string based types are only used for inserting the right cast to make the C compiler happy, so they should not be an obstacle. 8. Compile time evaluation can be used for some cases. Adding a preprocessor comes with its own set of tradeoffs, haven't yet decided what to do there. 9. A lowercase l looks a lot like a 1 in many fonts, hence the uppercase L. Will consider adding an i suffix.

Crinus 8y ago
1. The point of this is to avoid repeating the common headers and have the type system validate that a pointer/reference of a subtype is compatible with its parent type (in C you'd need to typecast which can be dangerous). 5. I also tend to name dynarrays as lists, but in this case you have both List and Array and the only difference seems to be that one has a capacity while the other doesn't. Having both can be a bit confusing when you actually wanted a (linked) list. 6. It will only help when inside the editor, hence why i explicitly wrote "when looking at its use in a diff (or any other non-syntax highlighted, non-code aware code viewing context)". 8. None of the examples i mentioned can be solved with compile-time evaluation (except some cases of IFDEF DEMO) since they change what code is actually compiled (e.g. if you want to use an API that may not even be available on a target - like e.g. DirectX on Linux) or generate code themselves. 9. I do not think it makes much sense to worry about that, there are fonts that have 0 and O look the same, let the user fix their fonts, do not punish those who use unambiguous fonts with inconsistency. Trust your users.