Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C3 Programming Language

c3-lang.org

Post reply on HN
Print view View original

261–270 of 270 posts

Re: The C3 Programming Language

#261

Post by lerno »

CyberDildonics wrote: post #72

It seems great to have something that is C but cleaned up, although clay had all that with templates and move semantics. I think leaving out move semantics and destructors is inexcusable at this point. It is not only fundamental, but doesn't affect things like standard libraries, runtimes, or ABIs.

But it of course move semantics and destructors affect all things. If the goal is to call and be callable from C without special constructs, how would you make the C code respect the move semantics and destructors?

Re: The C3 Programming Language

#262

Post by reactordev »

avadodin wrote: post #249
reactordev wrote: post #227

Earlier quoted context omitted.

python is not an option in this environment. Correct your tone.

I don't see anything wrong with my tone. I could have been snarky about it. I provided the C solutions as well but an interpreter written in C could at least allocate objects and threads within the interpreter context and not leak memory allowing you to restart it along any services within which is apparently better than whatever framework people sharing this sentiment are using. I'm genuinely curious. What kind of m…

ARINC-653

But no, tell me I’m wrong, tell me I’m an idiot for doing things this way, put me down for asking, and then deny my reality when I tell you.

This is why people dislike software engineers, they think they know everything.

Re: The C3 Programming Language

#263

Post by CyberDildonics »

lerno wrote: post #261
CyberDildonics wrote: post #72

It seems great to have something that is C but cleaned up, although clay had all that with templates and move semantics. I think leaving out move semantics and destructors is inexcusable at this point. It is not only fundamental, but doesn't affect things like standard libraries, runtimes, or ABIs.

But it of course move semantics and destructors affect all things. If the goal is to call and be callable from C without special constructs, how would you make the C code respect the move semantics and destructors?

C++ is already callable from C, you can make functions have any call signature that you want. What is the actual problem?

Re: The C3 Programming Language

#264

Post by xen0 »

lerno wrote: post #251
xen0 wrote: post #241

Reading through, something small caught me by surprise. https://c3-lang.org/language-common/arrays/#fixed-size-multi... Multi dimensional arrays are not declared in the same way they are accessed; the order of dimensions is reversed. Accessing the multi-dimensional fixed array has inverted array index order to when the array was declared. That is, the last element of 'int[3][10] x = {...}' is accessed with 'x[9][2]'.…

Please consider a variable `List{int}[3] x`, this is an array of 3 List{int} containing List{int}. If we do `x[1]` we will get an element of List{int}, from the middle element in the array. If we then further index this with [5], like `x[1][5]` we will get the 5th element of that list. If we look at `int*`, the dereference will peel off the `*` resulting in `int`. So, the way C3 types are declared is the most inside…

Thanks for pointing out what I was missing.

Please consider a variable `List{int}[3] x`, this is an array of 3 List{int} containing List{int}. If we do `x[1]` we will get an element of List{int}, from the middle element in the array. If we then further index this with [5], like `x[1][5]` we will get the 5th element of that list.

I get that motivation. In C++ it's an odd case that where `std::vector x[4]` is "reversed" in a sense compared to `int x[4][100]`. And this quirk is shared with other languages (Java, C#).

But in my experience, mixing generic datatypes like this with arrays is quite rare, and multi-dimensional array like structures with these types is often specified via nesting (`std::vector>`) which avoids confusion.

The argument re. pointers is more convincing though.

Re: The C3 Programming Language

#265

Post by avadodin »

reactordev wrote: post #262
avadodin wrote: post #249

Earlier quoted context omitted.

I don't see anything wrong with my tone. I could have been snarky about it. I provided the C solutions as well but an interpreter written in C could at least allocate objects and threads within the interpreter context and not leak memory allowing you to restart it along any services within which is apparently better than whatever framework people sharing this sentiment are using. I'm genuinely curious. What kind of m…

ARINC-653 But no, tell me I’m wrong, tell me I’m an idiot for doing things this way, put me down for asking, and then deny my reality when I tell you. This is why people dislike software engineers, they think they know everything.

You're the only one being aggressive here.

You drop a keyword and the aero-drones report. I do not mind it and I am not going to reply in kind.

I have 0 experience in aerospace but reading up on ARINC-653, it appears to mandate a reasonable RT design with threads and hard slices. Even comfortable with "partitions".

Where and why does the memory leak? If it is inherent in the mandated interfaces, you don't need to feel personally attacked.

If it is a layer laid down by your software –whether legacy or otherwise– why can't you keep track of allocations and ownership? Unless there are 200 bytes left and all slices are accounted for and running on the edge, I feel a solution could be worked out.

I wish you luck switching to Rust maybe a Rust2C translator could help.

Re: The C3 Programming Language

#266

Post by CyberDildonics »

reactordev wrote: post #227
avadodin wrote: post #206

Earlier quoted context omitted.

Why is something running on an rtos even able to leak memory? If your design is going to be dirty, you've got to account for that. In 30 years, I've never seen a memory leak in the wild. Set up a memory pool, memory limits, garbage collectors or just switch to an OS/language that will better handle that for you. Rust is favored among C++ users, but even Python could be a better fit for your use case.

python is not an option in this environment. Correct your tone.

Are you really telling someone to 'correct their tone' because one of their many suggestions doesn't work on your mystery platform that you won't mention?

Re: The C3 Programming Language

#267

Post by rixed »

flohofwoe wrote: post #258
rixed wrote: post #246

Earlier quoted context omitted.

tagged unions (not enums, sorry) are not a dynamic type system concept. Actually, I would not be able to name a single dynamically typed language that has them. As for the memory allocation, I can't see why any object should have the size of the largest alternative. When I do the manual equivalent of a tagged union in C (ie. a struct with a tag followed by a union) I malloc only the required size, and a function rece…

> Actually, I would not be able to name a single dynamically typed language that has them. That's because every type in a dynamically typed language is a tagged union ;) For instance in Javascript you need to inspect a variable with 'typeof' to find out if it is a string, a boolean, a number or something else. In a dynamically typed language, the runtime system needs to carry information around what type an item actu…

I don't think we speak the same language. I was refering to the use case (in C) that's been described by sph. Where you indeed malloc only the relevant size, and you have to manually and carefully check the tag before casting the payload into the proper type. This is what I am tired of doing over and over and over again, and would like a system programing language to help with.

Re: The C3 Programming Language

#268

Post by baranul »

zephen wrote: post #44

" the C-like for programmers who like C." Sounds intriguing. But then, the first thing I noticed in their example is a double-colon scope operator. I understand that it's part of the culture (and Rust, C#, and many other languages), but I find the syntax itself ugly. I dunno. Maybe I have the visual equivalent of misophonia, in addition to the auditory version, but :: and x I like C. But I abhor C++ with a passion, p…

It definitely is possible, because languages like Vlang (for example), are able to use '.' instead of '::'. Always saw this as language creator preference, versus any inescapable technical reason.

Re: The C3 Programming Language

#269

Post by fuzztester »

sph wrote: post #233
gritzko wrote: post #110

Earlier quoted context omitted.

I am a big fan of Ragel[1]. That is a high performance parser generator. In fact, it can generate different types of parsers, very powerful. Unfortunately, it takes a lot of skill to operate. I wrote a parser generator generator to make it all smooth[2], but after 8 years I still can't call it effortless. A colleague of mine once "broke the internet" with a Ragel bug. So, think twice. Still, for weekend activities I…

The worst part of designing a language is the parsing stage. Simple enough to do it by hand, but there’s a lot of boilerplate and bureaucracy involved that is painfully time-wasting unless you know exactly what syntax you are going for. But if you adopt a parser-generator such as Flex/Bison you’ll find yourself learning and debugging and obtuse language that has to be forcefully bent to your needs, and I hope your kn…

how is the boilerplate etc related to the syntax. not clear. i would have thought you first decide the syntax n only then start the work.

but i've never created an interpreter, let alone a compiler.

Re: The C3 Programming Language

#270

Post by maybewhenthesun »

chippiewill wrote: post #147
maybewhenthesun wrote: post #146

I see 'fn void main()'. There's probably a good reasson but why the 'fn'? It doesn't really add anything because 'void main()' already communicates it's a function. The main draw of C (to me) is it's terseness and it's avoidance of 'filler' syntax words. I admit I didn't (yet) look much further into it, but this first thing jumped out to me and slightly diminished my desire to look further into C3...

It's to remove a syntax ambiguity with c-style function declarations https://en.wikipedia.org/wiki/Most_vexing_parse The syntax ambiguity adds a lot of complexity to the grammar that makes parsing a lot more complicated than it needs to be. Sticking `fn` in front fixes a lot of problems.

tnx for the clear explanation
Post reply on HN