The Hare programming language

Post by discreteevent » Mon, Apr 25, 2022, 9:48 AM UTC

zozbot234 wrote: post #45

vladharbuz wrote: post #21

Earlier quoted context omitted.

I can sort of understand where you're coming from — manual memory management can be difficult, and doing it improperly can cause bugs. However, in my experience, we're very far from having a magical solution for memory management. C++ definitely isn't it, and while Rust does bring significant advances in this field, it's a very large and complicated language. Unfortunately, the memory management strategy of every oth…

> C++ definitely isn't it, and while Rust does bring significant advances in this field, it's a very large and complicated language. It really isn't. Not compared to C++, at least. Or to managed language runtimes, which are just as "large and complicated", only beneath the hood.

Post by nyanpasu64 » Mon, Apr 25, 2022, 9:51 AM UTC

zozbot234 wrote: post #49

nyanpasu64 wrote: post #44

Earlier quoted context omitted.

Not staticassertion, but I'm a hobbyist in real-time audio. I like Rust as a vocabulary for describing/teaching safe programming (&/&mut/Send/Sync). I find that multithreaded programs written in Rust are usually correct while multithreaded programs written in C++ are usually wrong, because Rust encodes the rules of shared-memory threading in its type system (&T: Sync objects are thread-shared, but are either immutabl…

> However I find it makes it too difficult to mutate through shared references It's not that difficult, you just need to use UnsafeCell or one of its safe derivatives (each of which has some potential runtime overhead) to keep the semantics tractable.

    let mut x = 1;
    let px = &mut x as *const i32;
    unsafe {
        *(px as *mut i32) = 2;
    }

    let mut x = 1;
    let px = addr_of_mut!(x);
    unsafe {
        *px = 2;
    }

Post by ddevault » Mon, Apr 25, 2022, 9:53 AM UTC

erk__ wrote: post #62

ddevault wrote: post #50

Earlier quoted context omitted.

I'm not sure what you mean by "select by type". I can say that you can define new types: type a = int; type b = int; type c = (a | b); Which seems to be what you're angling for here? I also suspect that you're approaching this from a Rust- or Zig-like background where enums and tagged unions are closely related; this is not so in Hare.

I do know those languages, but this is more the ADT way from ML. The example you linked did not really make it clear from my point of view because one of the points is that it will collapse if there are multiples of a specific type. But your way seems to make it possible.

Post by turminal » Mon, Apr 25, 2022, 9:54 AM UTC

pizza234 wrote: post #64

staticassertion wrote: post #19

lol my other post got flagged, so let me reiterate perhaps in a less inflammatory way. It is disappointing to see that "trust the programmer" is a design goal. Programmers can not be trusted with manual memory management. We have decades of proof, billions and billions of dollars of bug fixes and mitigation investments, real world damages, etc. Building a language like this and saying you hope it will be the foundati…

Quoted post unavailable.

Post by nyanpasu64 » Mon, Apr 25, 2022, 9:59 AM UTC

ddevault wrote: post #58

nyanpasu64 wrote: post #52

Earlier quoted context omitted.

FWIW, frequently I've wished that languages had a version of https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html built-in for implementing iterators, like Python generators, or somewhat similar to async/await. Porting the macros to C++ suffers because switches can't jump past declaring local variables with required constructors, and my hacks around this issue were ugly and error-prone. I haven't learned C++…

We do not have first-class iterators, but we do have an iterator pattern which is common throughout the Hare standard library. As an example, here's how you can enumerate the nodes in a directory: let iter = os::iter("/")!; for (true) { const entry = match (fs::next(&iter)) { case let ent: fs::dirent => yield ent; case void => break; }; fs::println(entry.name)!; };